MySQL主从复制中断后应先通过SHOW SLAVE STATUS定位IO或SQL线程异常及错误码，再按类型修复：IO中断查网络权限后START SLAVE；SQL中断依错误可逆性选择跳过或重建；binlog丢失必须重搭从库；恢复后须验证线程状态、延迟和数据一致性，并启用GTID、延长binlog保留期等预防措施。
MySQL主从复制中断后，恢复的核心是快速定位错误类型，再选择匹配的修复路径。不是所有中断都该跳过，也不是所有情况都要重搭——关键看 错在IO线程还是SQL线程、错误是否可逆、binlog是否还在主库。
一、先查状态，锁定问题根源
登录从库执行：
SHOW SLAVE STATUS\G
重点关注三项：
- Slave_IO_Running：为 No，说明连不上主库（网络、权限、主库宕机、防火墙）
- Slave_SQL_Running：为 No，说明中继日志执行失败（数据冲突、表结构不一致、语句非法）
- Last_Error：直接告诉你错在哪，比如 Error_code: 1062（主键重复）、Error_code: 1032（记录不存在）、Got fatal error 1236（binlog文件丢失）
二、按错误类型分策略处理
● IO线程中断（连不上主库）
- 检查主库是否存活、端口是否可达、复制账号是否存在且授权正确
- 确认主库 show master status 是否能正常返回
- 修复后直接 START SLAVE;，通常自动重连
● SQL线程中断（执行出错）
- 若错误明确且非关键（如临时表不存在、某条INSERT重复），可用 SET GLOBAL sql_slave_skip_counter = 1; 跳过一条事件，再 START SLAVE;
- 若错误反复出现（如持续主键冲突），说明主从数据已不一致，跳过只是掩耳盗铃，需人工比对或重建从库
- GTID模式下，不能用 skip_counter，应改用 SET GTID_NEXT='xxx'; BEGIN; COMMIT; 或重置 gtid_purged 后重新配置
● binlog丢失（1236错误）
- 主库已删掉从库要拉取的 binlog 文件，无法追平
- 必须重建从库：主库全量备份（mysqldump --master-data=2 --single-transaction 或 xtrabackup）→ 传到从库 → 导入 → 根据备份文件里的 CHANGE MASTER TO 语句重配 → START SLAVE
三、恢复后必须验证
启动复制不等于恢复成功，还要确认：
- SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes
- Seconds_Behind_Master 在缓慢下降并趋近于 0（注意：值为 NULL 表示 SQL 线程未运行）
- 抽样比对主从关键表行数、校验和（如 SELECT COUNT(*), MD5(GROUP_CONCAT(id)) FROM t1;）
- 如有条件，用 pt-table-checksum 工具做全量一致性校验
四、预防比抢救更重要
日常运维建议：
- 主从全部启用 GTID（gtid_mode=ON + enforce_gtid_consistency=ON），避免位点错乱
- 主库 binlog 至少保留 7 天（expire_logs_days=7），防止从库延迟过大被清理
- 从库设 read_only=ON，禁止应用直写，减少人为不一致
- 部署监控（如 Prometheus + mysqld_exporter），对 Seconds_Behind_Master > 60、线程异常等告警
