主从复制中断时应先执行 SHOW SLAVE STATUSG 定位问题类型，再结合错误日志、中继日志、二进制日志交叉验证；重点关注 Slave_IO_Running、Slave_SQL_Running、Last_IO_Error、Last_SQL_Error、Relay_Master_Log_File、Exec_Master_Log_Pos 和 Seconds_Behind_Master 等字段。
主从复制中断时，关键不是“看日志”，而是 ** 按顺序查三类日志 + 一个状态命令 **：先用 SHOW SLAVE STATUSG 定位问题类型，再结合错误日志、中继日志、二进制日志交叉验证。日志本身不直接告诉你“哪里断了”，但能告诉你“为什么 断”和“断在哪条语句”。
先看从库状态：SHOW SLAVE STATUSG 是第一入口
这条命令输出里，重点关注以下几项：
- Slave_IO_Running 和 Slave_SQL_Running：必须都是
Yes才算正常；任一为No就说明中断 - Last_IO_Error 或 Last_SQL_Error：直接显示最近一次 IO 线程或 SQL 线程报错的完整信息，例如：
Relay log read failure: Could not parse relay log event entry→ 中继日志损坏Table 'test.t1' doesn't exist→ 从库缺表Duplicate entry'1001'for key'PRIMARY'→ 主从数据不一致导致主键冲突 - Relay_Master_Log_File 和 Exec_Master_Log_Pos：表示当前 SQL 线程已执行到主库哪个 binlog 文件及位置点，可用于比对是否落后或跳过
- Seconds_Behind_Master：数值持续增大或为
NULL（SQL 线程停止时）都提示异常
再查错误日志：定位底层系统级或启动类问题
MySQL 错误日志（log_error 指向的文件，常见路径如 /var/log/mysql/error.log 或 /data/mysql/hostname.err）记录的是服务级异常，比如：
- 磁盘满导致 relay log 写入失败
- 权限不足无法创建中继日志文件
- MySQL 启动失败后从库未拉起复制线程
- 配置参数错误（如
relay_log_recovery=1但未配skip-slave-start）引发启动冲突
用 tail -n 100 /path/to/error.log 查最后百行，重点找 ERROR 或 CRITICAL 关键字。
必要时解析中继日志：确认损坏位置或跳过依据
当中继日志（relay log）损坏或 SQL 线程卡在某条事件时，需用 mysqlbinlog 工具 读取：
- 先从
SHOW SLAVE STATUSG中拿到Relay_Log_File和Relay_Log_Pos - 执行：
mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/relay-bin.000012 | head -n 50
可查看开头几十行内容，确认是否可解析 - 若报错
Could not parse relay log event entry，说明该文件从某个 offset 开始损坏，此时不能盲目跳过，而应启用relay_log_recovery=1并重启 MySQL，让从库自动重建 relay log
辅助查主库 binlog：验证是否主库端已无新日志可传
如果 IO 线程停了（Slave_IO_Running: No），但错误信息为空或模糊，需确认主库 binlog 是否还在生成：
- 登录主库执行：
SHOW MASTER STATUS;看当前 binlog 文件名和位置 - 对比从库的
Master_Host、Master_Port是否连得通（telnet master_ip 3306） - 检查主库是否启用了
log_bin，且从库连接账号有REPLICATION SLAVE权限 - 用
mysqlbinlog解析主库最新 binlog 片段，确认是否有合法事件：mysqlbinlog --start-position=12345 /var/lib/mysql/mysql-bin.000064 | tail -n 20
日志不是孤立存在的，它需要和状态、权限、网络、配置四者联动判断。真正有效的排查，是把 SHOW SLAVE STATUSG 的输出当作“病历首页”，错误日志是“化验报告”，relay log 和 binlog 是“影像片子”，缺一不可。
