实验环境

前面我们介绍了Xtrabackup 2.4版本的介绍，这个专题说8.0版本

大体上差不多，不过8.0版本移除了innobackupex命令且只能备份8.0版本的MySQL

此次实验的环境如下

• MySQL 8.0.19

• Redhat 7.4

1. Percona XtraBackup 备份原理

Percona XtraBackup 利用的是InnoDB的crash-recovery功能

他拷贝非一致状态的InnoDB数据文件,之后利用redo日志对数据文件做恢复以使数据文件一致

这是因为InnoDB维护了一个记录InnoDB数据更改的重做日志(redo log)，也可以称为事务日志

恢复时，Percona XtraBackup检查数据文件和事务日志，之后做两个步骤：

• 将提交过的事务写到数据文件中

• 回滚未提交的事务

Percona XtraBackup 备份开始时，首先记录日志的序号(log sequence number
或者LSN)。之后拷贝数据文件，与此同时，Percona XtraBackup 启动一个后台进程监视重做日志，之后拷贝改变的部分

因为重做日志会被覆盖，所以Percona XtraBackup必须时刻监视着

2. Percona XtraBackup 8.0 备份过程

Percona Server 5.6开始，Percona XtraBackup新增了backup lock特性，他相对与
FLUSH TABLES WITH READ LOCK来说更加的轻量级，使用它可以在不影响InnoDB表的DML操作下拷贝非InnoDB数据

而MySQL从8.0才开始支持backup lock特性，通过LOCK INSTANCE FOR BACKUP和
LOCK TABLES FOR BACKUP 命令来实现，可以做到备份时不锁表。

最后大体上xtrabackup的步骤如下:

• 首先会记录LSN位置并拷贝InnoDB数据文件并持续跟踪LSN变化

• InnoDB拷贝完之后执行LOCK TABLES FOR BACKUP 命令加备份锁，这时可以做DML操作和DDL操作，是通过performance_schema.log_status这个表来实现协调

• 之后拷贝非InnoDB数据文件，如MyISAM等

• 之后执行LOCK BINLOG FOR BACKUP命令阻止所有可能更改二进制日志位置或者GTID的操作

• 之后拷贝改变redo日志

• 最后释放二进制日志和表的锁(UNLOCK BINLOG)

这样就保证了备份完成后innodb和非innodb的数据是一致的

3. Percona XtraBackup还原原理

使用 xtrabackup --copy-back 或 xtrabackup --move-back将备份的文件还原到一个目录

相当于Oracle的restore

默认情况下,  它会读取my.cnf文件中的datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir变量并检查目录是否存在

还原文件的顺序如下:

• 首先是MyISAM的表和索引以及其他非innodb的数据(如.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par and .opt 文件)

• 之后拷贝innodb的表和索引

• 最后是redo log

之后是恢复数据，相当与oracle的recover，即使用redo log做恢复以使数据达到一致状态

4. 参考资料

本专题所有内容翻译子Percona XtraBackup的官方文档

可通过如下链接下载

http:///mysql/xtrabackup8/tutorial1/