xtrabackup8.0备份原理简析

MySQL8.0针对物理备份做了定向增强，提供了performance_schema.log_status表以获得一致性的日志点位，包括binlog、redo、gtid、以及checkpoint。

参考文章《MySQL：8.0新的备份锁的浅析及其重要BUG》可以得知，mysql通过log_status表获取一致性点时分别依次锁定了：

1. ordered_commit的flush stage到commit stage全流程，阻塞所有事务进入ordered_commit，确保binlog的点位和gtid不会变化。

2. log_buffer_x_lock_enter，阻塞所有mtr的commit进入log_buffer_s_lock_enter_reserve，确保redo日志的lsn不会增加

3. log_t::checkpointer_mutex（log_checkpointer_mutex_enter(log)），阻塞checkpoint执行，确保checkpoint点位不会移动

xtrabackup8.0针对上述的log_status特性实现纯innodb场景的”无锁“备份，具体的流程如下：

1. 开始备份并检查兼容性

2. 启动后台线程监听并持续拷贝新增redo日志

3. 备份innodb表相关数据文件

4. 执行FLUSH NO_WRITE_TO_BINLOG BINARY LOGS切换出一个新的binlog文件

5. 执行Selecting LSN and binary log position from p_s.log_status 获取一致性的LSN、binlog、gtid点位，分别未lsn_kept、binlog_pos_kept、gtid_kept

6. 拷贝当前最新的一个binlog，并且只拷贝到binlog_pos_kept点位。

7. 执行Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS，确保当前redo都落盘了

8. 确保后台线程对redo日志的拷贝停止在lsn_kept点位

9. 备份完成

上面这个流程除了log_status表查询时的瞬间锁定外，没有其他额外的锁，并且不影响select语句的执行，对于DML语句在触发mtr commit或ordered_commit前也是可以执行的。

上面的步骤时如何保障最后还原出来的数据库点位与log_status是一致的呢，重点是：

1. 上述步骤6，拷贝了最新的binlog。备份恢复过程类似一次mysql crash recover过程，log_status的一致性点位中的lsn_kept并不一定包含了binlog_pos_kept对应事务的提交的redo信息，这个事务就需要recover流程基于binlog将这个事务在还原后实例的引擎层提交上。

xtrabackup2，直接flush table with read lock，不会有在执行中的事务了，所以不需要依赖binlog来recover事务。所以xtrabackup2备份时不备份binlog。

xtrabakcup8.0为了减小拷贝binlog的代价，执行了步骤4，切换出一个新的binlog文件。

2. 步骤7和8，确保lsn_kept落盘了并且确保后台线程只拷贝到lsn_kept，这里是不能更多，因为binlog只拷贝到了binlog_pos_kept，再之后的redo日志将没有对应的binlog信息来做recover判定，并且之后的redo日志点位也与binlog点位不一致。

参考：

1. How Percona XtraBackup works - Percona XtraBackup

2. 想了解Xtrabackup备份原理和常见问题分析，看这篇就够了-华为开发者论坛 | 华为开发者联盟 (huawei.com)

3. xtrabackup2版本和xtrabackup8版本对比 (itxueyuan.com)

4. MySQL：8.0新的备份锁的浅析及其重要BUG - 简书 (jianshu.com)

转载请注明转自高孝鑫的博客！