记录 MySQL的学习过程 ( 13） 数据备份

1.备份恢复

工作职责
备份策略的设计

a.备份周期 根据数据量 60G左右的数据用mysqldump日备份即可约半小时左右 达到1TB可以考虑周备份使用第三方工具备份

b.备份工具  mysqldump  XBK (percona Xtrabackup) mysqlbinlog


c.备份方式  全备份 增量备份

2.逻辑备份

mysqldump 只能实现全备。所以要靠binlog实现增量备份，要先flush logs 然后cp走相应文件


3.物理备份

XBK 无论全备还是增量都没有问题，而且速度快


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

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

物理备份优点：
1.类似于直接cp数据文件，不需要管逻辑结构，相对来说性能较高

物理备份缺点：
2.可读性差
3.压缩比低，需要更多磁盘空间
建议：
>100G<TB



4.备份的类型

   热备  业务影响最小   innodb

   温备  长时间锁表备份  myisam

   冷备  停业务备份


5.检查备份的可用性

crontab -l 查看计划任务 >> 备份脚本 >> 备份路径 >> 备份日志 >> 备份文件


定期的恢复演练


6.备份工具


mysqldump

客户端通用参数

-u  -p   -S   -h  -P    
本地备份:
mysqldump -uroot -p  -S /tmp/mysql.sock
远程备份:
mysqldump -uroot -p  -h 10.0.0.51 -P3306

7.备份专用基本参数

-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
以上备份恢复时:必须库事先存在,并且use才能source恢复


如果是下面这样
mysqldump -uroot -p world >/backup/bak1.sql
以上备份了world库中的所有表


8.备份专用特殊参数

备份时必加的3个参数

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

例:
[root@db01 backup]# mysqldump -uroot -p -A -R -E --triggers >/data/backup/full.sql


其他参数

--master-data=2

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

mysqldump -uroot -p  -A  -R --triggers --master-data=2   >/back/full.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表可以实现自动锁表功能



--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


9.总结
备份必加参数
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql


 
10.补充

--max-allowed-packet=#

备份大数据库时备份时最好加上这个参数，否则会报错 超出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.


压缩备份并添加时间戳

例子：
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、压缩比很高


11.补充技巧

可以使用 into outfile 命令 将一些select的数据直接转存文件，但要注意要在my.cnf中设置安全路径

mysql> select concat("alter table ",table_schema," ",table_name," discard tablespace;") from information_schema.tables where table_schema='world' into outfile '/tmp/discard.sql';
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement


没有设置就报错了，此时记得加上secure-file-priv=
现在就可以导出了


也可以直接导出csv

select * from City into outfile '/tmp/city.csv'


12.企业故障恢复案例

背景环境：
正在运行的网站系统，mysql-5.7.20 数据库，数据量50G，日业务增量1-5M。


备份策略：
每天23:00点，计划任务调用mysqldump执行全备脚本


故障时间点：
年底故障演练:模拟周三上午10点误删除数据库，并进行恢复.

思路：

1、停业务，挂维护页面，避免数据的二次伤害

2、找一个临时库，恢复周三23：00全备

3、截取周二23：00  --- 周三10点误删除之间的binlog，恢复到临时库

4、测试可用性和完整性

5、
    
5.1 方法一：直接使用临时库顶替原生产库，前端应用割接到新库
    
5.2 方法二：将误删除的表导出，导入到原生产库

6、开启业务
处理结果：经过20分钟的处理，最终业务恢复正常





实操

a.准备数据
create database backup;
use backup
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;

mysql> show tables;
+------------------+
| Tables_in_backup |
+------------------+
| t1               |
+------------------+
1 row in set (0.00 sec)

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)


b.周二 23：00全备

# mkdir /backup

mysqldump -uroot -p123 -A  -R  --triggers --set-gtid-purged=OFF --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz


c.模拟周二 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;

mysql> show tables;
+------------------+
| Tables_in_backup |
+------------------+
| t1               |
| t2               |
+------------------+
2 rows in set (0.00 sec)

mysql> select * from t2;
+------+
| id   |
+------+
|   11 |
|   22 |
|   33 |
+------+
3 rows in set (0.00 sec)

d.模拟故障,删除表

drop database backup;


e.准备临时数据库（多实例3308）

systemctl start mysqld3307

f.准备备份

（1）准备全备：
cd /backup
gunzip full_2018-10-17.sql.gz
（2）截取二进制日志
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=753; #从全备的文件头部可以获得binlog的起点,即753

下面找终点

show binlog events in 'mysql-bin.000001'; #对应全备的头文件中的binlog文件

然后找到drop前的终点 1519

最后的命令如下

mysqlbinlog --skip-gtids --start-position=753 --stop-position=1519 /data/binlog/mysql-bin.000001>/backup/bin.sql

注意:只要开启了gtid 那么截取时一定要使用--skip-gtids 这个参数


g.恢复备份到临时库

mysql -S /data/3307/mysql.sock
set sql_log_bin=0;
source /backup/full_2018-10-17.sql
source /backup/bin.sql


h.将故障表导出并恢复到生产
mysqldump   -S /data/3307/mysql.sock -B backup >/backup/backup.sql
mysql -uroot -p123
set sql_log_bin=0
source /backup/backup.sql;

上面的例子是恢复backup这个库，如果恢复这个backup库中的某一张表，此处从导出命令则为
mysqldump   -S /data/3307/mysql.sock backup t1 >/backup/t1.sql

13.练习

1.创建数据库
mysql> create database oldboy charset utf8mb4;
Query OK, 1 row affected (0.00 sec)

mysql> use oldboy;
Database changed

2.新建一张表
mysql> create table t1(id int);
Query OK, 0 rows affected (0.02 sec)

3.插入几条数据
mysql> insert into t1 values(1),(2),(3),(4),(5);
Query OK, 5 rows affected (0.04 sec)

commit;
Query OK, 0 rows affected (0.00 sec)

4.全备份

# mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers > /backup/full.sql


5.插入2行数据，修改3行数据，删除1行数据


mysql> insert into t1 values(6),(7),(8);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)


mysql> update t1 set id=10 where id>5;
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)


mysql> delete from t1 where id=5;
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.01 sec)

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|   10 |
|   10 |
|   10 |
+------+
7 rows in set (0.00 sec)

6.删除t1表的所有数据

mysql> delete from t1;
Query OK, 7 rows affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t1;
Empty set (0.00 sec)

7.再次向t1中插入数据

mysql> insert into t1 values(1),(2),(3),(4),(5);
Query OK, 5 rows affected (0.01 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> update t1 set id=10 where id>2;
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|   10 |
|   10 |
|   10 |
+------+
5 rows in set (0.00 sec)


要求恢复数据，但是要跳过第6步


思路，先恢复全备，然后截取1-5步 再截取第7步




从备份文件的头部拿到以下数据

SET @@GLOBAL.GTID_PURGED='ba10b7ce-0abb-11eb-8af3-000c296233b6:1-10';

--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=818

看这一句

SET @@GLOBAL.GTID_PURGED='ba10b7ce-0abb-11eb-8af3-000c296233b6:1-10';

这尾部的1-10的意思是 备份文件已经包含了1-10了，所以算备份操作后的起点就是10+1=11


然后看

show binlog events in 'mysql-bin.000005'

可以发现全备操作后对应gtid是11-16 ，而且对应的第6步是 gtid 14的事务


开始截取sql

mysqlbinlog --skip-gtids --include-gtids='ba10b7ce-0abb-11eb-8af3-000c296233b6:11-16' --exclude-gtids='ba10b7ce-0abb-11eb-8af3-000c296233b6:14' /data/binlog/mysql-bin.000005 > /backup/bin.sql;


开始恢复数据

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

source /backup/full.sql;

source /backup/bin.sql;


最后的结果为

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|   10 |
|   10 |
|   10 |
|   10 |
|   10 |
|    1 |
|    2 |
|    3 |
|    4 |
|   10 |
+------+
12 rows in set (0.00 sec)

满足了要求


14.物理备份

Percona-XtraBackup的安装

安装依赖

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


由于xtrabackup依赖于/etc/my.cnf所以
安装后要在my.cnf后增加一行

[xtrabackup]
socket=/tmp/mysql.sock



查看版本

# innobackupex --version
xtrabackup: recognized server arguments: --datadir=/data/mysql/data --server-id=6 --log_bin=/data/binlog/mysql-bin
innobackupex version 2.4.12 Linux (x86_64) (revision id: 170eb8c)



15.备份的过程

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

xbk 在innodb表备份恢复的流程

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


16.全备份

innobackupex --user=root --password=123 --no-timestamp /backup/full

其中 如果不加--no-timestamp的话就会按照时间戳建立文件夹，因为要自订文件夹，所以加上这个参数
如果想把日志单独存放 可以在后面加上 &>/tmp/xbk.log


17.恢复

恢复时如果使用xbk恢复则需要恢复的数据目录中为空，所以一般不使用xbk的恢复而使用手动恢复，步骤如下：

下面模拟全挂掉的恢复

# pkill mysqld

# rm -fr /data/mysql/data/*


恢复前要模拟CSR 操作如下

# innobackupex --apply-log /backup/full

开始恢复数据

# innobackupex --copy-back /backup/full

重新赋权
# chown -R mysql.mysql /data/mysql/data/*



来看备份数据的结构

# ll /backup/full
total 131128
drwxr-x---. 2 root root       76 Oct 12 19:32 backup
-rw-r-----. 1 root root      487 Oct 12 19:32 backup-my.cnf
-rw-r-----. 1 root root      475 Oct 12 19:32 ib_buffer_pool
-rw-r-----. 1 root root 12582912 Oct 12 20:01 ibdata1
-rw-r-----. 1 root root 50331648 Oct 12 20:01 ib_logfile0
-rw-r-----. 1 root root 50331648 Oct 12 20:01 ib_logfile1
-rw-r-----. 1 root root 12582912 Oct 12 20:01 ibtmp1
drwxr-x---. 2 root root     4096 Oct 12 19:32 mysql
drwxr-x---. 2 root root       48 Oct 12 19:32 oldboy
drwxr-x---. 2 root root     8192 Oct 12 19:32 performance_schema
drwxr-x---. 2 root root     8192 Oct 12 19:32 sys
-rw-r-----. 1 root root       63 Oct 12 19:32 xtrabackup_binlog_info
-rw-r--r--. 1 root root       22 Oct 12 20:01 xtrabackup_binlog_pos_innodb
-rw-r-----. 1 root root      113 Oct 12 20:01 xtrabackup_checkpoints
-rw-r-----. 1 root root      554 Oct 12 19:32 xtrabackup_info
-rw-r-----. 1 root root  8388608 Oct 12 20:01 xtrabackup_logfile
-rw-r--r--. 1 root root        1 Oct 12 20:01 xtrabackup_master_key_id



其中 大部分文件就是mysql的data里面的文件


xtrabackup_binlog_info         记录备份时刻的 binlog的信息，可以作为binlog截取的起点

# cat xtrabackup_binlog_info
mysql-bin.000007        194     ba10b7ce-0abb-11eb-8af3-000c296233b6:1-17
   相关文件           备份时的postion号码       gtid的号码
      
xtrabackup_checkpoints

# cat xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0                备份中包含的lsn的起点，从0开始代表全备份，如果是增量的话则会是上次备份的结束位置
to_lsn = 3935260            ckpt时的lsn号码
last_lsn = 3935269          备份完成后的lsn号码（此处数字-9则是下次增量备份的起始位置）
compact = 0
recover_binlog_info = 0

如果 to_lsn 和 last_lsn 差9的话，则说明备份过程中没有新的数据变化

xtrabackup_info             汇总信息
xtrabackup_logfile          备份过程中的redo信息




18.下面开始实战增量备份

先清空之前的备份目录


rm -fr /backup/full/*


模拟一些数据

mysql> create database full charset utf8mb4;
Query OK, 1 row affected (0.01 sec)

mysql> use full;
Database changed
mysql> create table t1 (id int);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 values (1),(2),(3);
Query OK, 3 rows affected (0.06 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)


模拟周日全备

# innobackupex --user=root --password=123 --no-timestamp /backup/full


检查备份

# cat /backup/full/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 3941806
last_lsn = 3941815
compact = 0
recover_binlog_info = 0


模拟周一的数据变化

mysql> create database inc1 charset utf8mb4;
Query OK, 1 row affected (0.01 sec)

mysql> use inc1;
Database changed

mysql> create table t1(id int);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 values (1),(2),(3);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)


开始周一的增量备份



# innobackupex --user=root --password=123 --no-timestamp --incremental-basedir=/backup/full  /backup/inc1  --incremental


其中 --incremental 为打开增量备份
     --incremental-basedir 为基于哪个备份进行增量（第一次就是全备，第二次就是上一个增量备份）
     /backup/inc1  为备份的位置



此时观察 full与inc1的checkpoints信息


# cat /backup/inc1/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 3941806
to_lsn = 3948441
last_lsn = 3948450
compact = 0
recover_binlog_info = 0

# cat /backup/full/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 3941806
last_lsn = 3941815
compact = 0
recover_binlog_info = 0

可以发现

增量的from_lsn就是full的last_lsn-9



模拟周二的数据变化


mysql> create database inc2 charset utf8mb4;
Query OK, 1 row affected (0.01 sec)

mysql> use inc2;
Database changed

mysql> create table t1(id int);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 values (1),(2),(3);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)



开始周二的增量备份


# innobackupex --user=root --password=123 --no-timestamp --incremental-basedir=/backup/inc1  /backup/inc2  --incremental

此时观察chekpoint


# cat /backup/full/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 3941806
last_lsn = 3941815
compact = 0
recover_binlog_info = 0、

# cat /backup/inc1/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 3941806
to_lsn = 3948441
last_lsn = 3948450
compact = 0
recover_binlog_info = 0

# cat /backup/inc2/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 3948441
to_lsn = 3954341
last_lsn = 3954350
compact = 0
recover_binlog_info = 0


印证了之前的观点 前面的last_lsn实际上就是后面的from_lsn-9


模拟周三的数据变化


mysql> create database inc3 charset utf8mb4;
Query OK, 1 row affected (0.01 sec)

mysql> use inc3;
Database changed

mysql> create table t1(id int);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 values (1),(2),(3);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)


模拟故障


现在数据库挂掉了

# pkill mysqld
rm -fr /data/mysql/data/*


恢复思路

 挂维护页面停业务

 查找可用备份

 full+inc1+inc2+binlog

 恢复

 验证

 启动业务，撤维护页

 
 理论上是先处理模拟csr 然后将所有增量备份合并到全备中，最后恢复全备，不过这些操作也可以合并到一起操作

 a.整理全备 full

 # innobackupex --apply-log --redo-only /backup/full

 这里面的--redo-only 是只做redo不做undo（rollback） ，一般在整理全备+所有的增量合并时（除了最后一个增量）使用，换句话说就是当还原操作包含全备+增量备份时使用这个参数，而且多个增量备份的话，最后一个增量不用加这个参数


 b.合并inc1到full，并整理备份

 #innobackupex --apply-log --redo-only --incremental-dir=/backup/inc1 /backup/full


 现在来看一下合并后的变化

 # cat /backup/inc1/xtrabackup_checkpoints
 backup_type = incremental
 from_lsn = 3941806
 to_lsn = 3948441
 last_lsn = 3948450
 compact = 0
 recover_binlog_info = 0

 # cat /backup/full/xtrabackup_checkpoints
 backup_type = log-applied
 from_lsn = 0
 to_lsn = 3948441
 last_lsn = 3948450
 compact = 0
 recover_binlog_info = 0

 合并前的full的chkpoint

 # cat /backup/full/xtrabackup_checkpoints
 backup_type = full-backuped
 from_lsn = 0
 to_lsn = 3941806
 last_lsn = 3941815
 compact = 0
 recover_binlog_info = 0

 可以发现合并后的full里面的last_lsn和inc1里面的last_lsn一致了，也就是说full里面的备份已经包含inc1了



 c.合并inc2到full，并整理备份

 #innobackupex --apply-log --incremental-dir=/backup/inc2 /backup/full

  因为是最后一次的增量 所以没有哪个redoonly的参数

  # cat /backup/full/xtrabackup_checkpoints
  backup_type = full-prepared
  from_lsn = 0
  to_lsn = 3954341
  last_lsn = 3954350
  compact = 0
  recover_binlog_info = 0
  # cat /backup/inc2/xtrabackup_checkpoints
  backup_type = incremental
  from_lsn = 3948441
  to_lsn = 3954341
  last_lsn = 3954350
  compact = 0
  recover_binlog_info = 0

  由此发现full里面也包含了inc2了，所以应该挂差这里面的last_lsn信息，如果对不上，则恢复的备份会存在问题


 d.最后一次整理full

 #innobackupex --apply-log  /backup/full

 e.还有binlog需要截取

 因为是在做完inc2增量备份以后出现的问题，所以binlog的起点直接查看xtrabackup_binlog_info文件即可

  cat /backup/inc2/xtrabackup_binlog_info
  mysql-bin.000008        1995    6d1faae6-0c84-11eb-a281-000c296233b6:1-9,
  ba10b7ce-0abb-11eb-8af3-000c296233b6:1-17

  因为有多个gtid，所以需要确认到底哪个才是我们需要的，使用下面命令查询

  # mysqlbinlog /data/binlog/mysql-bin.000008

  最后发现是 6d1faae6-0c84-11eb-a281-000c296233b6:1-9 这一个，因为备份中包含了1-9 那么截取就从10开始，下面是到多少结束

  从上面的000008日志的最后一行可以看到是到了12，或者也可以使用下面的命令
 
  # mysqlbinlog /data/binlog/mysql-bin.000008 | grep '6d1faae6-0c84-11eb-a281-000c296233b6'

  直接看最后一个就是12


  下面开始截取

   mysqlbinlog --skip-gtids --include-gtids='6d1faae6-0c84-11eb-a281-000c296233b6:10-12' /data/binlog/mysql-bin.000008>/backup/binlog.sql
 
  开始恢复

  # cp -a /backup/full/* /data/mysql/data/

  # chown -R mysql.mysql /data/mysql/data

  # systemctl start mysqld


  mysql> set sql_log_bin=0;

  mysql> source /backup/binlog.sql

  到此为止，数据恢复完成


  验证数据发现数据都ok





19.备份集中单独恢复表

思考:在之前的项目案例中,如果误删除的表只有10M,而备份有500G,该如何快速恢复误删除表?

当使用xbk做完恢复后得到一个目录/backup/full 其中就有相关库的文件，可以利用文件的思路恢复


drop table city;
create table city like city_bak;
alter table city discard tablespace;
cp /backup/full/world/city.ibd  /application/mysql/data/world/
chown -R mysql.mysql  /application/mysql/data/world/city.ibd
alter table city import  tablespace;


 从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



20.简易测试当前磁盘io速度


# dd if=/dev/zero of=/data/bigfile bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 10.0883 s, 213 MB/s

21.数据迁移

5.6.49 --->  5.7.26   

先留着，暂时先不做了