MySQL day6 备份恢复

按照这个顺序去读取

一、备份工具

设计备份、容灾策略

• 备份策略：备份工具选择、备份周期设计、备份监控方法

5.1 mysqldump (MDP)

优点：
1.不需要下载安装
2.备份出来的是SQL，文本格式，可读性高,便于备份处理
3.压缩比较高，节省备份的磁盘空间

缺点：
4.依赖于数据库引擎，需要从磁盘把数据读出
然后转换成SQL进行转储，比较耗费资源，数据量大的话效率较低
建议：
100G以内的数据量级，可以使用mysqldump
超过TB以上，我们也可能选择的是mysqldump，配合分布式的系统
1EB  =1024 PB =1000000 TB

5.2 xtrabackup(XBK)

优点：
1.类似于直接cp数据文件，不需要管逻辑结构，相对来说性能较高
缺点：
2.可读性差
3.压缩比低，需要更多磁盘空间
建议：
>100G<TB

5.3 备份策略

备份方式：
全备:全库备份，备份所有数据
增量:备份变化的数据
逻辑备份=mysqldump+mysqlbinlog
物理备份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog
备份周期:
根据数据量设计备份周期
比如：周日全备，周1-周6增量

二、mysqldump

mysqldump (逻辑备份的客户端工具)
mysqldump --help

逻辑备份工具。备份的是SQL语句

InnoDB可以采取快照备份的方式。
备份方式：开启一个独立的事务，获取当前最新的一致性快照
将快照数据，放在临时表中，转换成SQL（Create database，Create table，insert），保存到sql文件中。

非InnoDB表
需要锁表备份、触发FTWRL，全局锁表。转换成SQL（Create database，Create table，insert），保存到sql文件中。

2.1 客户端通用参数

连接参数：
-u  -p   -S   -h  -P    
本地备份:
mysqldump -uroot -p  -S /tmp/mysql.sock      这个 -S 不写就默认在tmp位置
远程备份:
mysqldump -uroot -p  -h 10.0.0.51 -P3306

2.2 备份专用基本参数
-A 全备参数，整个备份

例子1:
[root@db01 ~]# mkdir -p /data/backup
mysqldump -uroot -p -A >/data/backup/full.sql
Enter password: 

mysqldump: [Warning] Using a password on the command line interface can be insecure.
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events. 

# 补充:
# 1.常规备份是要加 --set-gtid-purged=OFF,解决备份时的警告
# [root@db01 ~]# mysqldump -uroot -p123 -A  --set-gtid-purged=OFF  >/backup/full.sql
# 2.构建主从时,做的备份,不需要加这个参数
# [root@db01 ~]# mysqldump -uroot -p123 -A    --set-gtid-purged=ON >/backup/full.sql

-B db1 db2 db3 备份多个单库

说明：生产中需要备份，生产相关的库和MySQL库
例子2 :
mysqldump -B mysql gtid --set-gtid-purged=OFF >/data/backup/b.sql 

不加参数，备份单个或多个表

例子3 world数据库下的city,country表
mysqldump -uroot -p world city country >/backup/bak1.sql
以上备份恢复时:必须库事先存在,并且ues才能source恢复

三、高级参数

每周日 23:00全备，周1-6 binlog备份。所有备份是完整的。
周三时，有一个核心运维人员进行了删库操作。
思路：恢复全备 + 所有需要binlog恢复
痛点：binlog的截取
起点：起点查找比较困难
方法一：备份开始时，切割日志。 -F
方法二：备份开始时，自动记录日志文件信息 --master-data=2
终点：drop之前的位置点

–master-data=2

以注释的形式,保存备份开始时间点的binlog的状态信息

mysqldump -uroot -p  -A  -R --triggers --master-data=2   >/back/world.sql
[root@db01 ~]# grep 'CHANGE' /backup/world.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000035', MASTER_LOG_POS=194;

功能：
（1）在备份时，会自动记录，二进制日志文件名和位置号
0  默认值
1  以change master to命令形式，可以用作主从复制
2  以注释的形式记录，备份时刻的文件名+postion号
（2）自动锁表
（3）如果配合--single-transaction，只对非InnoDB表进行锁表备份，InnoDB表进行“热“”备，实际上是实现快照备份。

–single-transaction

对于innodb 存储引擎开启热备(快照备份)功能  ———— 开启一个独立事务，获取一致性快照，进行备份     
master-data可以自动加锁
（1）在不加--single-transaction ，启动所有表的温备份，所有表都锁定
（1）加上--single-transaction ,对innodb进行快照备份,对非innodb表可以实现自动锁表功能

❤例子6: 备份必加参数
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql

–set-gtid-purged=auto

auto , on
off 
使用场景:
1. --set-gtid-purged=OFF,可以使用在日常备份参数中.
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql
2. auto , on:在构建主从复制环境时需要的参数配置
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=ON >/data/backup/full.sql

–max-allowed-packet=#

mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF --max-allowed-packet=256M >/data/backup/full.sql

 --max-allowed-packet=# 
The maximum packet length to send to or receive from server.

数据包大小默认是4M。超过4M就会拒绝。因此要利用参数 --max-allowed-packet=#

补充（了解）：

-R            备份存储过程及函数
--triggers    备份触发器
-E            备份事件

例子4:
[root@db01 backup]# mysqldump -uroot -p -A -R -E --triggers >/data/backup/full.sql
(5) 特殊参数2使用

-F 在备份开始时,刷新一个新binlog日志

例子5:
mysqldump -uroot -p  -A  -R --triggers -F >/bak/full.sql

mysqldump + binlog 故障恢复案例

案例场景：

• 基础环境：Centos 7.6 + MySQL 5.7.28，LNMT 网站业务，数据量100G，每天5-10M数据增长。
• 备份策略：mysqldump 每天全备，binlog定时备份。
• 故障说明：周三上午10点数据故障，例如：核心业务库被误删除

恢复思路：

• 1.挂维护页。
• 2.找测试库。
• 3.恢复周二全备。
• 4.截取周二全备——》周三上午10点误删除之前的binlog，并恢复
• 5.测试业务功能正常
• 6.恢复业务：
  方案1：故障库导回到原生产
  方案2：直接用测试库称当生产，先跑着。

模拟数据损坏及恢复：
1.模拟原始数据

create database mdp charset utf8mb4;
use mdp;
create table t1(id int);
begin;
insert into t1 values(1),(2),(3);
commit;

2.模拟周二晚上全备

mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M > /data/back/full_`date +%F`.sql

出现错误Binlogging on server not active

vim /etc/my.cnf 
去掉mysqld下的log_bin前面的注释 并且改成
log_bin=mysql-bin

3.模拟周三白天的数据变化

use mdp;
create table t2(id int);
insert into t2 values(1),(2),(3);
commit;

4.搞破坏

drop database mdp;

5.开始恢复

5.1 检查全备
在备份好的sql文件找到这句话
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

5.2 恢复全备
在5.7之后，默认备份的sql文件就已经包含sql_log_bin=0，这里只是为了严谨

mysql> set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)

mysql> source /data/back/full_2020-06-03.sql

5.3 截取binlog
起点：grep “-- CHANGE MASTER TO” /data/back/full_2020-06-03.sql

– CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000001’, MASTER_LOG_POS=154;

终点：
show master status;
show binlog events in ‘musql-bin.000001’;

position截取

mysqlbinlog --skip-gtids --start-position=648 --stop-position=729 /data/binlog/mysql-bin.000001 > /tmp/binlog.sql

GTID截取：

5.4 恢复binlog

mysql> set sql_log_bin=0;
mysql> source /tmp/binlog.sql
mysql> set sql_log_bin=1;

mysqldump小结：

参数：-u -p -S -h -p
     -A -B --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64
选择场景： 数据流较少

四、小练习

1.实现所有表的单独备份

提示：
information_schema.tables
mysqldump -uroot -p123 world city >/backup/world_city.sql

select concat("mysqldump -uroot -p123 ",table_schema," ",table_name," --master-data=2 --single-transaction --set-gtid-purged=0  -R -E --triggers>/backup/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema');

2.模拟故障案例并恢复

（1）每天全备
（2）binlog日志是完整
（3）模拟白天的数据变化
（4）模拟下午两点误删除数据库

需求： 利用全备+binlog回复数据库误删除之前。
故障模拟及恢复：
1. 模拟周一23:00的全备
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql
2. 模拟白天的数据变化
Master [(none)]>create database day1 charset utf8;
Master [(none)]>use day1
Master [day1]>create table t1(id int);
Master [day1]>insert into t1 values(1),(2),(3);
Master [day1]>commit;
Master [world]>update city set countrycode='CHN';
Master [world]>commit;
模拟磁盘损坏：
[root@db01 data]# \rm -rf /data/mysql/data/*
3. 恢复故障
[root@db01 data]# pkill mysqld
[root@db01 data]# \rm -rf /data/mysql/data/*

4. 恢复思路
1.检查备份可用性
2.从备份中获取二进制日志位置
3.根据日志位置截取需要的二进制日志
4.初始化数据库,并启动
5.恢复全备
6.恢复二进制日志

3.压缩备份并添加时间戳

例子：
mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz
mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F-%T).sql.gz

mysqldump备份的恢复方式（在生产中恢复要谨慎，恢复会删除重复的表）
set sql_log_bin=0;
source /backup/full_2018-06-28.sql

注意：
1、mysqldump在备份和恢复时都需要mysql实例启动为前提。
2、一般数据量级100G以内，大约15-45分钟可以恢复，数据量级很大很大的时候（PB、EB）
3、mysqldump是覆盖形式恢复的方法。

一般我们认为，在同数据量级，物理备份要比逻辑备份速度快.
逻辑备份的优势:
1、可读性强
2、压缩比很高

4.从mysqldump 全备中获取库和表的备份

1、获得表结构
# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `city`/!d;q'  full.sql>createtable.sql

2、获得INSERT INTO 语句，用于数据的恢复
# grep -i 'INSERT INTO `city`'  full.sqll >data.sql &

3.获取单库的备份
# sed -n '/^-- Current Database: `world`/,/^-- Current Database: `/p' all.sql >world.sql

五、MySQL物理备份工具-xtrabackup(XBK、Xbackup)

安装依赖包

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev

下载软件并安装

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm

https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

备份方式——物理备份

（1）对于非Innodb表（比如 myisam）是，锁表cp数据文件，属于一种温备份。
（2）对于Innodb的表（支持事务的），不锁表，拷贝数据页，最终以数据文件的方式保存下来，把一部分redo和undo一并备走，属于热备方式。

面试题： xbk 在innodb表备份恢复的流程

  0、xbk备份执行的瞬间,立即触发ckpt,已提交的数据脏页,从内存刷写到磁盘,并记录此时的LSN号
  1、备份时，拷贝磁盘数据页，并且记录备份过程中产生的redo和undo一起拷贝走,也就是checkpoint LSN之后的日志
  2、在恢复之前，模拟Innodb“自动故障恢复”的过程，将redo（前滚）与undo（回滚）进行应用
  3、恢复过程是cp 备份到原来数据目录下