主从复制异常需系统排查，首先检查SHOW SLAVE STATUS中Slave_IO_Running和Slave_SQL_Running状态及错误信息，确认网络、权限、防火墙和binlog位置是否正常，针对连接失败、SQL执行错误或数据冲突采取相应措施，恢复后使用pt-table-checksum等工具验证数据一致性，并通过监控Seconds_Behind_Master和避免从库写入预防问题。
主从复制异常会影响数据一致性，排查时需要系统性地检查各个环节。以下是常见的排查步骤和方法，帮助快速定位并解决问题。
检查主从复制状态
登录到从库，执行以下命令查看复制线程状态：
SHOW SLAVE STATUS\G重点关注以下字段：
- Slave_IO_Running：是否正常拉取主库的binlog
- Slave_SQL_Running：是否正常执行中继日志中的SQL
- Last_Error 或 Last_IO_Error：最近的错误信息
- Seconds_Behind_Master：延迟时间，为NULL表示复制中断
如果任一线程为 No，说明复制已中断，需结合错误信息进一步分析。
常见异常原因及处理方法
根据错误类型采取对应措施：
1. 连接问题（Last_IO_Error）
- 检查主库网络是否可达：ping 主库IP
- 确认主库允许从库连接，检查GRANT REPLICATION SLAVE权限
- 主库防火墙是否开放3306端口
- 检查主库my.cnf中bind-address配置
2. 数据冲突或SQL执行失败（Last_SQL_Error）
- 可能是从库存在主库没有的数据，或主键冲突
- 可尝试跳过错误事务（谨慎使用）：
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE; - 更安全的方式是手动修复数据后重启复制
3. 主库binlog丢失或位置不一致
- 检查Master_Log_File和Read_Master_Log_Pos是否与主库当前binlog匹配
- 若位置错乱，需重新配置CHANGE MASTER TO指定正确的binlog文件和位置
- 可通过SHOW BINARY LOGS;在主库查看现有binlog
验证主从数据一致性
复制恢复后建议验证数据是否一致：
- 使用pt-table-checksum工具对比主从表数据
- 手动抽查关键表的行数和校验和： CHECKSUM TABLE db_name.table_name;
发现不一致时，可使用pt-table-sync同步差异数据。
预防与监控建议
减少异常发生的关键在于日常维护：
- 定期检查SHOW SLAVE STATUS输出
- 设置监控告警，关注Seconds_Behind_Master突增或复制中断
- 避免在从库执行写操作（除非特殊架构）
- 主库大批量更新后注意观察从库回放情况
基本上就这些。多数复制问题都能通过SHOW SLAVE STATUS找到线索，关键是读懂错误信息并合理应对。不复杂但容易忽略细节。
