有时候，我们希望将 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

建议继续学习：

1. server日志的路径分析    (阅读：10200)
2. AWStats简介：Apache/Windows IIS的日志分析工具的下载，安装，配置样例和使用（含6.9中文定义补丁）    (阅读：8948)
3. 利用脚本分析日志并利用snmp自定义OID，再通过cacti画图    (阅读：8745)
4. tomcat catalina.out日志切割每天生成一个文件    (阅读：8133)
5. 分布式日志系统scribe使用手记    (阅读：8095)
6. AWStats是一个基于Perl的WEB日志分析工具。    (阅读：6159)
7. 使用nginx记日志    (阅读：5172)
8. 大于2GB的Listener.log和运行超过198天的主机上的Oracle实例    (阅读：4967)
9. 在 shell 脚本里打日志    (阅读：4836)
10. Sentry: 错误日志集中管理    (阅读：4412)