Xtrabackup 不备份 binlog 怎么保证一致性？

又已知：Xtrabackup 在恢复备份后，会进行类似于 crash recovery 的动作(将备份的 redo log 的内容回放到数据中, 并对事务进行提交/回滚)，那么 Xtrabackup 为什么不需要备份 binlog 文件？

想了一下好像不是能一句话说清楚的，我来尝试解答下。

答：

备份时全局锁阶段做的操作：

2020-08-17T09:58:36.167905+08:00         2116 Query     FLUSH TABLES WITH READ LOCK
2020-08-17T09:58:36.490928+08:00         2116 Query     SHOW VARIABLES
2020-08-17T09:58:36.498670+08:00         2116 Query     SHOW SLAVE STATUS
2020-08-17T09:58:36.499435+08:00         2116 Query     SHOW MASTER STATUS
2020-08-17T09:58:36.499747+08:00         2116 Query     SHOW VARIABLES
2020-08-17T09:58:36.503341+08:00         2116 Query     FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
2020-08-17T09:58:36.704273+08:00         2116 Query     UNLOCK TABLES

这里最主要是要保证两点：

• 非事务数据之间一致性；

• 数据和 binlog 位点的一致性。

crash recovery 过程要保证“数据和binlog的一致”，因为 crash 后不能出现事务重做提交而 binlog 没记录的情况，这样会导致从库丢失数据。那备份需要考虑的是什么？有两点：

• 备份恢复后，再基于 binlog 做精确恢复时，--start-position 的位置是正确的，不会重放、漏掉事物；

• 备份恢复后，作为从库向主库复制数据时，复制起始位置是正确的，不会重放、漏掉事物。

首先我们得知道事务二阶段提交过程中的3个队列 flush、sync、commit 都有排他锁，一个大事务 commit 可能需要几秒钟，那么此时执行 FTWRL 是会被阻塞的，commit 结束后才能取得全局锁，取得全局锁后，执行 commit 会被阻塞：

所以在 xtrabackup 的恢复过程，不需要处理 prepare 状态的事务，也就不需要再验证该事务是否在 binlog 中了。

文章至此。

以下是个人微信公众号，欢迎关注：