MySQL主从复制出现报错时，排查需要系统性地检查主库、从库状态以及复制过程中的各个环节。以下是常见的排查步骤和方法。
1. 查看从库复制状态
登录从库执行以下命令，查看复制线程的运行情况：
SHOW SLAVE STATUS\G重点关注以下字段：
Slave_IO_Running：是否正常连接主库并读取binlog Slave_SQL_Running：是否能正常执行中继日志中的SQL Last_Error 或 Last_IO_Error：最近的错误信息 Seconds_Behind_Master：延迟时间，为NULL表示复制中断如果任一线程为 No，说明复制已中断，需结合错误信息进一步分析。
2. 分析常见错误类型
根据错误信息判断问题类别：
网络连接问题：如“Can't connect to MySQL server”，检查主库IP、端口、防火墙、用户权限等 用户权限不足：确保用于复制的用户（如repl）具有REPLICATION SLAVE权限 GTID或binlog位置不一致：主从gtid_purged不一致或Relay_Log_Pos错乱，可能导致“Could not execute GTID position”类错误 数据冲突：从库存在主库没有的数据，或主键冲突导致SQL线程停止 DDL/DML不兼容操作：如主库执行了DROP TABLE而从库表不存在3. 检查主从配置一致性
确认主从参数设置合理：
主库开启binlog：log-bin = mysql-bin 主从server-id唯一且不重复 若使用GTID，确保gtid_mode=ON，enforce_gtid_consistency=ON 主库binlog_format = ROW推荐使用配置错误常导致复制无法启动或中途失败。
4. 处理复制中断后的恢复
根据错误选择恢复方式：
临时跳过错误：执行SET GLOBAL sql_slave_skip_counter=1（仅限非关键错误） 使用GTID修复：通过SELECT @@GLOBAL.gtid_executed比对主从，并在从库使用SET GTID_NEXT注入空事务 重新搭建复制：备份主库数据并导入从库，重新CHANGE MASTER TO指向正确位置生产环境建议优先采用重建方式，避免数据不一致风险。
基本上就这些。关键是先看
SHOW SLAVE STATUS的输出，定位是IO还是SQL出错，再结合错误日志（
mysqld.log）深入分析。保持主从结构清晰、配置统一，能大幅减少复制问题。
