gtid_purged已提交但在服務(wù)器二進制日志中已被清除的事務(wù)的GTID集合gtid_purgedgtid_executed

初始化

前文中已講到 gtid_executed 和gtid_purged 初始化，這里再回顧下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é)果）。

更新時機

gtid_purged的行為主要由服務(wù)器角色和二進制日志（binlog）配置決定，下表總結(jié)了主要場景下的更新時機：

補充說明

除了上述核心機制，以下幾點對理解和管理gtid_purged也至關(guān)重要：

1. 初始化依賴的配置：系統(tǒng)變量binlog_gtid_simple_recovery（默認(rèn)ON）決定了啟動時初始化gtid_purged的效率。
   • ON（默認(rèn)）：僅讀取最舊和最新的兩個二進制日志文件來計算，速度快。
   • OFF：可能需要掃描所有二進制日志文件來計算，速度慢，僅在升級等特定場景下可能需要設(shè)置。
2. 與備份恢復(fù)的關(guān)系：使用mysqldump進行邏輯備份時，導(dǎo)出的SQL文件默認(rèn)會包含一條SET @@GLOBAL.gtid_purged = ...語句。這條語句的作用是告訴新的從庫“備份文件中已經(jīng)包含了哪些GTID對應(yīng)的事務(wù)，這些事務(wù)無需再從主庫復(fù)制”。在多源復(fù)制或已有數(shù)據(jù)的實例上恢復(fù)時，需要謹(jǐn)慎處理此語句。
3. 約束條件：在MySQL 5.7版本中，只有在gtid_executed集合為空時（例如執(zhí)行RESET MASTER之后），才能設(shè)置gtid_purged。更高版本的限制可能有所放松，但此操作仍需在明確知曉影響的情況下執(zhí)行。

應(yīng)用與排查要點

• 搭建從庫：這是gtid_purged最主要的使用場景。在從庫上使用SET @@GLOBAL.gtid_purged來聲明已從備份數(shù)據(jù)中恢復(fù)的事務(wù)GTID集，是建立基于GTID復(fù)制的關(guān)鍵步驟之一。
• 常見問題排查：如果出現(xiàn)“The slave is connecting using CHANGE MASTER TO … MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires”錯誤，通常是因為從庫gtid_purged集合中的部分GTID在主庫的二進制日志中已被清除。解決方案通常是從頭重建復(fù)制，或使用第三方工具（如binlog server）來提供丟失的日志。

總結(jié)

簡單來說，gtid_purged是一個用于追蹤“已提交但日志已丟失事務(wù)”的GTID集合。它在服務(wù)器啟動時初始化，更新時機取決于配置：主庫和開啟log_slave_updates的從庫在清除二進制日志時更新；未開啟log_slave_updates的從庫則在每個事務(wù)提交時實時更新。

到此這篇關(guān)于MySQL中g(shù)tid_purged 的初始化和更新機制的文章就介紹到這了,更多相關(guān)mysql gtid_purged內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論