主从复制异常需先定位网络、io线程、sql线程或数据不一致原因；执行show slave status\g查看slave_io_running、slave_sql_running、seconds_behind_master等关键字段判断状态。
主从复制异常通常表现为同步延迟或完全中断，核心要先定位是网络、SQL线程、IO线程还是数据不一致导致的问题。
查看复制状态的关键命令
登录从库执行 SHOW SLAVE STATUS\G，重点关注以下字段：
- Slave_IO_Running 和 Slave_SQL_Running：必须都为 Yes，任一为 No 表示复制中断
- Seconds_Behind_Master：大于 0 表示有延迟，持续增长说明同步跟不上
- Relay_Log_Pos 与 Read_Master_Log_Pos 是否接近：差距大可能 IO 线程卡住
- Last_IO_Errno / Last_SQL_Errno：直接显示错误编号，如 1062（主键冲突）、2003（连接失败）、1594（中继日志事件损坏）
常见同步延迟原因与应对
延迟不等于故障，但长期延迟会放大风险。主要诱因包括：
- 从库硬件性能弱于主库（尤其是磁盘 I/O 或 CPU），可考虑升级或调整 slave_parallel_workers 启用并行复制
- 主库突发大批量写入（如 delete from big_table），从库单线程回放慢；可在业务低峰期操作，或拆分大事务
- 从库上执行了非预期的写操作（如误更新系统表），触发唯一键冲突或锁等待；启用 read_only=ON 并限制 super 权限
- 网络抖动或主库 binlog 写入压力高，导致 IO 线程获取日志慢；检查主从间网络延迟和主库 sync_binlog 设置
复制中断的典型错误及修复步骤
根据 Last_SQL_Errno 快速归类处理：
- 错误 1032（记录不存在）或 1062（重复键）：通常是主从数据不一致。先确认是否允许跳过（如测试环境），用 SET GLOBAL sql_slave_skip_counter = 1（MySQL 5.6）或 START SLAVE SQL_THREAD UNTIL ...（MySQL 5.7+ GTID 模式需用 gtid_executed 调整）
- 错误 1594（中继日志损坏）：停止复制，手动指定主库 binlog 文件和位置重启：CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy
- 错误 2003 或 1045：检查主库网络可达性、复制用户权限、密码是否过期；建议使用强密码并定期轮换
- IO 线程停止且无报错：可能是主库 binlog 被清理（expire_logs_days 过小），需重新搭建从库或启用 relay_log_purge=OFF 临时保护中继日志
预防性措施与监控建议
被动处理不如主动防控：
- 部署 pt-heartbeat 工具实时检测逻辑延迟（比 Seconds_Behind_Master 更准）
- 对主从数据一致性做周期性校验，如 pt-table-checksum + pt-table-sync
- 主库开启 binlog_checksum=CRC32，防止日志传输损坏
- 从库配置 slave_net_timeout 和 master_connect_retry 避免短时断连后长时间不重试
- 关键业务避免在从库执行写操作，所有变更走主库，严格遵循读写分离路由规则
