答案：排查MySQL主从复制错误需先检查复制状态，重点关注Slave_IO_Running和Slave_SQL_Running及错误信息，根据连接、数据冲突等不同错误类型采取修复措施，必要时重置复制。
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启动复制
基本上就这些。关键是看状态、读错误、对症处理，尽量避免跳过错误，优先保证数据一致。定期监控复制状态能减少突发故障的影响。
