mysql二进制日志查看工具_记一次生产数据库中继二进制日志损坏导致mysql主从同步故障

概述

生产环境中当并发过高时，有时mysql复制会因中继二进制日志损坏而崩溃，并且无法通过简单的“ start slave”命令将其重启，下面简单记录一下这个现象及解决思路。

---

问题现象

报错如下：

Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

从上面可以看到是中继日志或是Master上的日志出问题了。

首先如果是中继日志坏掉，那只需要找到同步的时间点，然后重新同步，这样就可以有新的中继日志了。如果Master上的日志坏了就得重建了。

---

解决过程

1、确定需要同步的点

应该注意的重要值是 Relay_Master_Log_File和 Exec_Master_Log_Pos。 将需要它们来正确重新启动从属服务器上的复制。

可以看出目前跑到如下位置：

中继日志relay_master_log_file = mysql-bin.000630

中继日志读取位置exec_master_log_pos =135396438

补充：

Master_Log_File，Read_Master_Log_Pos 记录了IO thread读到的当前master binlog文 件和位置， 对应master的binlog文件和位置。

Relay_Log_File，Relay_Log_Pos记录了SQL thread执行到relay log的那个文件和位置，对应的是slave上的relay log文件和位置。

Relay_Master_Log_File，Exec_Master_Log_Pos记录的是SQL thread执行到master binlog的文件和位置，对应的master上binlog的文件和位置。

---

2、重新启动复制

--如果不是GTID按以下步骤STOP SLAVE;RESET SLAVE;CHANGE MASTER TO master_log_file='mysql-bin.000630', master_log_pos=135396438;START SLAVE;--如果配置了GTID主从按以下步骤STOP SLAVE;RESET SLAVE;CHANGE MASTER TO MASTER_HOST='1xxxx',MASTER_USER='repl',MASTER_PASSWORD='rxxxx',MASTER_AUTO_POSITION=1;START SLAVE;

---

3、再次检查主从

在以同步方式调用从库之前，从状态命令中检查参数 Seconds_Behind_Master 的值可知主从同步延迟的状态(90524秒)，半小时后恢复正常，主从延迟为0。

show slave status G;

过半个小时后：

---

后面会分享更多devops和DBA方面内容，感兴趣的朋友可以关注下~