gtid不一致导致主从同步中断，八成因gtid_mode状态机未走完、gtid_executed集合错位或binlog被purge；须三步验证：查运行时参数是否均为'on'、停复制后比对gtid_executed字符串是否一字不差、确认retrieved与executed gtid集相等，再按off→off_permissive→on_permissive→on路径切换，严禁跳步。
GTID不一致导致主从同步中断，八成不是“参数没开”，而是gtid_mode状态机没走完、gtid_executed集合实际错位、或MASTER_AUTO_POSITION = 1请求的binlog已被purge。直接RESET REPLICA ALL或硬塞SET GTID_PURGED极易引发永久性断裂。
先确认主从GTID是否真不一致，别被表象骗
别只看SHOW SLAVE STATUS\G里Executed_Gtid_Set非空就认为“开了GTID”——可能只是旧残留。必须分三步验证：
- 查运行时参数：
SELECT @@gtid_mode, @@enforce_gtid_consistency;，两端必须同时返回'ON'和'ON'（注意大小写和引号） - 停复制后比对集合：
STOP REPLICA;再执行SELECT @@global.gtid_executed;，主库和从库输出字符串必须一字不差（包括空格、换行、UUID顺序） - 确认
Retrieved_Gtid_Set与Executed_Gtid_Set相等（STOP REPLICA后查），否则说明SQL线程卡在中间，不是“不一致”，只是“没追完”
gtid_mode切换必须按状态机路径走，跳步必报ERROR 1238
gtid_mode不是布尔开关，是四阶状态机。从OFF升到ON必须严格执行：
STOP REPLICA;-
SET GLOBAL enforce_gtid_consistency = ON;（必须先设这个） SET GLOBAL gtid_mode = OFF_PERMISSIVE;SET GLOBAL gtid_mode = ON_PERMISSIVE;SET GLOBAL gtid_mode = ON;START REPLICA;
每一步后用SELECT @@gtid_mode;确认生效；所有SET GLOBAL必须同步写入/etc/my.cnf，否则重启回落。
MASTER_AUTO_POSITION = 1报ERROR 1236，本质是binlog缺失，不是配置错
报错信息形如Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires'，说明从库要的GTID在主库binlog里已不存在。
- 检查主库
PURGE BINARY LOGS历史：SHOW BINARY LOGS;和SELECT @@expire_logs_days; - 确认从库
gtid_executed是否混入其他server_uuid（比如曾连过测试库）：SELECT * FROM performance_schema.replication_applier_status_by_coordinator; - 若确认从库没执行过额外事务，且缺失量小，可用
SET GTID_PURGED = 'xxx';强制对齐（但必须先RESET REPLICA ALL并清空relay log文件） - 缺失量大或无法确认来源，唯一安全解法是
mysqldump --set-gtid-purged=OFF重导全量
跳过单个事务必须精准注入空事务，抄错一个字符就废
GTID模式下sql_slave_skip_counter完全失效。跳过需手动伪造已执行的GTID：
- 从
Last_SQL_Error里精确提取GTID，例如3e11fa47-71ca-11e1-9e33-c80aa9429562:23（冒号前后不能有空格，UUID大小写敏感） - 顺序执行：
STOP REPLICA;→SET GTID_NEXT = 'xxx';→BEGIN; COMMIT;→SET GTID_NEXT = 'AUTOMATIC';→START REPLICA; - 关键风险：若
COMMIT前连接断开，或GTID_NEXT值有误，从库gtid_executed将永久错乱，无法自动修复
真正棘手的从来不是“怎么跳过”，而是“为什么这个GTID会缺失”——它背后大概率藏着人为误操作、跨库同步残留、或binlog轮转策略失控。修完立刻查mysql.error.log和SHOW BINLOG EVENTS定位源头，否则下周还会爆。
