参考资料
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的一致性。
网友评论