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 则会被保留。虽然这并不会影响从库复制本身，但还是会有地雷：
- 由于崩溃或停止 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
