MySQL 复制中断后，关键不是立刻重启复制，而是先确认中断原因、检查数据一致性、再选择安全的恢复方式。盲目执行
START SLAVE可能导致主从数据错乱或跳过关键事务。
定位复制中断的具体位置和原因
登录从库执行：
SHOW SLAVE STATUS\G
重点关注以下字段： Slave_IO_Running 和 Slave_SQL_Running：判断是 IO 线程（拉日志失败）还是 SQL 线程（执行中出错）中断 Last_IO_Errno / Last_IO_Error：网络、权限、主库 binlog 被删等 IO 层问题 Last_SQL_Errno / Last_SQL_Error：常见如主键冲突、表不存在、DDL 不兼容、GTID 冲突等 Relay_Master_Log_File 和 Exec_Master_Log_Pos：记录从库已执行到主库哪个 binlog 文件和位置 Retrieved_Gtid_Set 和 Executed_Gtid_Set（GTID 模式下）：对比差集可看出哪些事务未执行
常见异常类型及对应恢复操作
根据错误类型选择处理策略，避免“一刀切”跳过错误：
主键/唯一键冲突（Errno 1062）：先查冲突记录是否合理（比如业务误写从库），再决定是跳过单条（SET GLOBAL sql_slave_skip_counter = 1）还是人工修复数据后恢复 表不存在（Errno 1146）：检查该表是否在主库已创建但未同步到从库（如忽略库配置不当），需补建表结构，再恢复复制 binlog 被删除或找不到（IO 线程失败）：确认主库
expire_logs_days设置是否过小；若缺失日志不可补，需重新搭建从库 GTID 冲突（如 Attempted to execute replication event with GTID that was already executed）：用
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;查当前卡点，必要时用
SET GTID_NEXT='xxx'; BEGIN; COMMIT;注入空事务跳过
验证并确保主从数据一致后再启用复制
不能只看
Seconds_Behind_Master = 0就认为一致。建议： 用
pt-table-checksum（Percona Toolkit）校验主从表级数据一致性，尤其对核心业务表 对比主从库的
SHOW MASTER STATUS和
SHOW SLAVE STATUS中的 binlog 位置或 GTID 集合是否完全匹配 抽样比对关键表的行数、校验和（如
CRC32(CONCAT(...))）、时间范围数据 确认从库无写入（
read_only=ON已启用），防止二次污染
预防复制中断的实用建议
多数中断源于配置疏漏或运维操作不规范：
主库开启binlog_format = ROW，避免语句级复制的不确定性 从库设置
read_only = ON+
super_read_only = ON（MySQL 5.7+），禁止意外写入 定期清理 relay log（
relay_log_purge = ON），但避免与
sync_relay_log = 0同时使用 监控项至少包括：
Seconds_Behind_Master、SQL/IO 线程状态、relay log 磁盘空间、复制错误码告警 所有 DDL 操作前，在从库手动预检（如是否存在同名表、字段类型是否兼容）
