xtrabackup备份原理及流式备份应用

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不同的版本：

  1. 8.0 ： MySQL 8.0 以上版本
  2. 2.4 ： MySQL 5.7 版本
  3. 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
  1. xbcloud, xbcloud_osenv : 是xtrabackup新的高级特性云备份
  2. xbcrypt : 支持加密备份
  3. xbstream : 支持流式备份功能。可以将备份的内容打包并通过管道传递
  4. xtrabackup : 是备份功能的主程序
  5. innobackupex : 这个工具在之前的版本中是一个perl脚本，会调用xtrabackup这个二进制工具。从xtrabackup 2.3开始，该工具使用C语言进行了重写，当前它是xtabackup二进制工具的一个软连接，但是实际的使用方法却不同，并且在以后的版本中会删除该工具。

因为innobackupex在后续版本中已经不存在。因此本文将会主要介绍xtrabackup的备份恢复方法和原理。

2. xtrabackup 备份和恢复原理

对于xtrabackup备份和恢复数据的过程总体分为3个阶段：

  1. 备份（backup）
  2. 准备（prepare）
  3. 恢复（copy-back 或move-back）

2.1 备份阶段（backup）

对于MySQL的备份，在大部分的情况下需要完成以下两种类型的数据的备份：

  1. innodb 存储引擎数据的备份。
  2. 非事务引擎的数据备份，例如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详解)：

  1. 上全局读锁(lock_global_read_lock)：阻塞所有的更新操作。
  2. 清理表缓存(close_cached_tables)：关闭表缓存。
  3. 上全局COMMIT锁(make_global_read_lock_block_commit)：阻塞活跃的事务提交。

FTWRL的操作中会阻塞包括innodb在内的所有存储引擎的更新操作。在FTWRL执行的过程中，整个数据库相当于只读模式。可见如果在线上数据库中(尤其在承担线上读写业务的数据库下)，使用FTWRL可能会导致线上数据库长时间陷入不可写入的状态。对于这个问题percona版本的MySQL做出了优化，将FTWRL 分为了几个部分：

  1. lock table for backup : 这个锁会阻塞所有对非事务表的更新及所有DDL动作，但是innodb表的读写可以继续执行。
  2. 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集群存在如下的痛点：

  1. 备份磁盘空间不足：随着线上数据的增长，大部分MySQL数据库都没有预留足够的备份空间，因此当前每次在本地备份数据都会导致磁盘空间报警。在DBA处理不及时的情况下，容易导致磁盘空间占满而影响服务。

而xtrabackup正好有流式备份的功能，能够解决当前DBA的痛点。因此本小节将主要介绍下xtrabackup的流式备份功能(stream模式)。

当前 xtrabackup支持2种方式的流式备份：

  1. tar格式（ps : tar 和ssh还有很多有意思的功能，具体可以参考使用tar+pigz+ssh实现大数据的高效传输 ）
  2. 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. 配置从机器1免密ssh登录机器2。
  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  root@192.168.100.2  "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 mysql@192.168.100.2  " 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 mysql@192.168.100.2  "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 mysql@192.168.100.2  "cat -  | xbstream  -x -C /ssd/100_1_bak/" ### 使用--compress选项压缩

4. 总结

本文主要介绍了xtrabackup备份的原理以及流式备份功能。限于本文的作者水平有限，文中的错误在所难免，恳请大家批评指正。

posted @ 2019-11-06 10:31  bush2582  阅读(3871)  评论(0)  编辑  收藏  举报