开启MySQL 5.7+ GTID前必须确认三件事：一、enforce_gtid_consistency=ON且log_slave_updates=ON；二、binlog_format=ROW；三、gtid_mode需分OFF_PERMISSIVE→ON_PERMISSIVE→ON两步安全启用。
MySQL 5.7+ 开启 GTID 前必须确认的三件事
GTID 不是开关一开就能用的，强行开启会导致主从断裂或启动失败。最常踩的坑是：没关 log_slave_updates、没设 enforce_gtid_consistency=ON、或者在已有数据的实例上直接开 gtid_mode=ON。
必须满足以下全部条件才能安全启用：
-
enforce_gtid_consistency=ON—— 启动前就要加进配置，否则 MySQL 拒绝启动 -
log_slave_updates=ON—— 主从链路中所有节点（包括中间从库）都得开，否则 GTID 复制中断 -
binlog_format=ROW——MIXED或STATEMENT在 GTID 下会报错ER_GTID_MODE_ON_WITH_STATEMENT_BINLOG_FORMAT
my.cnf 里怎么写才不报错
直接贴能跑通的最小配置段，注意顺序和值类型 —— gtid_mode 必须分两步设，不能一步到位，否则 MySQL 启动直接拒绝。
第一步（先设兼容模式）：
gtid_mode=OFF_PERMISSIVE enforce_gtid_consistency=ON log_slave_updates=ON binlog_format=ROW
重启后执行：SELECT @@global.gtid_mode; 确认返回 OFF_PERMISSIVE，再执行：SET GLOBAL gtid_mode = ON_PERMISSIVE;
第二步（确认无匿名事务后）：
查：SELECT * FROM performance_schema.replication_applier_status_by_coordinator WHERE CHANNEL_NAME = ''; 和 SHOW MASTER STATUS;，确保 Executed_Gtid_Set 不为空且不含 0-0- 这类匿名事务标记。
最后改配置为：
gtid_mode=ON enforce_gtid_consistency=ON log_slave_updates=ON binlog_format=ROW
主从初始化时 GTID 模式下不能再用 mysqldump --master-data
传统主从靠 --master-data 记录 binlog 文件名+位置，但 GTID 模式下这信息完全没用，强行用会导致从库报错 Could not execute Write_rows event on table ...; Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging.
正确做法只有两个：
- 用
mysqldump --set-gtid-purged=ON（MySQL 5.6.9+），它会在 dump 文件开头写SET @@GLOBAL.GTID_PURGED='...'; - 或用
mysqlpump --set-gtid-purged=ON（MySQL 5.7.8+），更稳定 - 物理备份（如 Percona XtraBackup）也必须加
--galera-info或确认--gtid参数已生效
从库 CHANGE MASTER TO 怎么写才对
GTID 模式下不再用 MASTER_LOG_FILE 和 MASTER_LOG_POS，全靠 MASTER_AUTO_POSITION=1 自动对齐。
命令必须这样写：
CHANGE MASTER TO MASTER_HOST='10.0.1.2', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION=1;
漏掉 MASTER_AUTO_POSITION=1 或写成 =0，从库启动 IO 线程后立刻报错：ERROR 1777 (HY000): CHANGE MASTER TO MASTER_AUTO_POSITION = 1 can only be executed when @@GLOBAL.GTID_MODE = ON.
另外注意：START SLAVE; 前确保主库 SHOW MASTER STATUS; 的 Executed_Gtid_Set 已非空，否则从库同步会卡在 waiting for master to send event。
GTID 的真正复杂点不在配置本身，而在于“状态一致性” —— 主从之间、dump 文件与当前 binlog、甚至跨版本升级时的 gtid_purged 手动注入，稍有偏差就会触发 ER_MASTER_INFO_REPOSITORY_TABLE 或复制跳过失败。别信“一键开启”，多看 SELECT * FROM performance_schema.replication_connection_status; 和 SHOW SLAVE STATUS\G 里的 Retrieved_Gtid_Set 与 Executed_Gtid_Set 是否连续。
