主从复制中断时应先执行SHOW SLAVE STATUS\G定位问题类型,再结合错误日志、中继日志、二进制日志交叉验证;重点关注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 STATUS\G 定位问题类型,再结合错误日志、中继日志、二进制日志交叉验证。日志本身不直接告诉你“哪里断了”,但能告诉你“为什么断”和“断在哪条语句”。
这条命令输出里,重点关注以下几项:
Yes 才算正常;任一为 No 就说明中断Relay log read failure: Could not parse relay log event entry → 中继日志损坏Table 'test.t1' doesn't exist → 从库缺表Duplicate entry '1001' for key 'PRIMARY' → 主从数据不一致导致主键冲突NULL(SQL线程停止时)都提示异常MySQL 错误日志(log_error 指向的文件,常见路径如 /var/log/mysql/error.log 或 /data/mysql/hostname.err)记录的是服务级异常,比如:
relay_log_recovery=1 但未配 skip-slave-start)引发启动冲突用 tail -n 100 /path/to/error.log 查最后百行,重点找 ERROR 或 CRITICAL 关键字。
当中继日志(relay log)损坏或 SQL 线程卡在某条事件时,需用 mysqlbinlog 工具读取:
SHOW SLAVE STATUS\G 中拿到 Relay_Log_File 和 Relay_Log_Pos
mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/relay-bin.000012 | head -n 50Could not parse relay log event entry,说明该文件从某个 offset 开始损坏,此时不能盲目跳过,而应启用 relay_log_recovery=1 并重启 MySQL,让从库自动重建 relay log如果 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 STATUS\G 的输出当作“病历首页”,错误日志是“化验报告”,relay log 和 binlog 是“影像片子”,缺一不可。
以上就是mysql主从复制中断日志怎么看_mysql复制日志解读的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号