迁移后主从无法建立复制关系，大概率是主从gtid_mode状态不一致；需执行SELECT @@global.gtid_mode, @@global.enforce_gtid_consistency, @@global.log_bin确认三者均为ON/ON/1，否则修正配置并重启mysqld。
迁移后主从无法建立复制关系，大概率是两边 gtid_mode 状态不一致——比如主库开了 ON，从库还是 OFF，或者反过来。这种配置级不匹配会直接让 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 报错退出，连尝试同步的机会都没有。
检查并确认两端 gtid_mode 是否真正开启
不能只看配置文件里写了 gtid_mode = ON，MySQL 启动时如果依赖项没满足（比如 enforce_gtid_consistency 关着、log_bin 没开），它会静默降级为 OFF，且不报错。
- 在主库和从库分别执行：
SELECT @@global.gtid_mode, @@global.enforce_gtid_consistency, @@global.log_bin; - 三者必须同时为
ON/ON/1，才算真正启用 GTID - 如果任一值为
OFF或0，说明 GTID 实际未生效，需先修正配置再重启 mysqld - 特别注意：修改
my.cnf后必须重启 MySQL 进程，SET GLOBAL对这些变量无效
从库已启 GTID 但主库没开？别硬切 AUTO_POSITION
如果主库 gtid_mode = OFF，而你强行在从库用 MASTER_AUTO_POSITION = 1，会立刻报错 ERROR 1777 (HY000): CHANGE MASTER cannot use MASTER_AUTO_POSITION when master has GTID_MODE = OFF。这不是从库问题，是主库没资格参与 GTID 复制。
- 要么升级主库：停机修改
my.cnf，补全gtid_mode=ON、enforce_gtid_consistency=ON、log_bin=ON，再重启 - 要么降级从库：改用传统 binlog 文件+位点方式复制，即
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy - 切勿在主库未开 GTID 时，试图用
SET GTID_PURGED或RESET SLAVE ALL“绕过”——这只会让从库状态更混乱
两端都开了 gtid_mode，但 SHOW SLAVE STATUS 报 Executed_Gtid_Set 不包含主库的区间
这说明复制链路已断裂，不是配置问题，而是事务历史不连续。常见于迁移时用了逻辑导出（mysqldump）但没加 --set-gtid-purged=ON，或物理备份没正确提取 xtrabackup_binlog_info 中的 GTID。
- 先停复制：
STOP SLAVE; - 确认主库当前完整 GTID：
SELECT @@global.gtid_executed;（记下输出，如a1b2c3e4-...:1-100） - 从库执行前必须关日志：
SET SQL_LOG_BIN = 0;，再设SET GTID_PURGED = 'a1b2c3e4-...:1-100';，最后SET SQL_LOG_BIN = 1; -
GTID_PURGED必须严格等于主库输出，多一个空格、少一位数字都会失败 - 设完立即
CHANGE MASTER TO MASTER_AUTO_POSITION = 1; START SLAVE;，不要中间穿插其他操作
最容易被忽略的是：SET GTID_PURGED 要求从库的 gtid_executed 为空，否则报 Cannot modify gtid_purged because it is not empty。这意味着你必须先确保 RESET SLAVE ALL 已执行、relay log 文件被手动删净、mysqld 进程重启过——任何残留都会让这个赋值失败。
