MySQL 5.6 GTID 新特性實踐：從原理到故障演練

GTID 核心概念

GTID = UUID + TID
UUID：MySQL 實例唯一標識（server_uuid）
TID：該實例已提交事務序號，單調遞增
例：3E11FA47-71CA-11E1-9E33-C80AA9429562:23

GTID 解決的核心痛點

傳統基於位置複制（File + Position）故障切換時，需手動換算各節點 Binlog 位置，極易出錯。GTID 使同一事務在全叢集唯一標識，切換主庫只需：

CHANGE MASTER TO MASTER_HOST='new_master', MASTER_AUTO_POSITION=1;

無需關心具體 File/Position，MySQL 內部自動對齊 GTID 集合。

搭建 GTID 複制（官方建議流程）

1. 主庫設 read_only=ON，停寫
2. 主從同步 my.cnf 加入：

gtid_mode=ON
enforce_gtid_consistency=ON
log_bin=mysql-bin
log_slave_updates=ON

3. 重啟主從服務
4. 從庫執行：CHANGE MASTER TO MASTER_HOST='...', MASTER_AUTO_POSITION=1;
5. START SLAVE;

三個必配參數缺一不可

• gtid_mode=ON
• enforce_gtid_consistency=ON（禁止非事務表混用、CREATE TEMPORARY TABLE 等）
• log_slave_updates=ON（從庫將複制事件寫入自身 Binlog，保證 GTID 鏈路完整）

缺少任一參數會報錯：--gtid-mode=ON requires --log-bin and --log-slave-updates

故障演練一：從庫需求的 GTID 已被主庫 PURGE

-- 主庫
PURGE BINARY LOGS TO 'mysql-bin.000004';
-- 導致 gtid_purged 包含從庫尚未拉取的事務

-- 從庫啟動複制報錯
Last_IO_Error: Got fatal error 1236 from master: 'The slave is connecting using MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

故障演練二：強制跳過已 PURGE 部分（慎用）

-- 從庫停止複制
STOP SLAVE;

-- 手動設定 gtid_purged 告訴從庫「這些事務我已有/可忽略」
SET GLOBAL gtid_purged = '3E11FA47-71CA-11E1-9E33-C80AA9429562:1';

-- 重新啟動
START SLAVE;
-- 從庫將從 :2 開始拉取，補齊缺口

前提：DBA 確認該從庫資料與主庫一致，或差異不影響後續複制（如僅 INSERT 無 UPDATE/DELETE）。

監控關鍵指標

生產升級建議

• 5.6 線上開啟 GTID 需停寫重啟，風險大，參考 Facebook/Percona 「Online GTID Enable」補丁
• 新叢集直接啟用 GTID，避免後續遷移痛點
• 備份策略需包含 gtid_executed / gtid_purged 狀態

GTID 讓複制拓撲變更從「手工計算」變為「自動對齊」，是 MySQL 高可用架構的基石特性。