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

gtid_executed 的初始化

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

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

2. 扫描 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文件即可。

3. 计算最终的 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，是有问题的。

上面过程的流程如下图：

到此这篇关于MySQL 机器重启后gtid_executed初始化流程解析的文章就介绍到这了,更多相关mysql gtid_executed初始化内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！