一招教你如何修复MySQL slave中继日志损坏问题

一招教你如何修复MySQL slave中继日志损坏问题

MySQL的Crash safe slave是指在slave崩溃后，重新启动slave可以继续从主服务器进行复制，而不会出现复制错误或数据不一致的问题。要实现这个功能，需要解决由于复制过程中的未同步刷盘导致的binlog文件接收位置与实际位置不一致，或者relay log文件不完整的问题。因此，将relay_log_recovery配置为ON是必需的，这允许在MySQL正常重启或宕机恢复时，SQL线程从slave最后执行的位置重新开始请求binlog。

然而，将relay_log_recovery设置为ON也会带来问题。当设置为ON时，MySQL在重启或宕机恢复时，会从SQL线程的最后执行位置开始请求binlog，这可能会导致由于之前主备时延大，请求点的binlog已经被主服务器清除，从而导致主备复制关系异常。因此，生产环境中通常会将relay_log_recovery设置为OFF。

但是，当设置为OFF时，在操作系统OOM-killer事件或异常断电等情况发生时，可能会导致relay log的部分事件不完整。MySQL重启后，SQL线程在应用relay log时，可能会遇到不完整的事件，从而导致主备复制关系中断。在error.log中，通常会看到类似“innodb: InnoDB: Relay log event is incomplete”这样的错误信息。

在MySQL的复制方式中，分为基于binlog的复制（非GTID模式）和基于GTID的复制。在非GTID模式下，MySQL重启后，通过读取slave_master_info表中的master_log_name和master_log_pos值，向主服务器请求binlog。同时，SQL线程通过读取slave_relay_log_info表中的relay_log_name和relay_log_pos值，开始应用relay log。在GTID模式下，MySQL通过读取mysql.gtid_executed表和binlog文件中的Executed_Gtid_Set，以及realy_log文件中的Retrieved_Gtid_Set，获取执行的GTID，从而确定复制位点。

当设置relay_log_recovery为ON时，MySQL重启或宕机恢复时，会从SQL线程的最后执行位置重新开始请求binlog。这种方式虽然可以避免主备复制关系异常，但可能会导致在OS宕机等情况发生时，MySQL重启后，SQL线程从不完整的relay log事件开始应用，从而导致主备复制关系中断。

为解决上述问题，可以采取以下修复计划：当配置master_info_repository和relay_log_info_repository为TABLE时，SQL线程在提交事务的同时更新slave_relay_log_info表，从而保证SQL线程执行位置的正确性。然而，如果在异常宕机时丢失了master信息，IO线程可能会导致relay log文件的重复dump，或者SQL线程重复执行同一事务，这可能导致主备复制出错。对于非GTID复制模式，这通常需要使用relay_log_recovery=ON作为Crash safe slave的必需参数。

在GTID复制模式下，由于GTID协议保证了数据一致性，并且ev->apply_event时会忽略已执行的事务，因此在设置relay_log_recovery为OFF的情况下，可以清除relay log文件中可能存在的损坏的事件，以避免主备复制关系异常。

为了修复损坏的relay log文件，可以在MySQL启动初始化过程中进行修复。当配置了rds_recovery_relay_log=ON时，可以在初始化Gtid_sets的过程中扫描relay log文件，判断其是否是非正常关闭。如果是非正常关闭，则进入修复流程，扫描整个relay log文件，记录并更新合法事件的位置。如果发现非完整事件，则返回最新合法事件的位置。根据这个位置，截断并清除relay log文件中损坏的部分，以确保主备复制关系的正常进行。

总结起来，通过设置rds_relay_log_recovery参数为ON，可以在OS宕机等情况发生时预防relay_log_recovery=ON带来的潜在问题，即从SQL线程执行完的GTID开始请求的binlog已经被主服务器清除。此外，华为云数据库特惠活动正在进行中，全场10元起购，直降108000元，新购满额送P30 Pro，有兴趣的读者可以点击链接进行抢购。2024-10-26