MySQL主从复制出错时，关键是要快速定位问题类型并采取相应措施。通常错误集中在连接、数据不一致、SQL执行失败等方面。以下是排查主从复制错误的实用步骤。
检查复制状态
登录到从库，运行以下命令查看复制运行情况：
SHOW SLAVE STATUS\G重点关注以下字段：
Slave_IO_Running：是否正常拉取主库binlog Slave_SQL_Running：是否正常执行中继日志 Last_Error 和 Last_IO_Error：最近的错误信息 Seconds_Behind_Master：延迟时间，为NULL表示复制中断如果任一Running状态为No，说明复制已停止，需根据错误信息进一步分析。
常见错误类型及处理方法
根据错误信息分类处理：
1. 连接类错误（Last_IO_Error）
主库地址、端口、用户名或密码错误：检查CHANGE MASTER TO语句中的参数 网络不通：使用ping和telnet测试主库连通性 主库未授权：在主库执行GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP'2. 数据冲突或重复键错误（Last_SQL_Error）
主键冲突、记录已存在：可能是手动写入了从库或主从数据不一致 表不存在：确认主从结构是否同步，是否有DDL未同步执行临时跳过错误的方法（谨慎使用）：
STOP SLAVE;SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
注意：跳过操作可能导致数据不一致，建议仅用于紧急恢复。
验证数据一致性
使用pt-table-checksum工具对比主从数据是否一致：
pt-table-checksum --host=主库IP --user=root --password=xxx若发现差异，可用pt-table-sync修复：
pt-table-sync --host=主库IP --user=root --password=xxx h=从库IP,D=数据库,t=表 --execute注意：修复前确保从库只读，避免写入冲突。
重置复制（最后手段）
当错误频繁或数据偏差大时，建议重新搭建复制：
在主库执行FLUSH TABLES WITH READ LOCK; 并导出数据（mysqldump） 记录导出时的binlog位置（SHOW MASTER STATUS） 导入从库，解锁主库UNLOCK TABLES 重新配置CHANGE MASTER TO指向正确位置 START SLAVE启动复制基本上就这些。关键是看状态、读错误、对症处理，尽量避免跳过错误，优先保证数据一致。定期监控复制状态能减少突发故障的影响。
