MySQL relay_log_purge=0 时的风险

关注

转载最新推荐文章于 2026-08-05 11:38:03 发布 8.4k 阅读 AI 写同款· GEO 优化 ›

十、MySQL主从架构配置主从复制，默认是通过pos复制（postion），就是说在日志文档里，将用户的每一项操作都进行了编号（pos），每一个event都有一个其实号，一个终止编号，配置主从复制时候，从节点要输入master的log_pos值，就是这个原因，要求它从哪个pos开始同步数据库里的数据，这也是传统的复制技术。MySQL5.6以后，增加了GTID复制（详见第6步）GTID就类似pos的一个作用，不过它是整个mysql复制结构全局通用的，就是说在整个mysql冗余架构中，它们的日志文件里时间的GTID值是一致的。阅读详情

http://ourmysql.com/archives/1453

有时候，我们希望将 MySQL 的 relay log 多保留一段时间，比如用于高可用切换后的数据补齐，于是就会设置 relay_log_purge=0，禁止 SQL 线程在执行完一个 relay log 后自动将其删除。但是在官方文档关于这个设置有这么一句话：

Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe.

究竟是什么样的风险呢？查找了一番后，基本上明白了原因。

首先，为了让从库是 crash safe 的，必须设置 relay_log_recovery=1，这个选项的作用是，在 MySQL 崩溃或人工重启后，由于 IO 线程无法保证记录的从主库读取的 binlog 位置的正确性，因此，就不管 master_info 中记录的位置，而是根据 relay_log_info 中记录的已执行的 binlog 位置从主库下载，并让 SQL 线程也从这个位置开始执行。MySQL 启动时，相当于执行了 flush logs ，会新开一个 relay log 文件，新的 relay log 会记录在新的文件中。如果默认情况 relay_log_purge=1 时，SQL 线程就会自动将之前的 relay log 全部删除。而当 relay_log_purge=0 时，旧的 relay log 则会被保留。虽然这并不会影响从库复制本身，但还是会有地雷：

由于崩溃或停止 MySQL 时，SQL 线程可能没有执行完全部的 relay log，最后一个 relay log 中的一部分数据会被重新下载到新的文件中。也就是说，这部分数据重复了两次。
如果 SQL 跟得很紧，则可能在 IO 线程写入 relay log ，但还没有将同步到磁盘时，就已经读取执行了。这时，就会造成新的文件和旧的文件中少了一段数据。

如果我们读取 relay log 来获取数据，必须注意这一点，否则就会造成数据不一致。而保留 relay log 的目的也在于此。因此，在处理 relay log 时必须格外小心，通过其中 binlog 头信息来确保正确性。

关于如何配置 crash safe 的复制本身的配置，可以参照：
http://blog.itpub.net/22664653/viewspace-1752588/
http://www.innomysql.net/article/34.html

参考资料：
http://blog.booking.com/better_crash_safe_replication_for_mysql.html
https://bugs.mysql.com/bug.php?id=73038
http://bugs.mysql.com/bug.php?id=74324