xtrabackup8:无全局锁备份原理浅析

参考资料

https://mp.weixin.qq.com/s/vl9RscCswHhl2D2jsj15EQ

xtrabackup2.4 FTWRL 的作用

众所周知，xtrabackup2.4 备份 MySQL5.7 时，在备份完 InnoDB 表后，会加全局锁 FTWRL（即：flush tables with read lock），然后做以下关键操作：

• 备份非 InnoDB 表（比如 mysql 库下的表）
• 获取 binlog position、GTID、redo log LSN
• 对 redo log 刷盘、 redo log 全部拷贝完之后结束拷贝

做完这些后，就会解锁，基本上备份也就结束了。xtrabackup 备份的数据在恢复时需要应用 redo log 前滚到一个位置，这个位置就是刚提到的 redo log LSN，让数据最终处于一个一致性快照中；并且这个数据还需要与binlog position、GTID一致，因为后续可能还需要基于 binlog 做增量恢复或者复制（这就需要 binlog position、GTID 作为起始位置）。

FTWRL 是这样来保证上述一致性的：

• 所有修改数据的操作都会被阻塞，所以不会再写 redo log（包括 redo log buffer），LSN 不会再变化，此时对 redo log 刷盘（FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS），内存中所有的 redo log 都将被刷盘，拷贝到的 redo log 是完整的，并且和获取到的 redo log LSN 一致；
• 阻塞事务提交（FTWRL 与事务提交的排他锁互斥），这保证了备份的数据中只有两类事务：还没提交的、提交完成的，不存在 prepare 状态的事务；另外此期间获取的 binlog positon、GTID 也是静止的。

然后在备份恢复阶段（--apply-log），redo log 重做的截止位置就是 FTWRL 期间获取到的 LSN（ xtrabackup_checkpoints 文件中的 last_lsn）：

• 没提交的事务回滚
• 已提交的事务重做
• 不存在 prepare 状态的事务，因此不需要根据 binlog 来判断该事务应该回滚还是重做，这也是 xtrabackup2.4 不需要备份 binlog 的原因

xtrabackup8 无FTWRL原理

xtrabackup8 适用于 MySQL8.0，因为 MySQL8.0 中的系统表不再使用 MyISAM 引擎，因此这成了一个去掉 FTWRL 重要前提。那去掉 FTWRL 后如何保证上文提到的一致性问题呢？

1. 首先会有一个备份锁（LOCK INSTANCE FOR BACKUP），整个备份期间都持有这把锁，会阻塞 DDL，因此可以保证拷贝到的表结构不会发生变化；
2. MySQL8.0 通过 performance_schema.log_status 表为在线备份工具（如 xtrabackup8）提供一个一致性的日志信息（包含 binlog postion、GTID 等）。为了使查询 log_status 得到的日志信息与备份的数据一致，查询 log_status 表时会有锁保护，不过加锁粒度只与二阶段提交的锁互斥。

此处得展开说下二阶段提交内部各个阶段的锁：

1. flush 阶段：加 LOCK_log 锁，fsync redo log，write binlog，此时生成 GTID；
2. sync 阶段：释放 LOCK_log 锁，加 LOCK_sync 锁，fsync binlog；
3. commit 阶段：释放 LOCK_sync 锁，加 LOCK_commit 锁，更新事务状态；加 global_sid_lock 锁，将 GTID 更新到 gtid_executed。

而MySQL8所有版本（目前最新8.0.28）由于 bug，查询 log_status 表时只获取 LOCK_log、global_sid_lock 锁。因此 InnoDB 内部可能存在事务已完成 sync ，但未完成 commit，即：

• binlog postion 已更新
• gtid_executed 未更新

查询到的 gtid_executed 实际落后于数据和 binlog position。

bug 详见：
https://bugs.mysql.com/bug.php?id=102175
https://jira.percona.com/browse/PS-7873

修复方法：查询 log_status 表时，同时获取 LOCK_log 、LOCK_sync、LOCK_commit、global_sid_lock，这将和事务提交的各阶段锁都互斥，保证读到的 GTID 与 binlog position 一致。

上面好像忘了提获取 LSN 由什么锁保护了，除了上述锁，还有 log_buffer_x_lock_enter、log_t::checkpointer_mutex，分别阻塞修改数据的DML操作和 checkpoint。也就是说查询 log_status 表时：

• 阻塞 DML，防止 LSN 变化；
• 阻塞事务提交们，防止 binlog position、GTID 变化；
• 阻塞 checkpoint，防止 checkpoint LSN 变化。

这样能保证备份数据的一致性，数据（即LSN）与 binlog position、GTID的一致性。