gtid_executed 的初始化

1. 從 mysql.gtid_executed 表加載（主要來源）

• 持久化存儲：在實例正常運行期間，MySQL 會定期（例如在 binlog 文件輪換時或服務(wù)器關(guān)閉時）將內(nèi)存中的 gtid_executed 集合進行“壓縮”并持久化到 mysql.gtid_executed 系統(tǒng)表中。
• 初始化基礎(chǔ)值：實例啟動時，首先會從 mysql.gtid_executed 表中讀取所有記錄，將這些記錄的 GTID 集合合并，作為初始化 @@GLOBAL.gtid_executed 系統(tǒng)變量的基礎(chǔ)值。這是最快、最主要的數(shù)據(jù)來源。

2. 掃描 Binlog 文件以進行驗證和補充

• 掃描現(xiàn)存文件：繼上一步之后，服務(wù)器會掃描磁盤上所有現(xiàn)存的（未被 PURGE 的）binlog 文件。
• 重建 Binlog 中的 GTID 集合：對于每個 binlog 文件，服務(wù)器通過解析其頭部的 Previous_gtids_log_event 和文件體內(nèi)的 Gtid_log_event，計算出該文件所包含的完整 GTID 區(qū)間。
• 計算并合并：服務(wù)器將所有現(xiàn)存 binlog 文件中的 GTID 集合合并，得到一個代表“磁盤上記錄的已執(zhí)行事務(wù)”的 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

這樣設(shè)計的目的：

• 效率：從表加載速度遠快于解析所有 binlog 文件。
• 安全性/正確性：mysql.gtid_executed 表可能由于某些原因（如未及時刷新）未能包含最新提交的事務(wù)。掃描 binlog 確保了任何已經(jīng)記錄到二進制日志中的事務(wù)都不會被遺漏，從而保證了 gtid_executed 集合的絕對正確性。

gtid_purged 初始化

在 gtid_executed 確定之后，再看下gtid_purged 的計算。
實際上，簡單說，

gtid_executed = gtid purged + gtid not purged

gtid_purged代表的是已經(jīng)從磁盤上被清除的 binlog 文件中所記錄的那些事務(wù)。

步驟一：計算 gtids_in_binlog（所有曾被記錄在日志中的 GTID）
計算方法：最新的二進制日志文件中的 Previous_gtids_log_event（上一個日志的 GTID 集合）加上該最新日志文件自身的 GTID 事務(wù)。

步驟二：計算 gtids_in_binlog_not_purged（未被清理的 GTID）
計算方法： 用 gtids_in_binlog（步驟一的結(jié)果）減去最老的二進制日志文件中的 Previous_gtids_log_event 集合。

步驟三：計算 gtid_purged（已清理的 GTID）
計算方法： 用 gtid_executed（所有執(zhí)行過的 GTID）減去 gtids_in_binlog_not_purged（步驟二的結(jié)果）。

補充說明：可能有同學(xué)會有疑問，為什么不直接使用 最舊binlog文件 中的 Previous_gtids_log_event 作為 gtid_purged？實際上，這里要考慮沒有記錄binlog的情況，如果沒有打開binlog 或者某個事務(wù)沒有記錄binlog，直接使用最舊binlog文件 中的 Previous_gtids_log_event，是有問題的。

上面過程的流程如下圖：

到此這篇關(guān)于MySQL 機器重啟后gtid_executed初始化流程解析的文章就介紹到這了,更多相關(guān)mysql gtid_executed初始化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論