MySQL relay_log_purge=0 时的风险

转自： http://xiezhenye.com/2015/12/mysql-relay_log_purge0-%E6%97%B6%E7%9A%84%E9%A3%8E%E9%99%A9.html

 

有时候，咱们但愿将 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 则会被保留。虽然这并不会影响从库复制自己，但仍是会有地雷：

1. 因为崩溃或中止 MySQL 时，SQL 线程可能没有执行彻底部的 relay log，最后一个 relay log 中的一部分数据会被从新下载到新的文件中。也就是说，这部分数据重复了两次。
2. 若是 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