MySQL 机器重启后gtid_executed初始化流程解析_Mysql

gtid_executed 的初始化

从 mysql.gtid_executed 表加载（主要来源）

持久化存储：在实例正常运行期间，mysql 会定期（例如在 binlog 文件轮换时或服务器关闭时）将内存中的 gtid_executed 集合进行“压缩”并持久化到 mysql.gtid_executed 系统表中。
初始化基础值：实例启动时，首先会从 mysql.gtid_executed 表中读取所有记录，将这些记录的 gtid 集合合并，作为初始化 @@global.gtid_executed 系统变量的基础值。这是最快、最主要的数据来源。

扫描 binlog 文件以进行验证和补充

扫描现存文件：继上一步之后，服务器会扫描磁盘上所有现存的（未被 purge 的）binlog 文件。
重建 binlog 中的 gtid 集合：对于每个 binlog 文件，服务器通过解析其头部的 previous_gtids_log_event 和文件体内的 gtid_log_event，计算出该文件所包含的完整 gtid 区间。
计算并合并：服务器将所有现存 binlog 文件中的 gtid 集合合并，得到一个代表“磁盘上记录的已执行事务”的 gtid 集合，我们称之为 binlog_gtid_set。

补充说明：如果版本只涉及 5.7.8 及以后版本，binlog_gtid_set 计算时只使用最新binlog文件即可。

计算最终的 gtid_executed
最终的
@@global.gtid_executed 值是以下两个集合的并集（union）： gtid_executed = 从mysql.gtid_executed表加载的集合 ∪ binlog_gtid_set

这样设计的目的：

效率：从表加载速度远快于解析所有 binlog 文件。
安全性/正确性：mysql.gtid_executed 表可能由于某些原因（如未及时刷新）未能包含最新提交的事务。扫描 binlog 确保了任何已经记录到二进制日志中的事务都不会被遗漏，从而保证了 gtid_executed 集合的绝对正确性。

gtid_purged 初始化

在 gtid_executed 确定之后，再看下gtid_purged 的计算。
实际上，简单说，

gtid_executed = gtid purged + gtid not purged

gtid_purged代表的是已经从磁盘上被清除的 binlog 文件中所记录的那些事务。

步骤一：计算 gtids_in_binlog（所有曾被记录在日志中的 gtid）
计算方法：最新的二进制日志文件中的 previous_gtids_log_event（上一个日志的 gtid 集合）加上该最新日志文件自身的 gtid 事务。

步骤二：计算 gtids_in_binlog_not_purged（未被清理的 gtid）
计算方法： 用 gtids_in_binlog（步骤一的结果）减去最老的二进制日志文件中的 previous_gtids_log_event 集合。

步骤三：计算 gtid_purged（已清理的 gtid）
计算方法： 用 gtid_executed（所有执行过的 gtid）减去 gtids_in_binlog_not_purged（步骤二的结果）。

补充说明：可能有同学会有疑问，为什么不直接使用最旧binlog文件中的 previous_gtids_log_event 作为 gtid_purged？实际上，这里要考虑没有记录binlog的情况，如果没有打开binlog 或者某个事务没有记录binlog，直接使用最旧binlog文件中的 previous_gtids_log_event，是有问题的。

上面过程的流程如下图：