gtid_mode和enforce_gtid_consistency必须同时为on且写入[mysqld]段重启生效，主从值严格一致，否则start slave必失败；二者需双端配置，gtid_executed与gtid_purged不匹配或dump未加--set-gtid-purged=on均会导致复制异常。
gtid_mode 和 enforce_gtid_consistency 必须同时为 ON，且**必须写入配置文件的 [mysqld] 段并重启生效**，否则 START SLAVE 一定失败——这是线上最常卡住的第一步。
主从两端的 gtid_mode 值必须严格一致
MySQL 5.7 不允许“主库开、从库关”的混合模式。只要一端是 OFF（包括 OFF_PERMISSIVE），执行 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 就会报错：ERROR 1777 (HY000): CHANGE MASTER TO requires MASTER_AUTO_POSITION = 1 when gtid_mode = ON。
-
SHOW VARIABLES LIKE 'gtid_mode';要在主、从上分别执行，不能只查一端 -
gtid_mode = on和gtid_mode = ON都合法；但gtid_mode = 1或gtid_mode = true会被 mysqld 启动时静默忽略 - 仅用
SET GLOBAL gtid_mode = ON;不持久，重启后回退；5.7.9+ 可用SET PERSIST gtid_mode = ON;，但生产环境仍建议写进配置文件 - 配置若写在
[client]段，或[mysqld]外的空白行，完全不生效
enforce_gtid_consistency = ON 是硬性前提，不是可选项
它和 gtid_mode 是两个独立变量：一个管事务合规性，一个管 GTID 生效开关。漏配前者，即使后者显示为 ON，复制初始化也会失败，日志里常出现误导性提示如：[Warning] Neither --relay-log nor --relay-log-index were used。
- 该参数必须在主、从两端都设为
ON，且同样写入[mysqld]段 - 开启后，部分语句会被直接拒绝，例如：
CREATE TABLE ... SELECT、含用户变量的非确定性INSERT、事务内混用 InnoDB 和 MyISAM 表等 - 业务侧需提前检查 SQL 兼容性，否则上线后会报错：
ERROR 1786 (HY000): Statement violates GTID consistency
从库 gtid_executed 和 gtid_purged 状态不匹配会导致 START SLAVE 卡死
从库如果曾用传统位置（MASTER_LOG_FILE/MASTER_LOG_POS）启动过复制，即使改了配置，gtid_executed 和 gtid_purged 可能仍为空或与主库不一致，导致 START SLAVE 卡在 relay log 初始化阶段，报错类似：Slave failed to initialize relay log info structure。
- 检查从库当前状态：
SELECT @@global.gtid_executed, @@global.gtid_purged; - 对比主库：
SHOW MASTER STATUS;中的Executed_Gtid_Set - 若从库
gtid_executed为空，说明没执行过 GTID 事务，不能直接START SLAVE，要先执行CHANGE MASTER TO MASTER_AUTO_POSITION = 1; - 若从库
gtid_purged包含主库没有的 UUID（比如曾作为其他主库的从库），需手动清理：RESET MASTER;（仅限全新从库）或SET GLOBAL gtid_purged = 'xxx';（值取自主库gtid_purged）
mysqldump 导出必须加 --set-gtid-purged=ON，否则导入从库时会因 GTID 冲突导致复制中断；而这个参数在 5.7.6+ 才默认启用，低版本需显式指定。
