实验环境此次实验的环境如下

• MySQL 5.7.25

• Redhat 6.10

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备份过程

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

backup lock 包括如下三个命令：

• LOCK TABLES FOR BACKUP

• LOCK BINLOG FOR BACKUP

• UNLOCK BINLOG

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

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

• InnoDB拷贝完之后执行执行LOCK TABLES FOR BACKUP命令阻止非InnoDB表的DML操作

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

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

• 之后拷贝改变redo日志

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

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

注意上述过程为Percona Server 5.6及以上，对于社区版的MySQL使用的是如下命令进行上锁

• FLUSH NO_WRITE_TO_BINLOG TABLES

• FLUSH TABLES WITH READ LOCK

这意味着当备份完innodb表后，非innodb的表会导致全局的读锁，即不允许DML操作

另外如果备份时有长时间未结束的语句或者系统繁忙时，FLUSH TABLES WITH READ LOCK会消耗很长时间，将导致数据库长时间无法DML操作

所以建议MySQL不要使用MyISAM引擎的表并在系统空闲时进行备份

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/xtrabackup/tutorial1