在这篇博客中，我将解释如何从损坏的中继日志文件导致的复制失败中恢复。
MySQL 副本将从其源二进制日志接收到的数据存储在中继日志文件中。该文件可能由于各种原因而损坏，主要是硬件故障。如果发生这种情况，复制将停止工作，并且副本上的错误日志将包含类似于以下内容的条目：
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
一旦您执行建议的检查并发现失败的原因确实是中继日志文件损坏，您可以通过重置副本来恢复复制。
首先，您必须确保源服务器的二进制日志没有损坏。您可以在mysqlbinlog命令的帮助下执行此操作 。只需在二进制日志上运行它，并确保它不会因错误而失败。
要找出当前的二进制日志，请运行命令 SHOW REPLICA STATUS
（或 SHOW SLAVE STATUS ，如果您正在运行 MySQL，早于 8.0.22）。
然后找到 Relay_Source_Log_File ( Relay_Master_Log_File ) 的值：
Relay_Source_Log_File: mysql-bin.000002
这将是副本 SQL 线程从中执行最后一条语句的二进制日志。
另外，请注意 Exec_Source_Log_Pos ( Exec_Master_Log_Pos ) 的值：最近执行的位置。这对于下一步是必要的。
如果您使用 GTID，则需要在Executed_Gtid_Set中找到包含最后一个 GTID 的二进制日志 。
一旦确保源的二进制日志文件是健康的，就可以运行 RESET REPLICA ( RESET SLAVE ) 语句。如https://dev.mysql.com/doc/refman/8.0/en/reset-replica.html所述，“它清除复制元数据存储库，删除所有中继日志文件，并启动新的中继日志文件。它还将使用 SOURCE_DELAY | 指定的复制延迟重置为 0。CHANGE REPLICATION SOURCE TO语句（来自 MySQL 8.0.23）或CHANGE MASTER TO语句（在 MySQL 8.0.23 之前）的 MASTER_DELAY 选项。“
因此，您需要在它之后运行CHANGE REPLICATION SOURCE TO （或 CHANGE MASTER TO）命令。如果您使用基于位置的复制，请将副本指向上一步中记录的 Relay_Source_Log_File和 Exec_Source_Log_Pos。
对于基于 GTID 的副本，使用 SOURCE_AUTO_POSITION = 1 ( MASTER_AUTO_POSITION = 1 )。
原文标题：How to Resolve “Error Reading Relay Log Event” After Relay Log Corruption
原文作者：Sveta Smirnova
原文地址：https://www.percona.com/blog/how-to-resolve-error-reading-relay-log-event-after-relay-log-corruption/
