必须确认主从两端gtid_mode和enforce_gtid_consistency均为on，且严格一致；执行select @@gtid_mode, @@enforce_gtid_consistency验证，on_permissive或任一端非on均导致start slave失败。
确认主从两端 GTID 模式是否真正一致
跨版本同步（比如 5.7 → 8.0 或 8.0 → 8.4）出 GTID 错误，八成卡在 gtid_mode 和 enforce_gtid_consistency 状态不匹配。别只看配置文件，必须在主、从库分别执行：SELECT @@gtid_mode, @@enforce_gtid_consistency;
结果必须严格为 'ON' 和 'ON' ——ON_PERMISSIVE、OFF_PERMISSIVE 或任意一端是 OFF，都会导致 START SLAVE 静默失败或报 ERROR 1777。
检查 MySQL 8.0+ 的默认行为是否覆盖了旧配置
MySQL 8.0 起默认启用 gtid_mode = ON 且强制写入 my.cnf 中的 gtid_mode=on 可能被忽略。常见陷阱包括：
-
my.cnf里写的是gtid_mode = true或gtid_mode = 1：MySQL 启动时静默跳过，SHOW VARIABLES仍显示OFF - 配置写在
[client]段而非[mysqld]段：完全不生效 - 从库是 5.7 升级上来的，但没执行完整切换路径：必须按
OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON顺序SET GLOBAL，且每步后要SELECT确认生效 - 8.0+ 要求
log_slave_updates = ON（GTID 复制必需），而 5.7 默认关闭，升级后容易遗漏
处理因 binlog purge 导致的 GTID 断层
跨版本迁移常伴随 PURGE BINARY LOGS，若从库 gtid_purged 缺失主库已清除的 GTID 区间，START SLAVE 会卡在初始化阶段。修复前先查状态：
主库执行：SHOW MASTER STATUS; → 记下 Executed_Gtid_Set
从库执行：SELECT @@global.gtid_executed, @@global.gtid_purged;
若从库 gtid_purged 为空或明显小于主库 Executed_Gtid_Set，不能直接 CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1。必须：
- 在从库停复制：
STOP SLAVE; - 清空 relay log 并重置状态：
RESET SLAVE ALL; - 若从库 binlog 非空，先
RESET MASTER;（仅限确认无其他下游依赖） - 再设
SET GLOBAL gtid_purged = 'xxx:1-yyy';，值必须精确复制主库当前Executed_Gtid_Set - 最后
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
跳过错误事务时注意版本间 GTID_NEXT 行为差异
MySQL 5.7 和 8.0 对 SET GTID_NEXT 的校验更严格：值必须存在于 Retrieved_Gtid_Set 中，且不能是已执行过的 GTID。操作前务必从 SHOW SLAVE STATUS\G 的 Last_SQL_Error 或 Relay_Master_Log_File + Exec_Master_Log_Pos 定位出错事务的真实 GTID（不是靠猜或日志时间戳）。常见错误：
- 抄错 UUID 或 transaction_id（比如把
:12345写成:1234）→ 后续仍报同错 - 没执行
BEGIN; COMMIT;就START SLAVE→ GTID_NEXT 未提交，跳过无效 - 在 8.0.23+ 上用
SET SESSION GTID_NEXT→ 必须用SET @@SESSION.GTID_NEXT，否则报错 - 多源复制场景下，
Retrieved_Gtid_Set是多个 UUID 的并集，需结合Last_IO_Error确定具体来源 server_uuid
真正麻烦的不是命令敲不对，而是跳过之后发现主键自增偏移错位、唯一索引残留冲突记录、或后续 DDL 因 GTID 顺序错乱而卡死 —— 这些都得靠 SELECT COUNT(*)、mysqlbinlog 解析和主从时间戳 INSERT 验证。
