GTID模式主从复制需主从均设gtid_mode=ON、enforce_gtid_consistency=ON、log_bin=ON；CHANGE MASTER TO必须用MASTER_AUTO_POSITION=1；验证时重点检查Retrieved_Gtid_Set、Executed_Gtid_Set和Auto_Position值。
GTID 模式下主从复制不是“开箱即用”，必须提前在主从双方都启用 gtid_mode=ON 且禁用 enforce_gtid_consistency=OFF，否则 CHANGE MASTER TO 会直接报错 ERROR 1777 (HY000)。
主库必须开启的三项关键配置
仅设置 gtid_mode=ON 不够，MySQL 要求三者同时满足才能启动 GTID：
-
gtid_mode=ON：启用 GTID 生成与识别 -
enforce_gtid_consistency=ON：强制事务符合 GTID 约束（例如禁止CREATE TEMPORARY TABLE、非确定性函数等） -
log_bin=ON：必须开启二进制日志（GTID 依赖 binlog 记录事务）
缺一不可。若已运行的实例未开启 log_bin，重启前需确认磁盘空间足够、binlog_format=ROW 已设好，并避免在业务高峰期操作。
从库执行 CHANGE MASTER TO 的正确写法
GTID 模式下不指定 MASTER_LOG_FILE 和 MASTER_LOG_POS，而是用 MASTER_AUTO_POSITION=1 让 MySQL 自动对齐 GTID 集合：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;
常见错误：
- 漏写
MASTER_AUTO_POSITION=1，仍带MASTER_LOG_FILE→ 报错ERROR 1777 - 主库未执行
FLUSH PRIVILEGES或复制账号没REPLICATION SLAVE权限 → 连接后 IO 线程立即Connecting状态卡住 - 从库
gtid_executed非空但和主库无交集（如从库是全新实例但之前启过 GTID）→ 启动失败，需先执行RESET MASTER
验证复制状态时重点看这三项
运行 SHOW SLAVE STATUS\G 后，不要只扫一眼 Slave_IO_Running 和 Slave_SQL_Running，必须确认：
-
Retrieved_Gtid_Set非空且持续增长 → 表示 IO 线程正在拉取主库 binlog -
Executed_Gtid_Set与Retrieved_Gtid_Set差值稳定（或为 0）→ SQL 线程跟得上 -
Auto_Position: 1→ 确认当前确实是 GTID 模式同步，不是降级为 file/pos 模式
如果 Executed_Gtid_Set 长期不动，大概率是 SQL 线程遇到 DDL 冲突或权限问题，此时 Seconds_Behind_Master 会飙升，但错误信息藏在 Last_SQL_Error 字段里，得仔细看。
GTID 最大的隐性成本是：一旦主库 gtid_purged 被清掉一部分，从库就再也无法通过自动定位补全缺失事务；所以 binlog_expire_days 必须大于从库可能的最大延迟时间，这点比传统模式更敏感。
