MySQL升级后主从复制异常的核心原因是版本差异引发的GTID、binlog格式及SQL线程行为兼容性问题，需依次检查复制状态、错误日志、参数一致性并针对性修复。
MySQL升级后主从复制异常，核心原因是版本差异导致的兼容性问题，尤其是GTID、binlog格式、SQL线程行为等关键机制变化。需优先检查复制状态、错误日志和参数一致性，再针对性修复。
确认复制中断的具体错误
登录从库执行 SHOW SLAVE STATUS\G，重点关注以下字段：
- Slave_IO_Running 和 Slave_SQL_Running：判断是IO线程还是SQL线程出错
- Seconds_Behind_Master：为 NULL 表示复制已停止；为 0 不代表正常，需结合 Running 状态看
- Last_IO_Error 或 Last_SQL_Error：直接显示报错信息，如 “Could not execute Write_rows event”、“The slave is connecting using CHANGE MASTER without START SLAVE” 等
- Retrieved_Gtid_Set 与 Executed_Gtid_Set：GTID 模式下两者不一致说明有事务未执行或跳过
检查主从参数与模式是否兼容
MySQL 5.7 升级到 8.0 后常见冲突点：
- 8.0 默认启用 enforce_gtid_consistency=ON 且要求 gtid_mode=ON，若主库未开启 GTID，从库不能以 GTID 模式连接
- binlog_format 必须一致（推荐 ROW），8.0 对 STATEMENT 格式限制更严，某些函数（如 UUID()、SYSDATE()）在 SBR 下会报错
- slave_parallel_type 和 slave_parallel_workers 在 8.0 中逻辑变更，若升级前启用了并行复制，需确认是否与新版本兼容
- 检查 lower_case_table_names：主从必须一致，否则表名解析失败导致复制中断
常见错误的快速修复方式
根据典型报错选择对应操作，red">务必先备份从库数据：
-
“Cannot add or update a child row: a foreign key constraint fails”：说明从库外键校验严格于主库（如主库 skip 到了该语句）。临时关闭外键检查：
SET FOREIGN_KEY_CHECKS=0;，再执行START SLAVE;，恢复后记得设回 1 -
GTID 相关错误（如 “The slave is not configured or failed to initialize GTID state”）：确认主从 GTID 开关状态一致；若从库多执行了事务，可用
SET GTID_NEXT='xxx'; BEGIN; COMMIT;跳过空事务，再SET GTID_NEXT='AUTOMATIC'; START SLAVE; - “Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids”：检查 server-id 是否唯一，升级后配置文件可能被覆盖，需手动核对并重启 mysqld
- SQL 线程卡在某个 position：用
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;手动指定位置重连（适用于非 GTID 模式）
升级后建议做的预防动作
避免下次升级再踩坑：
- 升级前在测试环境完整模拟主从升级流程，包括参数迁移、dump 导入、复制重建
- 主从统一使用 GTID 复制（MySQL 5.6.9+ 支持），便于故障定位和切换
- 升级后立即执行
SELECT VERSION(), @@GLOBAL.GTID_MODE, @@BINLOG_FORMAT;验证关键参数 - 开启 log_slave_updates（尤其在级联复制中），确保从库 binlog 可用于下级同步
