MySQL GTID 主從復制完整配置指南

前言

全域交易識別碼（GTID）是 MySQL 5.6 版本引入的重要特性，它為每個已提交的事務分配一個全域唯一的 ID，由伺服器 UUID 與事務序號組成。這項機制徹底改變了傳統基於二進制日誌檔案與位置的復制方式，讓主從架構的部署、故障切換與數據一致性保證變得更加簡單可靠。本文將系統性地介紹 GTID 的核心概念、優勢、工作原理，並提供生產環境可用的完整配置步驟。

一、GTID 核心概念

• 全域唯一性：GTID 格式為 source_id:transaction_id，其中 source_id 即伺服器的 server_uuid，transaction_id 為該伺服器上已提交事務的遞增序號（從 1 開始）。
• 冪等執行：同一 GTID 在任一伺服器上僅會執行一次，有效避免重複執行導致的數據不一致。
• 自動定位：從庫啟動復制時使用 MASTER_AUTO_POSITION=1，無需手動指定 MASTER_LOG_FILE 與 MASTER_LOG_POS。
• 強制開啟從庫 Binlog：GTID 模式下從庫必須開啟 log_bin 並設置 log_slave_updates=1，以記錄已執行的 GTID 集合。

二、GTID 組成結構

GTID = source_id:transaction_id
source_id：來源伺服器標識，即 server_uuid（例如 3E11FA47-71CA-11E1-9E33-C80AA9429562）
transaction_id：該伺服器上已提交事務的序號（例如 23）
示例：3E11FA47-71CA-11E1-9E33-C80AA9429562:23

三、GTID 主要優勢

1. 簡化故障切換：無需尋找 binlog 檔案與位置，直接基於 GTID 集合進行同步。
2. 簡化主從搭建：新增從庫只需配置 CHANGE MASTER TO ... MASTER_AUTO_POSITION=1 即可。
3. 更安全的復制：GTID 連續無空洞，配合 enforce_gtid_consistency 可杜絕非事務性操作導致的數據不一致。
4. 零數據丟失保證：嚴格的事務對應關係確保主從數據強一致。

四、GTID 工作流程詳解

1. 主庫執行並提交事務時生成 GTID，寫入 Binlog。
2. Binlog 經 I/O 線程傳輸到從庫 Relay Log。
3. SQL 線程讀取 Relay Log，解析 GTID 並設置 gtid_next 變量，告知下一個待執行的 GTID。
4. 對比從庫 Binlog 中是否已存在該 GTID：
   　　• 若存在 → 已執行，直接跳過
   　　• 若不存在 → 執行事務，並將 GTID 記錄至從庫 Binlog
5. 執行前檢查其他 Session 是否持有該 GTID，防止並發重複執行。
6. 解析過程中優先使用主鍵，無主鍵則退回到二級索引或全表掃描。

五、配置文件關鍵參數（MySQL 5.6.5+）

主庫配置

[mysqld]
# GTID 核心
server_id=135
gtid_mode=ON
enforce_gtid_consistency=ON

# Binlog 設置
log_bin=master-binlog
log_slave_updates=1
binlog_format=ROW          # 強烈建議 ROW 格式，避免數據不一致

# Relay Log
skip_slave_start=1         # 防止意外自動啟動 Slave

從庫配置

[mysqld]
# GTID 核心
gtid_mode=ON
enforce_gtid_consistency=ON
server_id=143

# Binlog 設置（從庫必開）
log_bin=slave-binlog
log_slave_updates=1
binlog_format=ROW

# Relay Log
skip_slave_start=1

說明：enforce_gtid_consistency=ON 會限制部分語法（如 CREATE TABLE ... SELECT、臨時表與事務表混用等），請提前評估業務兼容性。

六、基於 GTID 的復制部署實戰

場景 1：全新部署的主從架構

1. 雙方均按上節配置修改 my.cnf 並重啟 MySQL。
2. 主庫建立復制賬號：
   CREATE USER 'repl'@'%' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
3. 從庫執行：
   

   CHANGE MASTER TO
     MASTER_HOST='192.168.1.135',
     MASTER_USER='repl',
     MASTER_PASSWORD='strong_password',
     MASTER_PORT=3306,
     MASTER_AUTO_POSITION=1;
   START SLAVE;

4. 驗證：SHOW SLAVE STATUS\G 確認 Slave_IO_Running 與 Slave_SQL_Running 均為 Yes。

場景 2：傳統復制遷移至 GTID 復制

1. 按第 5 節修改雙方配置文件。
2. 全局鎖定寫入，等待主從同步完成：
   SET GLOBAL read_only = ON;
3. 依次重啟主庫、從庫 MySQL 服務。
4. 從庫重新配置主從關係（同場景 1 的 CHANGE MASTER 步驟）。
5. 開啟復制並驗證：START SLAVE; SHOW SLAVE STATUS\G

七、常見坑點與最佳實踐

• 版本要求：生產環境建議 MySQL 5.7.6+ 或 8.0+，GTID 實現更成熟。
• Binlog 格式：務必使用 ROW 格式，STATEMENT 或 MIXED 在特定場景下會導致 GTID 不一致。
• server_id 唯一：集群內每個節點的 server_id 必須唯一，否則會導致 GTID 衝突。
• 監控指標：關注 Retrieved_Gtid_Set、Executed_Gtid_Set 差異，及時發現延遲或斷點。
• 備份策略：使用 mysqldump --set-gtid-purged=ON 或 Percona XtraBackup 保證備份包含 GTID 資訊，便於快速構建新從庫。

八、總結

GTID 通過全域唯一事務標識，將 MySQL 複製從「基於位置」升級為「基於事務」，極大地降低了運維複雜度，提升了數據一致性保障。遵循本文的配置規範與部署流程，可快速構建穩健、易維護的高可用 MySQL 架構。