讨论:Xtrabackup不备份binlog怎么保证一致性?
问:
有一天从某个地方看到一个有意思的问题:
已知:MySQL 的内部两阶段提交,是为了解决 binlog 和 redo log 的一致性(在 crash recovery 的过程中, 如果发现某个事务的 redo log 已经完成 prepare 阶段, 但未完成 commit,那么会验证该事务是否在 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 位点的一致性。
其中 FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS,是防止 innodb_flush_log_at_trx_commit 不等于 1 ,redo log没有刷到磁盘。
关键在:xtrabackup 只需要保证“数据和 binlog 位点的一致”,而不是“数据和 binlog 的一致”。
crash recovery 过程要保证“数据和binlog的一致”,因为 MySQL crash 后不能出现事务重做提交而 binlog 没记录的情况,这样会导致从库丢失数据。
然而备份是不需要考虑 crash 的,因为备份时 crash,备份肯定失败。所以备份成功,binlog 肯定不会出现和数据不一致的情况。那备份需要考虑的是什么?有两点:
- 备份恢复后,再基于 binlog 做精确恢复时,--start-position 的位置是正确的,不会重放、漏掉事物;
- 备份恢复后,作为从库向主库复制数据时,复制起始位置是正确的,不会重放、漏掉事物。
其实这两点都一样,就是要保证备份时 “数据和 binlog 位点的一致”。那么实现就很简单了,在 FTWRL 期间,show master status 就是记录 binlog 位点,所有不在记录中的事务(没有完成 binlog commit),不管是不是已经完成 prepare 阶段的事务(redo log 已经刷盘),在备份恢复时都要回滚。 所以,xtrabackup 不需要备份 binlog,并且备份恢复的 apply-log 阶段跟 crash recovery 所做的动作是不一样的。
另外还可以推断出:flush tables with read lock 全局锁能让已经 prepare 还未 commit 的事务,不能完成 commit。