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

  • 2019 年 11 月 6 日
  • 笔记

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  [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备份的原理以及流式备份功能。限于本文的作者水平有限,文中的错误在所难免,恳请大家批评指正。