17370845950

MySQL复制中断后应先定位原因、检查数据一致性再安全恢复，而非直接重启复制；需通过SHOW SLAVE STATUS分析IO/SQL线程状态、错误码、位点及GTID信息，按主键冲突、表缺失、binlog删除、GTID冲突等类型采取对应修复措施，并用pt-table-checksum校验一致性。

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 操作前，在从库手动预检（如是否存在同名表、字段类型是否兼容）