GTID复制要求主从均启用gtid_mode=ON且enforce_gtid_consistency=ON，CHANGE MASTER TO必须指定MASTER_AUTO_POSITION=1，从库需开启log-bin和log-slave-updates，初始数据必须通过一致备份对齐GTID_EXECUTED。
主从都必须开 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 会直接拒绝执行。
