目录
- xtrabackup备份原理及流式备份应用
- 0. 参考文献
- 1. xtrabackup 安装
- 2. xtrabackup 备份和恢复原理
- 2.1 备份阶段（backup）
- 2.2 准备阶段（prepare）
- 2.3 恢复（copy-back 或move-back）
- 3. xtrabackup 流式备份应用
- 4. 总结
xtrabackup备份原理及流式备份应用
0. 参考文献
| 序号 | 文献 |
|---|---|
| 1 | MariaDB/MySQL备份和恢复(三)：xtrabackup用法和原理详述 |
| 2 | MySQL · 物理备份 · Percona XtraBackup 备份原理 |
| 3 | Streaming and Compressing Backups |
| 4 | How Percona XtraBackup Works |
| 5 | FLUSH TABLE WITH READ LOCK详解 |
| 6 | 为什么要使用FTWRL |
| 7 | 使用tar+pigz+ssh实现大数据的高效传输 |
xtrabackup 是一款开源的MySQL备份解决工具，由percona公司开发完成。相比于MySQL企业版的mysqlbackup 和ibbackup功能强大许多。尤其提供了当前部门需求的流式备份功能，因此在目前看来xtrabackup是一款非常合适的MySQL备份工具。本文将从xtrabackup备份的应用与原理角度介绍xtrabackup。
1. xtrabackup 安装
xtrabackup可以通过多种方式安装。本文在这里选择从https://www.percona.com/downloads/ 下载二进制包的方式安装。在网页中可以看到xtrabackup有4个版本可以选择。这4个版本分别支持MySQL不同的版本：
- 8.0 ： MySQL 8.0 以上版本
- 2.4 ： MySQL 5.7 版本
- 2.2 和 2.3 ： MySQL 5.1, 5.5 和 5.6
当前线上使用的MySQL版本是5.7版本，因此本文所有的内容都是基于2.4版本生成的。如果读者对于8.0 有兴趣，可以阅读其文档：Percona XtraBackup - Documentation
下载下来的文件中，bin目录下会有如下的几个文件：
~/percona-xtrabackup-2.4.15-Linux-x86_64/bin$ ls -la
total 211188
drwxr-xr-x 2 mysql mysql 4096 Oct 12 13:20 .
drwxr-xr-x 6 mysql mysql 4096 Jul 5 16:00 ..
lrwxrwxrwx 1 mysql mysql 10 Jul 5 16:00 innobackupex -> xtrabackup
-rwxr-xr-x 1 mysql mysql 9811072 Jul 5 15:53 xbcloud
-rwxr-xr-x 1 mysql mysql 3020 Jul 5 15:52 xbcloud_osenv
-rwxr-xr-x 1 mysql mysql 5854168 Jul 5 15:53 xbcrypt
-rwxr-xr-x 1 mysql mysql 5942024 Jul 5 15:53 xbstream
-rwxr-xr-x 1 mysql mysql 194628336 Jul 5 15:59 xtrabackup- xbcloud, xbcloud_osenv : 是xtrabackup新的高级特性云备份
- xbcrypt : 支持加密备份
- xbstream : 支持流式备份功能。可以将备份的内容打包并通过管道传递
- xtrabackup : 是备份功能的主程序
- innobackupex : 这个工具在之前的版本中是一个perl脚本，会调用xtrabackup这个二进制工具。从xtrabackup 2.3开始，该工具使用C语言进行了重写，当前它是xtabackup二进制工具的一个软连接，但是实际的使用方法却不同，并且在以后的版本中会删除该工具。
因为innobackupex在后续版本中已经不存在。因此本文将会主要介绍xtrabackup的备份恢复方法和原理。
2. xtrabackup 备份和恢复原理
对于xtrabackup备份和恢复数据的过程总体分为3个阶段：
- 备份（backup）
- 准备（prepare）
- 恢复（copy-back 或move-back）
2.1 备份阶段（backup）
对于MySQL的备份，在大部分的情况下需要完成以下两种类型的数据的备份：
- innodb 存储引擎数据的备份。
- 非事务引擎的数据备份，例如myisam 引擎数据的备份。
在备份的过程中数据库基本处于可读写的状态，因此在这期间需要对于变化的数据进行处理，以便在备份结束时获取正确的备份数据。基于上述的考虑xtrabackup备份的过程主要包括了以下的几个步骤：
拷贝和监控redo log ： 在起始时刻，xtrabackup会先获取MySQL当前时刻的LSN，同时开始拷贝redo log至xtrabackup_logfile文件中。因为在备份的过程中数据库基本处于可读写的状态下，因此redo log会不断的变化，将导致初始拷贝的redo log和MySQL当前的redo log不一致。所以在xtrabackup后台，还会启动另外的一个进程持续监控redo log文件的变化。如果监控到文件发生变化，则将其写入到xtrabackup_logfile中。这个进程会一直存在并执行监控redo log的变化，直到备份将结束为止。
拷贝innodb相关文件：拷贝包括ibdata1(共享表空间)和*.idb(如果开启了独立表空间的话)相关的文件。
加备份锁：因为非innodb表没有redo log可供拷贝，所以在备份非innodb表之前需要对数据库加锁，以防止在备份过程中数据被修改。在这里需要先简单的介绍下备份锁的概念。在各种备份工具备份数据库的过程中，为了获取一致性备份(binlog位置与数据匹配)，需要在备份的过程中加上备份锁。在MySQL中会使用FLUSH TABLES WITH READ LOCK简称(FTWRL)来获取一致性备份。FTWRL会执行如下的几个操作(更具体的介绍和相关原理可以参见FLUSH TABLE WITH READ LOCK详解)：
- 上全局读锁(lock_global_read_lock)：阻塞所有的更新操作。
- 清理表缓存(close_cached_tables)：关闭表缓存。
- 上全局COMMIT锁(make_global_read_lock_block_commit)：阻塞活跃的事务提交。
FTWRL的操作中会阻塞包括innodb在内的所有存储引擎的更新操作。在FTWRL执行的过程中，整个数据库相当于只读模式。可见如果在线上数据库中(尤其在承担线上读写业务的数据库下)，使用FTWRL可能会导致线上数据库长时间陷入不可写入的状态。对于这个问题percona版本的MySQL做出了优化，将FTWRL 分为了几个部分：
- lock table for backup : 这个锁会阻塞所有对非事务表的更新及所有DDL动作，但是innodb表的读写可以继续执行。
- lock binlog for backup：做锁会阻止binlog更新，因此此时所有的DML操作都会被阻塞。
可以看出如果在备份的过程中，将FTWRL拆解成如上的2步操作，则在备份非事务表的过程中可以不阻塞事务表的更新。对于xtrabackup如果备份的数据库是不支持backup lock的版本，则使用FTWRL操作。而如果是支持backup lock的版本，则使用lock tables for backup获取轻量级的backup locks来替代FTWRL。
- 拷贝非innodb表文件。
- 获取binlog一致性位置：在拷贝完所有的数据之后，备份进入收尾阶段。在这里根据是否支持backup lock分为不同的操作。对于不支持backup lock的版本，直接获取binlog的一致性坐标点同时结束redo log的监控和拷贝并释放锁。而对于支持backup lock的版本，先通过lock binlog for bakcup来获取binlog日志锁，然后结束redo log的监控和拷贝，再unlock tables释放表锁，随后获取二进制日志的一致性位置坐标点，最后unlock binlog释放binlog日志锁。
- 结束备份退出。
2.2 准备阶段（prepare）
在恢复备份之前需要对数据进行一些处理，在xtrabackup中称之prepare。这个步骤的主要工作就是将之前记录的redo log应用到innodb的数据中，使得innodb中的数据最终和备份结束的时刻一致。这个步骤不需要在有MySQL的机器上运行，xtrabackup自身实现了一个简化版本的innodb引擎，通过它完成redo log的应用。
2.3 恢复（copy-back 或move-back）
在最后一步，xtrabackup会将数据copy 或者move (如果DBA不打算保留备份数据)到数据库对应的目录下。同样这步也不需要MySQL启动或者存在，可以在任何机器上执行。但是要求对应的数据库目录下是空的，不存在任何的文件。
最后根据如上的叙述可以归纳总结如下：
3. xtrabackup 流式备份应用
当前对于部门的MySQL集群存在如下的痛点：
- 备份磁盘空间不足：随着线上数据的增长，大部分MySQL数据库都没有预留足够的备份空间，因此当前每次在本地备份数据都会导致磁盘空间报警。在DBA处理不及时的情况下，容易导致磁盘空间占满而影响服务。
而xtrabackup正好有流式备份的功能，能够解决当前DBA的痛点。因此本小节将主要介绍下xtrabackup的流式备份功能(stream模式)。
当前 xtrabackup支持2种方式的流式备份：
- tar格式（ps : tar 和ssh还有很多有意思的功能，具体可以参考使用tar+pigz+ssh实现大数据的高效传输 ）
- xbstream格式
在测试xtrabackup备份功能之前需要先准备下实验环境。
| 机器 | IP | CPU | 磁盘 | 内存 |
|---|---|---|---|---|
| 机器1 | 192.168.100.1 | 40核 | 1.1T SSD(已使用60%) | 64G |
| 机器2 | 192.168.100.2 | 40核 | 1.1T SSD(空盘) | 64G |
需要完成的操作是从机器1备份数据到机器2，并且不占用机器1原本不多的剩余磁盘空间。为了能够使用流式备份功能，首先需要在机器2上完成如下2个步骤：
- 配置从机器1免密ssh登录机器2。
- 在机器2上建立存放备份的目录，本例中路径为/ssd/100_1_bak/
tar格式的备份可以选择使用gzip或者不压缩。在本例中分别使用如下命令完成：
xtrabackup --safe-slave-backup --slave_info --user='root' --password='XXXXXX' --backup --tables-file=./tb.txt --stream=tar | ssh [email protected] "cat - | tar -x -C /ssd/100_1_bak/" #### tar 不压缩
xtrabackup --safe-slave-backup --slave_info --user='root' --password='XXXXXX' --backup --tables-file=./tb.txt --stream=tar |pigz | ssh -p32200 [email protected] " gzip -d | tar -x -C /ssd/100_1_bak/" ### 使用tar 流 并交给 gzip 压缩传输ps : xtrabackup没有选项只备份innodb表或者myisam表。但是可以通过选项指定备份的表。在本例中通过--tables-file选项，将需要备份的innodb表写入tb.txt文件中进行备份。生成tb.txt的内容可以使用如下的sql语句获得：
select CONCAT(TABLE_SCHEMA, '.', TABLE_NAME) FROM information_schema.TABLES WHERE ENGINE = 'InnoDB' AND ENGINE IS NOT NULL AND TABLE_SCHEMA NOT IN ( 'mysql', 'performance_schema', 'information_schema', 'sys') ;如果使用xbstream格式，则可以使用如下的命令：
xtrabackup --safe-slave-backup --slave_info --user='root' --password='XXXXXX' --backup --tables-file=./tb.txt --stream=xbstream | ssh -p32200 [email protected] "cat - | xbstream -x -C /ssd/100_1_bak/" ### xbstream不压缩
xtrabackup --safe-slave-backup --slave_info --user='root' --password='XXXXXX' --backup --tables-file=./tb.txt --stream=xbstream --compress | ssh -p32200 [email protected] "cat - | xbstream -x -C /ssd/100_1_bak/" ### 使用--compress选项压缩4. 总结
本文主要介绍了xtrabackup备份的原理以及流式备份功能。限于本文的作者水平有限，文中的错误在所难免，恳请大家批评指正。