DBA职责
1备份策略的设计
备份周期：根据数据量
备份工具：mysqldump , XBK(percona xtrbackup),MEB(MySQL Enterprise Backup),mysqlbinlog
备份方式：全备 （mysqldump） 增量(binlog(flush logs ,cp之前的))
物理备份：XBK 全备+增量
2检查备份可用性
crontab -l
备份脚本
备份路径
看备份日志，检查备份文件（大小，内容）
3定期的恢复演练
4数据恢复
只要备份和日志是完整的，恢复到故障之前的时间点（快速）
5数据迁移
mysql -> mysql
其他 -> Mysql
Mysql->其他
操作系统不同的迁移
mysqldump
连接数据库
-u 用户
-p 密码
-S socket
-h 主机
P 端口
基础备份参数
-A 全备
-B 单裤 或者多个库
库 表
-d 只备份表结构（不包含数据）
-t只备份数据库表的数据（不包含表结构）
演示
mkdir /backup/
全备
mysqldump -uroot -p123456 -A >/backup/full.sql
或者加上时间
mysqldump -uroot -p123456 -A >/backup/all_$(date +%F).sql
备份多个库
mysqldump -uroot -p123456 -B world sky >/backup/db.sql
库表的备份
mysqldump -uroot -p123456 world city country>tab.sql
备份多个表
mysqldump -uroot -p123456 word>/backup/word_tab.sql
特殊备份参数
-R 备份存储过程和函数
-E 事件 （相当于linux的计划任务）
--triggers 触发器
--master-data=2
--single-transaction
master-data=2详解
1.记录备份时刻的binlog信息
2.自动锁表
不加--single-transaction，温备
加了--single-transaction ，对于Innodb表不锁表(快照备份)
--single-transaction
对于innodb的表，进行一致性快照备份，不锁表
恢复案例
1.背景环境
正在运行的网站系统，mysql-5.7.20数据库，数据量50G，日增1-5M
2.备份策略
每天23:00点，计划任务调用mysqldump执行全备脚本
3故障时间点
年底故障演练：模拟周三上午10点误删数据库
4.思路
a.停业务，挂维护页,避免数据的二次伤害
b.找一个临时库，恢复周二23:00全备
c.截取周二23:00 ----周三10:00误删的binlog日志，恢复到临时库
d.测试可用性和完整性
5.方法一： 直接使用临时库顶替原生产库，前端应用切割到新库
方法二：将误删除的表导出，导入到原生产库
6.开启业务
处理结果：经过20分钟的处理，业务恢复
故障模拟演练
准备数据
create database backup;
use backup
create table t1(id int);
insert into t1 values(1),(2),(3);
commit;
参数讲解
--set-gtid-purged=off (auto/ON)(OFF) OFF仅是做普通的本机备份回复时，可以添加，相当于没开GTID
构建主从复制一定要使用auto或者on
在备份中添加 SET @@GLOABL.GTID_purged
--max_allowed_packet=128m 数据包大小调整（备份时候会报错，传输数据包大小）
生产中数据表很大，导出的时候占用内存，数据包
准备周二的23:00全备
mysqldump -uroot -p123456 -A -R --triggers --set-gtid-purged=off --master-data=2 --single-transaction|gzip>/backup/full_$(date +%F).sql.gz
cd /backup/
# ll
total 13208
-rw-r--r--. 1 root root 13521639 Dec 25 22:00 full_2019-12-25.sql.gz
解压缩检查一下
gunzip full_2019-12-25.sql.gz
模拟周二23:00到周三10点之间的数据变化
use backup
insert into t1 values(11),(22),(33);
commit;
create table t2(id int);
insert into t2 values(11),(22),(33);
commit;
模拟故障，删除库
drop database backup;
准备临时库（3307） 切割binlog数据
vim /backup/full_2019-12-25.sql
起点
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=792;
终点
show binlog events in 'mysql-bin.000006';
| mysql-bin.000006 | 1558 | Query | 6 | 1656 | drop database backup |
截取
mysqlbinlog --skip-gtids --start-position=792 --stop-position=1558 /data/binlog/mysql-bin.000006>/backup/bin.sql
vim /backup/bin.sql
看看有没有drop 没有就对了
数据恢复
mysql -uroot -p123456 -S /data/3307/mysql.sock
set sql_log_bin=0;
source /backup/full_2019-12-25.sql
source /backup/bin.sql
show databases;
show tables;
select * from t1;
select * from t2;
将故障表导出并恢复到生产
mysqldump -uroot -p123456 -S /data/3307/mysql.sock backup >/bakcup/bak.sql #因为是临时库，加不加参数都行
mysql -uroot -p123456
set sql_log_bin=0;
use backup
source /backup/bak1.sql;
set sql_log_bin=1;
数据被删除的演练(GTID)
create database sky charset utf8mb4;
use sky;
create table t1(id int);
insert into t1 values(1),(2),(3),(4),(5);
commit;
全备操作
mysqldump -uroot -p123456 -A --master-data=2 --single-transaction -R -E --triggers>/backup/full.sql
查看备份的sql
SET @@GLOBAL.GTID_PURGED='c01ce874-0b98-11ea-8819-000c296fff83:1-15';
16-
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2407;
更新数据
insert into t1 values(6),(7),(8);
commit;
update t1 set id=10 where id>5;
commit;
删除数据，并捣乱
delete from t1 id=5;
commit;
delete from t1;
commit;
show tables;
insert into t1 values(6),(7),(8);
commit;
update t1 set id=10 where id>2;
commit;
select * from t1;
+------+
| id |
+------+
| 10 |
| 10 |
| 10 |
+------+
恢复
show binlog events in 'mysql-bin.00006';
mysqlbinlog --skip-gtids --include-gtids='c01ce874-0b98-11ea-8819-000c296fff83:16-21' --exclude-gtids='c01ce874-0b98-11ea-8819-000c296fff83:19' /data/binlog/mysql-bin.000006 >/backup/bin.sql
切割日志，gtid16-21的 不要19的事件
查看一下
vim /backup/bin.sql
set sql_log_bin=0;
source /backup/full.sql
source /backup/bin.sql
set sql_log_bin=1;
mysqldump核心参数总结
--master-data=2
1.以注释的形式记录二进制日志信息（日志名，节点信息）
2.开启自动锁表的功能
--single-transaction
针对innodb进行快照备份（保存多个版本（MVCC）一致性快照）
