先查看从库复制状态，通过SHOW SLAVE STATUS\G检查Slave_IO_Running和Slave_SQL_Running是否为Yes，结合Last_Error分析错误类型，确认网络、权限、GTID或数据冲突问题，核对主从配置如log-bin、server-id、gtid_mode等参数一致性，根据错误选择跳过、GTID修复或重建复制，优先重建避免数据不一致。
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）深入分析。保持主从结构清晰、配置统一，能大幅减少复制问题。
