必须同时设置 gtid_mode = ON 和 enforce_gtid_consistency = ON，否则 MySQL 启动失败；还需启用 log_bin 和 binlog_format = ROW，并使用 MASTER_AUTO_POSITION = 1 配置复制，且主从 GTID_EXECUTED 必须一致。
必须同时设 gtid_mode = ON 和 enforce_gtid_consistency = ON，缺一不可，否则 MySQL 启动失败或复制直接拒绝。
为什么只配 gtid_mode = ON 会报错
MySQL 在启动时检测到 gtid_mode = ON 但 enforce_gtid_consistency = OFF，会立即拒绝启动，并抛出错误：ERROR 3124 (HY000): @@GLOBAL.GTID_MODE = ON requires @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON.
-
enforce_gtid_consistency = ON是安全闸门：它禁止执行 CREATE TABLE ... SELECT、用户变量赋值（如@a := 1）、临时表混用等 GTID 不安全语句 - 不加这层限制，主从可能因非确定性语句产生数据不一致，GTID 就失去意义
- 配置文件里这两个参数顺序无关，但必须共存；漏掉任意一个，mysqld 进程根本起不来
log_bin 和 binlog_format = ROW 为什么也强制要求
GTID 的本质是“事务级唯一标识”，而标识来源依赖二进制日志。没有 log_bin，事务就无法被编号；用 STATEMENT 格式则会让 NOW()、UUID()、自增主键等产生主从不一致——MySQL 会直接拦截这类语句并报错：ERROR 1786 (HY000): Statement violates GTID consistency。
-
log_bin值写成mysql-bin即可，无需路径；MySQL 自动补全到datadir -
binlog_format = ROW是硬性前提，MIXED或STATEMENT下设gtid_mode = ON会被拒绝 - 即使你只打算做单向复制，从库也必须开
log_bin（否则级联复制断链，且部分 GTID 状态校验逻辑会异常）
CHANGE MASTER TO 必须用 MASTER_AUTO_POSITION = 1
开启 GTID 后，不能再用 MASTER_LOG_FILE 和 MASTER_LOG_POS。一旦混用，START SLAVE 立即失败：ERROR 1776 (HY000): Parameters MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is enabled.
-
MASTER_AUTO_POSITION = 1（注意是数字1，不是字符串'ON'或布尔值） - 执行前务必
STOP SLAVE，否则命令被忽略 - 如果主从
GTID_EXECUTED集合不兼容（比如从库有主库已 purged 的事务），START SLAVE会卡住或报ERROR 3037，此时只能重搭从库或注入空事务对齐
验证是否真生效：别只看配置文件
配置写对 ≠ 实际启用。真正有效的判断依据是运行时变量：
- 查
SELECT @@gtid_mode;—— 必须返回ON（不是OFF_PERMISSIVE） - 查
SELECT @@enforce_gtid_consistency;—— 必须返回ON - 查
SHOW SLAVE STATUS\G中的Using_Gtid字段 —— 应为Current_Pos，不是No - 初始数据导入后，主从的
SELECT @@global.gtid_executed;必须完全一致；否则后续事务会跳、会冲突，且这种不一致不会自动修复
最容易被忽略的是初始数据与 GTID 执行集的对齐——GTID 只管“新增”，不管“历史”。备份没带 --master-data=2 或恢复后没校验 gtid_executed，后面所有问题都源于此。
