MySQL 复制中断后应先定位原因、检查数据一致性再安全恢复，而非直接重启复制；需通过 SHOW SLAVE STATUS 分析 IO/SQL 线程状态、错误码、位点及 GTID 信息，按主键冲突、表缺失、binlog 删除、GTID 冲突等类型采取对应修复措施，并用 pt-table-checksum 校验一致性。
MySQL 复制中断后，关键不是立刻重启复制，而是先确认中断原因、检查数据一致性、再选择安全的恢复方式。盲目执行 START SLAVE 可能导致主从数据错乱或跳过关键事务。
定位复制中断的具体位置和原因
登录从库执行：SHOW SLAVE STATUSG
重点关注以下字段：
- 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 操作前，在从库手动预检（如是否存在同名表、字段类型是否兼容）
