问题描述
检查从机状态时出现以下错误
中继日志读取失败:无法解析中继日志事件条目。可能的原因有:master的二进制日志损坏(可以通过运行'MysqLbinlog'查看二进制日志),slave的relay log损坏(可以通过运行'MysqLbinlog'查看relay log),a网络问题,或者 master 或 slave 的 MysqL 代码中的错误。如果你想查看master的二进制日志或者slave的relay log,你可以通过在这个slave上发出'SHOW SLAVE STATUS'来知道它们的名字。
我将 Bitnami 的 MariaDB 与复制一起使用,其中我有 1 个主节点和 2 个从节点,其中一个节点似乎已损坏并且出现上述错误。
解释我在节点停止工作时采取的步骤
解决方法
我已经通过以下步骤解决了同样的问题。
查看当前从机状态执行命令:
show slave status\G
您应该会看到与此类似的结果:
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: provisioner-peer
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000149
Read_Master_Log_Pos: 919065590
Relay_Log_File: mysql-relay-bin.000450
Relay_Log_Pos: 884188250
**Relay_Master_Log_File: mysql-bin.000149**
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1594
Last_Error: 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 run
ning '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.
Skip_Counter: 0
**Exec_Master_Log_Pos: 884187951**
Relay_Log_Space: 919067911
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1594
Last_SQL_Error: 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 run
ning 'mysqlbinlog' on the binary log),you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
Replicate_Ignore_Server_Ids:
Master_Server_Id: 287
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 1
1 row in set (0.000 sec)
您应该注意的重要值是 Relay_Master_Log_File 和 Exec_Master_Log_Pos。您将需要它们来正确地重新启动从属服务器上的复制。
要重新启动复制,请执行以下命令:
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO master_log_file='mysql-bin.000149',master_log_pos=884187951;
START SLAVE;
要检查复制是否再次工作,请再次执行命令:
show slave status\G
在您将您的从站称为同步之前,请检查状态命令中参数 Seconds_Behind_Master 的值。在我们的例子中,我看到了值(7971 秒):
Seconds_Behind_Master:7971
在接下来的几分钟内,复制再次与主同步,复制延迟为 0 秒
注意:为了安全起见,首先备份你的数据库