MySQL主从复制中断是配置错位的明确信号，关键需检查gtid_mode、binlog_format、sql_mode等运行时参数是否对齐，而非仅看版本号；Slave_IO_Running或Slave_SQL_Running为No时，应先通过SHOW SLAVE STATUS\G定位具体错误类型再操作。
主从复制中断不是升级失败的终点，而是配置错位的明确信号——8.0 的 GTID、binlog 格式、SQL 模式三者中只要一个没对齐，复制就会卡在 Slave_SQL_Running: No 或直接报错退出。
检查 SHOW SLAVE STATUS\G 中的关键字段
别急着重启或跳过事务，先看清楚到底是哪一层断了：
-
Slave_IO_Running: No：说明从库连不上主库，重点查网络、权限、server_id冲突（升级后配置文件常被覆盖）、主库 binlog 是否被 purge -
Slave_SQL_Running: No且Last_SQL_Error含GTID字样：大概率是主从gtid_mode开关不一致，或从库执行了未被主库记录的事务 -
Seconds_Behind_Master: NULL：复制已完全停止，需结合Retrieved_Gtid_Set和Executed_Gtid_Set判断是否出现 GTID 跳变或空洞 -
Last_IO_Error出现ERROR 1236：典型是主库 binlog 被清理，而从库还依赖其中的 GTID；若错误含unknown variable，说明从库启动时读到了 8.0 新增参数（如transaction_write_set_extraction），配置文件里混入了不兼容项
验证主从运行时参数是否真正对齐
版本号只是表象，真正起作用的是运行时参数。在主库和从库上分别执行：
SELECT @@gtid_mode, @@enforce_gtid_consistency, @@binlog_format, @@sql_mode, @@character_set_server, @@collation_server;
重点关注以下组合是否一致：
-
gtid_mode必须同为ON或同为OFF；若主库是 5.7 且未开启 GTID，从库 8.0 就不能用MASTER_AUTO_POSITION = 1 -
binlog_format必须都是ROW；8.0 对STATEMENT模式更严格，某些函数（如UUID()）会直接报错 -
sql_mode差异会导致 SQL 线程执行失败，比如主库允许非标准 GROUP BY，从库因启用ONLY_FULL_GROUP_BY直接拒绝 -
character_set_server和collation_server不一致可能引发比较异常，尤其在 WHERE 条件含中文或大小写敏感字段时
快速修复常见中断类型
根据错误现象选择最小侵入操作，所有操作前务必确认从库数据已备份：
- 报错
Cannot add or update a child row: a foreign key constraint fails：临时关闭外键检查：SET FOREIGN_KEY_CHECKS=0;，再START SLAVE;；恢复后立即设回=1 - GTID 错乱（
Retrieved_Gtid_Set为空但Executed_Gtid_Set有值）：说明从库多执行了事务，用SET GTID_NEXT='xxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:1'; BEGIN; COMMIT;跳过一个空事务，再SET GTID_NEXT='AUTOMATIC'; START SLAVE; - 主库是 5.7、从库是 8.0 但复制启动就失败：禁用 GTID 连接，改用 file/pos 方式：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154, MASTER_AUTO_POSITION=0; - 主库是 8.0、从库是 5.7 报
ERROR 1236：主库必须关闭 GTID：SET GLOBAL gtid_mode = OFF_PERMISSIVE; SET GLOBAL gtid_mode = OFF;，并确认enforce_gtid_consistency=OFF；否则 5.7 无法解析 8.0 的 writeset 信息
最易被忽略的一点：升级后 lower_case_table_names 值可能被重置，主从不一致会导致表名解析失败，复制无声中断——这个参数一旦初始化就不能改，必须在初始化阶段就统一好。
