代码改变世界

【MySQL】relaylog损坏后,如果解决"Error Reading Relay Log Event"

  abce  阅读(1193)  评论(0编辑  收藏  举报

本文来讲解一下复制由于relay log文件损坏而发生失败时,如何恢复。

MySQL复制将接收到的binarylog信息存储到relaylog文件中。relaylog文件可能会因为各种原因而发生损坏,大多数是硬件故障。如果发生了,复制就会停止工作,且errorlog中会有以下类似信息:

1
2
3
4
2022-05-12T12:32:07.282374Z 2 [ERROR] Error in Log_event::read_log_event(): 'Event too small', data_len: 0, event_type: 0
2022-05-12T12:32:07.282386Z 2 [ERROR] Error reading relay log event for channel '': slave SQL thread aborted because of I/O
...
2022-05-12T12:32:07.282396Z 2 [ERROR] Slave SQL for channel '': 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. Error_code: 1594

一旦你根据建议检查日志后,发现的确是因为relaylog文件发生了损坏,你可以通过重置复制来恢复。

 

首先,你要确保主库的binarylog文件没有损坏。可以借助mysqlbinlog命令。

 

想找出是哪个binarylog发生了损坏。可以执行命令show replica status或show slave status。找出Relay_Source_Log_File或Relay_Master_Log_File的值:

1
Relay_Source_Log_File: mysql-bin.000002

这就是sql thread执行最后语句的binarylog文件。

同时,还要注意Exec_Source_Log_Pos或Exec_Master_Log_Pos的值:最后执行的命令的位置。这些信息是下一步需要的。

 

如果开始了GTID,你需要找到Executed_Gtid_Set的值。

一旦你确定binarylog文件是健康的,你可以执行reset replica或reset slave命令。

根据官方文档https://dev.mysql.com/doc/refman/8.0/en/reset-replica.html

1
"it clears the replication metadata repositories, deletes all the relay log files, and starts a new relay log file. It also resets to 0 the replication delay specified with the SOURCE_DELAY | MASTER_DELAY option of the CHANGE REPLICATION SOURCE TO statement (from MySQL 8.0.23) or CHANGE MASTER TO statement (before MySQL 8.0.23). "

会清空复制元数据资料,删除所有的relaylog文件,开启一个新的relaylog文件。也会将在change replication source to命令中参数source_delay、master_delay指定的复制延迟选项设置成0(从MySQL 8.0.23起来);在MySQL 8.0.23之前是change master to命令。

 

然后,你需要执行change replication source to(或者change master to)命令。

如果是基于文件位置的复制,指向复制的Relay_Source_Log_File或Exec_Source_Log_Pos指定的位置;对于基于GTID的复制,只需要SOURCE_AUTO_POSITION=1或MASTER_AUTO_POSITION=1。

 

复制节点上的relaylog文件存储的变化信息可以从主库检索到。因为可以使用reset replica命令安全地移除损坏的relaylog文件,然后重新从主库的binarylog文件加载数据。

请注意在执行此操作之前检查源服务器是否没有刷新所需的二进制日志。

 

相关博文:
阅读排行:
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· .NET10 - 预览版1新功能体验(一)
历史上的今天:
2016-07-24 DG - logical standby switchover切换过程
点击右上角即可分享
微信分享提示