首先查看从库的SHOW SLAVE STATUS\G，判断是IO线程或SQL线程出错；再根据Last_Error、Seconds_Behind_Master等字段定位问题类型，结合错误日志分析具体原因。常见问题包括主键冲突可跳过事务处理，表缺失需手动同步结构，binlog丢失则需重建从库，权限不足要检查复制用户配置。预防措施包括定期校验数据一致性、设置合理binlog保留时间、避免从库写入并监控延迟告警。
MySQL主从复制出错时，首先要快速定位问题来源，判断是网络、权限、数据不一致还是配置问题。以下是常见错误的排查思路和实用技巧。
查看复制状态
登录从库执行SHOW SLAVE STATUS\G，重点关注以下字段：
- Slave_IO_Running：是否正常拉取主库binlog
- Slave_SQL_Running：是否正常执行中继日志
- Last_Error 或 Last_IO_Error：最近的错误信息
- Seconds_Behind_Master：延迟时间，为NULL表示复制中断
通过这些字段可初步判断是IO线程还是SQL线程出错。
常见错误类型及处理方法
1. 主键冲突或记录已存在（Duplicate entry）
通常是主从数据不一致导致。可在从库跳过该事务：
SET GLOBAL sql_slave_skip_counter = 1;
然后重启复制：STOP SLAVE; START SLAVE;。但要注意这可能导致数据偏差，建议先备份并确认影响。
2. 表不存在（Table doesn't exist）
检查主库是否有建表语句未同步，或从库误删表。可手动在从库创建对应表结构，确保与主库一致。
3. 主库binlog被删除或找不到（Could not find first log file）
说明从库请求的binlog已被主库清除。此时需重新搭建从库，使用mysqldump或xtrabackup全量恢复后重建复制关系。
4. 用户权限不足
确认主库用于复制的用户（如repl）有REPLICATION SLAVE权限，并能从从库IP连接。
日志分析辅助定位
查看MySQL错误日志（一般位于/var/log/mysql/error.log或数据目录下的hostname.err），搜索关键字如“error”、“failed”、“slave”等，常能发现更详细的报错上下文。
也可开启general log临时追踪命令执行情况，但生产环境慎用，避免性能影响。
预防与维护建议
- 定期校验主从一致性，可用pt-table-checksum工具
- 合理设置主库binlog过期时间（expire_logs_days）
- 避免在从库写入数据，除非是双主架构且做好冲突控制
- 监控复制延迟，设置告警机制
基本上就这些。多数复制问题都能通过状态查看+日志分析解决，关键是反应快、判断准，不复杂但容易忽略细节。
