首先检查复制状态，使用SHOW SLAVE STATUSG查看Slave_IO_Running和Slave_sql_Running状态及Last_Error信息；再分析错误日志文件hostname.err中与“[ERROR]”或“Replication”相关的记录；最后根据主键冲突、GTID不一致、日志缺失等具体错误类型采取跳过事件、重置GTID或重新配置主从等措施。结合log_slave_updates开启、relay log分析和mysqlbinlog工具可进一步定位问题。
MySQL复制出错时，复制日志是排查问题的关键。通过分析错误信息、查看复制状态和日志内容，可以快速定位并解决问题。
检查复制状态
使用SHOW SLAVE STATUSG命令查看从库的复制状态，重点关注以下字段：
- Slave_IO_Running：IO线程是否正常运行
- Slave_SQL_Running：SQL线程是否正常运行
- Last_Error 和 Last_IO_Error：最近的错误信息
- Seconds_Behind_Master：主从延迟时间
如果某一线程停止，对应错误信息会显示在Last_Error中，这是分析的第一步。
查看错误日志文件
MySQL的错误日志通常位于数据目录下的hostname.err文件中，记录了数据库运行过程中的关键事件。
- 查找包含“[ERROR]”或“Replication”的日志条目
- 关注复制线程启动失败、连接超时、GTID冲突等关键词
- 配合
tail -f hostname.err实时监控日志输出
例如出现“Could not connect to master”，说明网络或权限配置有问题。
分析常见复制错误类型
不同错误需要不同的处理方式：
- 主键冲突或记录不存在：可能是手动修改了从库数据，可用
SET GLOBAL sql_slave_skip_counter=1跳过一条事件（谨慎使用） - GTID不一致：检查主从GTID集合，必要时执行
RESET MASTER或SET GTID_PURGED - 二进制日志找不到：如“Could not find first log file”，需确认主库binlog是否存在，并重新配置CHANGE MASTER TO
- 版本或字符集不兼容：确保主从环境尽量一致
启用详细日志辅助诊断
开启更详细的日志有助于深入分析：
- 设置
log_slave_updates=ON，让从库也写binlog - 使用
SHOW RELAY_LOG EVENTS查看中继日志内容 - 结合
mysqlbinlog工具解析relay log或binlog文件 - 临时增加
--log-warnings=2以记录更多复制警告
通过这些手段，可以看清具体哪条SQL导致复制中断。
基本上就这些。关键是先看状态、再查日志、最后根据错误类型采取对应措施。多数复制问题都能通过这三步解决。