MySQL复制断开是主从架构中常见的问题，处理方式需要根据断开原因快速定位并恢复。核心思路是检查错误、修复数据一致性，并重新启动复制进程。
检查复制状态和错误信息
复制中断后第一步是查看从库的复制状态：
SHOW SLAVE STATUS\G：重点关注 Slave_IO_Running、Slave_SQL_Running 和 Last_Error 字段 如果 IO 线程出错，可能是网络或主库权限问题；SQL 线程出错通常是数据冲突或语句执行失败 记录错误编号（如 1062 唯一键冲突、1032 记录不存在）有助于判断后续操作常见断开原因及应对方法
不同错误需要不同的处理策略：
主库重启或宕机导致连接丢失：通常只需执行 START SLAVE; 自动重连 GTID 或 binlog 位置不一致：确认主库当前 binlog 位置，使用 CHANGE MASTER TO 指定正确 MASTER_LOG_FILE 和 MASTER_LOG_POS 数据不一致导致 SQL 线程停止：可临时跳过错误（SET GLOBAL sql_slave_skip_counter=1;），但需后续校验数据一致性 主库删除了从库正在读取的 binlog：这种情况必须重建从库，因为日志已不可恢复使用 GTID 提高容错能力
启用 GTID 可简化复制管理：
配置 gtid_mode=ON 和 enforce_gtid_consistency=ON 从库断开后可通过 CHANGE MASTER TO MASTER_AUTO_POSITION=1; 自动同步位点 避免手动计算 binlog 位置，降低配置错误风险恢复后的验证与监控
重启复制后不能立即认为完成：
运行 SHOW SLAVE STATUS\G 确认两个线程均为 Yes 观察 Seconds_Behind_Master 是否稳定下降至 0 定期使用 pt-table-checksum 校验主从数据一致性 部署监控工具（如 Prometheus + MySQL Exporter）及时发现异常基本上就这些。关键是快速响应、准确判断错误类型，优先保障服务可用，再逐步修复数据差异。日常维护中建议开启 GTID 并做好备份，能大幅降低复制故障的处理难度。
