主从都必须开 gtid_mode=ON
，且不能只配一半
GTID 复制不是“主库开了就行”，主库和从库必须同时启用，否则
START SLAVE会直接报错：
ERROR 3021 (HY000): This server is not configured as a replication slave或更隐蔽的
Slave_SQL_Running: No。常见错误是只在主库加了
gtid-mode = ON，从库仍用传统复制参数，结果启动后 IO 线程正常、SQL 线程卡死。确认方式很简单：
SELECT @@gtid_mode;必须返回
ON，且
SHOW VARIABLES LIKE 'enforce_gtid_consistency';返回
ON。
MASTER_AUTO_POSITION = 1
是 GTID 启动的开关，不是可选项
从库执行
CHANGE MASTER TO时，
MASTER_AUTO_POSITION = 1必须显式指定，且不能和
MASTER_LOG_FILE/
MASTER_LOG_POS共存——否则 MySQL 会报错：
ERROR 1777 (HY000): CHANGE MASTER TO without MASTER_AUTO_POSITION = 1 requires MASTER_LOG_FILE and MASTER_LOG_POS to be set。它本质是告诉从库：“别问我从哪开始同步，你按 GTID 集合自动对齐”。如果误写了旧式 position 参数，复制会静默失败，
Retrieved_Gtid_Set和
Executed_Gtid_Set会长期为空或不匹配。
从库必须开 log-bin
和 log-slave-updates
这是最容易被 Windows 或测试环境忽略的一点：即使从库不对外提供写服务，也必须开启二进制日志（
log-bin）并设置
log-slave-updates = ON。原因在于 GTID 要求每个已执行事务的 GTID 必须记录在本地
binlog中，用于后续校验和级联复制。若关闭，从库启动后会报错：
ERROR 3546 (HY000): Global transaction identifier is turned on, but binary log is not enabled。注意：配置里
log-bin值不用带路径，写成
log-bin = mysql-bin即可，MySQL 会自动补全路径。
数据一致性没对齐前，START SLAVE
就是自欺欺人
很多操作卡在“明明配置全了，但
SHOW SLAVE STATUS\G显示延迟巨大或 SQL 线程报错跳过事务”，根本原因是主从初始数据不一致。GTID 不会帮你修复历史差异——它只保证“新增事务不重复、不遗漏”。所以务必先做三件事：
• 主库用
mysqldump --single-transaction --master-data=2导出全量；
• 从库清空（或全新初始化）后导入该备份；
• 导入后检查
SELECT @@GLOBAL.GTID_EXECUTED;在主从上是否完全一致。如果不一致，强行
START SLAVE可能导致事务被跳过或冲突，尤其当主库有
CREATE TEMPORARY TABLE等 GTID 不安全语句时，
enforce-gtid-consistency = ON会直接拒绝执行。
