参考资料
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 后如何保证上文提到的一致性问题呢？
- 首先会有一个备份锁（LOCK INSTANCE FOR BACKUP），整个备份期间都持有这把锁，会阻塞 DDL，因此可以保证拷贝到的表结构不会发生变化；
- MySQL8.0 通过 performance_schema.log_status 表为在线备份工具（如 xtrabackup8）提供一个一致性的日志信息（包含 binlog postion、GTID 等）。为了使查询 log_status 得到的日志信息与备份的数据一致，查询 log_status 表时会有锁保护，不过加锁粒度只与二阶段提交的锁互斥。
此处得展开说下二阶段提交内部各个阶段的锁：
- flush 阶段：加 LOCK_log 锁，fsync redo log，write binlog，此时生成 GTID；
- sync 阶段：释放 LOCK_log 锁，加 LOCK_sync 锁，fsync binlog；
- 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的一致性。
