如何在Innodb层维护GTID？

如何在 Innodb 层维护 GTID？

摘要

在之前的公众号文章《GTID实践和分析》中介绍了GTID的基本原理，MySQL主要通过Server引擎的binlog文件和Innodb的mysql.gtid_executed表来持久化GTID集合信息。在提交时会将分配给事务的GTID刷到binlog文件中，在事务成功提交后会将GTID加入内存的executed_gtids集合中，并周期性持久化到mysql.gtid_executed表中。在实例恢复时可以从mysql.gtid_executed表+最后一个binlog文件中的GTID信息来恢复executed_gtids集合，从而保证GTID的完整性。

在MySQL 8.0.17开始引入基于Innodb引擎的物理备份插件clone plugin，和xtrabackup不同，它在克隆时不会复制Server层的binlog文件，而mysql.gtid_executed表的数据并不是实时的，因此需要在Innodb层维护完整的GTID信息。引入clone plugin后一个明显的变化是事务提交时会将GTID信息记录在undo log header，并新增一个 Clone_persist_gtid 对象来维护Innodb层GTID的持久化。本文将从"分配Undo log segment"、"在Undo log header记录GTID信息"、"GTID的持久化"和"Purge Undo log"这几个关键环节代码对GTID的维护进行介绍。