MySQL 5.6 引入全局事務標識符，徹底解決了傳統基於文件位點復制的「指錯位點導致數據漏傳/重傳」痛點。本文深度解析 GTID 原理、配置全流程、故障處理與遷移最佳實踐。
| 維度 | 傳統 | GTID |
|---|
| 定位方式 | MASTER_LOG_FILE + MASTER_LOG_POS | MASTER_AUTO_POSITION=1 |
| 從庫切換 | 需手動計算新位點 | 自動對比 GTID 集合，補齊缺失事務 |
| 故障轉移 | 複雜，易出錯 | MHA/Orchestrator 秒級自動故障轉移 |
| 數據一致性 | 依賴人工校驗 | 事務級去重，天然保證一致性 |
三、配置前置條件
-- 主庫必須開啟
log_bin = mysql-bin
server_id = 1001
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON -- 5.6 必須，5.7+ 可選
-- 從庫
server_id = 1002
relay_log = relay_log
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
關鍵限制（enforce_gtid_consistency 強制）：
- 禁止
CREATE TABLE ... SELECT
- 事務中禁止創建臨時表
- 禁止事務內同時更新事務表與非事務表
四、從庫數據初始化（關鍵步驟）
方案 A：mysqldump（中小數據量）
# 主庫導出（含 GTID 信息）
mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases -uroot -p -P3308 > all.sql
# 從庫導入
mysql -uroot -p -P3309 < all.sql
--master-data=2 會在輸出中註釋形式包含 SET @@GLOBAL.GTID_PURGED='...'，從庫導入後自動同步 GTID 執行集合。
方案 B：XtraBackup（大數據量，物理備份）
# 備份時帶上 --slave-info 記錄 GTID
xtrabackup --backup --target-dir=/backup --slave-info --user=root --password=xxx
# 恢復後查看 xtrabackup_slave_info 文件獲取 GTID 集合
五、啟動 GTID 復制
CHANGE MASTER TO
MASTER_HOST='192.168.1.106',
MASTER_PORT=3308,
MASTER_USER='repl',
MASTER_PASSWORD='repl',
MASTER_AUTO_POSITION=1;
START SLAVE;
SHOW SLAVE STATUS\G
六、常見啟動報錯與解決
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
原因：從庫 relay_log_info_repository=TABLE 但表中殘留舊位點信息衝突。
解決：
STOP SLAVE;
RESET SLAVE ALL; -- 5.6 用 RESET SLAVE
START SLAVE;
七、驗證復制鏈路
- 主庫建表插入：
CREATE TABLE gtid_test (id INT); INSERT INTO gtid_test VALUES (1);
- 從庫查詢：
SELECT * FROM gtid_test; 應立即可見。
- 檢查
SHOW SLAVE STATUS\G 中 Retrieved_Gtid_Set、Executed_Gtid_Set、Seconds_Behind_Master=0。
八、GTID 模式下常見運維場景
- 新增從庫：同初始化流程，無需關心位點。
- 主從切換：提升從庫為主，其他從庫
CHANGE MASTER TO MASTER_HOST=new_master, MASTER_AUTO_POSITION=1 即可。
- 跳過錯誤事務：
SET GTID_NEXT='bad_gtid'; BEGIN; COMMIT; SET GTID_NEXT=AUTOMATIC;（極謹慎使用）。
- 部分復制：
replicate_do_db/replicate_wild_do_table 仍生效，但 GTID 集合仍記錄所有事務。
九、總結
GTID 將復制定位從「文件+偏移」升級為「事務集合」，實現了真正的自動化、去中心化復制拓撲管理。生產環境強烈建議全鏈路開啟 GTID，配合 log_slave_updates、enforce_gtid_consistency、半同步復制、MHA/Orchestrator，構建高可用、可運維的 MySQL 集群架構。
- 上一篇文章： MySQL 增刪改查 (CRUD) 基礎語法完整速查表
- 下一篇文章： MySQL int(3) vs int(11) 區別深度解析：顯示寬度 ≠ 存儲長度
Copyright ©
程式碼之家 All Rights Reserved
