django-\/\/ i K | 
  ## 实验环境



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

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

详情请看如下链接

[XtraBackup工具详解](http://www.zhaibibei.cn/mysql/xtrabackup/)

此次实验的环境如下

- 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://www.zhaibibei.cn/mysql/xtrabackup8/tutorial1/](http://www.zhaibibei.cn/mysql/xtrabackup8/tutorial1/)


[上一章](http://www.zhaibibei.cn/mysql/xtrabackup8/tutorial2/)

[下一章](http://www.zhaibibei.cn/mysql/xtrabackup8/tutorial4/)