一、概述
官方文档中对relay_log_recovery参数的解释
Enables automatic relay log recovery immediately following server startup. The recovery process creates a new relay log file, initializes the SQL thread position to this new relay log, and initializes the I/O thread to the SQL thread position. Reading of the relay log from the master then continues.
上面的英文看不懂，没关系，后面有大白话的翻译加实验，不怕你不懂。
现在我们考虑一个问题，假设当从库意外宕机后，同时从库的relay log也一起损坏了，而主库的日志已经传到了从库，只是从库还没有来得及应用这些日志，那么从库该如何处理？
二、结论
1. 在从库中将relay_log_recovery不设置或者设置为off，如果碰到上面的情形，从库会丢失那些没有应用的日志，主从会不一致。
2. 在从库中将relay_log_recovery设置为on，假如果碰到上面的情形，从库会自动放弃所有未执行的relay log，重新生成一个relay log，并将从库的io线程的position重新指向新的relay log。并将sql线程的position退回到跟io线程的position保持一致，重新开始同步，这样在从库中事务不会丢失。这个参数建议开启。是不是很绕，没关系，看实验。
三、实验
1. 实验环境介绍
mysql版本：5.7.25，操作系统版本：centos6.10
主库ip：10.40.16.61，从库ip：10.40.16.62
从库的参数文件中加入了参数skip-slave-start，防止从库自动启动slave。
2. 将relay_log_recovery设置为off
默认情况这个参数就是off，所以无须设置
查看主库状态
查看从库状态
从上面的输出可以看到，当前主从是同步的，而且从库的relay_log_recovery参数是OFF
关闭从库的sql线程
(root@localhost)[hello]> stop slave sql_thread;
主库随意做几个更改
(root@localhost)[hello]> insert into t1 values(20);
(root@localhost)[hello]> insert into t1 values(30);
在主库查看t1表
在从库查看t1表
查看主库状态
查看从库状态
查看从库的relay log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000010
可以看到主库已经将日志传送到relay log中了，只是从库没有执行而已。现在模拟从库意外宕机。
[root@mysqlb relaybin]# reboot
等从库节点启动完毕后删除从库最后的relay log
[root@mysqlb relaybin]# rm -f slave-relay-bin.000010
然后启动从库
[root@mysqlb relaybin]# service mysql start
查看relay log目录，发现又生成了一个slave-relay-bin.000010
去看看这个重新生成的slave-relay-bin.000010内容
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000010
可以看到啥都没有，这是因为数据库在重启的时候，会自动重新生成一个relay log，但是这个特性跟上面提到的参数relay_log_recovery没有任何关系
再去从库看看当前的从库状态
发现与重启前的状态信息是的一致的
启动从库的slave线程，再去从库看看当前的从库状态
可以看到从库又开始同步了，而且Exec_Master_Log_Pos=Read_Master_Log_Pos，还重新生成了一个slave-relay-bin.000011
再去从库看当前的slave log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000010
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000011
可以看到都是些空事务，也就是从库对于那些还没有执行的语句，全部抛弃了。强制将Exec_Master_Log_Pos移到了Read_Master_Log_Pos。
主库
从库
看到了吧，t1表中的20和30这两条记录就丢失了。
2. 将relay_log_recovery设置为on
在从库参数文件中设置参数(relay_log_recovery = 1)并重启从库
查看主库状态
查看从库状态
停掉重库的sql线程
(root@localhost)[hello]> stop slave sql_thread;
主库做点改动，这次选用t2表
从库查看t2表
从库查看状态
从库查看slave log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000013
可以看到日志已经进入到slave log中了
现在模拟从库意外宕机，等启动后删除从库最新的relay log，跟第一个实验步骤一致
[root@mysqlb relaybin]# reboot
[root@mysqlb relaybin]# rm -f slave-relay-bin.000013
[root@mysqlb relaybin]# service mysql start
查看从库的状态
可以看到Read_Master_Log_Pos已经由重启前的5429退回到了5124，跟Exec_Master_Log_Pos保持一致。
查看从库的relay log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000013
从库照例又生成了一个slave-relay-bin.000013，不过这个依然是个空日志
启动从库的slave线程
(root@localhost)[hello]> start slave;
查看从库的状态
可以看到Exec_Master_Log_Pos没变，Read_Master_Log_Pos增长了，我就在这里不明白，为什么sql线程不去执行日志呢，而且还多了一个线程System lock？
查看relay log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000014
可以看到启动slave线程后，又生成了一个新的relay log，而且之前没有执行的relay log条目的确又进到这个新的relay log中了。但是此刻sql线程并没有执行relay log，应该就是system lock在作怪。
放大招，重启从库来达到释放锁的目的，再启动slave线程
可以看到现在Slave_SQL_Running_State已经不是System lock了。
在从库查看t2表的数据
可以看到数据并没有任何丢失，由此证明在从库中将relay_log_recovery设置为ON，能避免由于从库relay log损坏导致的主从不一致的情形。
四、总结
在从库中最好将relay_log_recovery设置为ON。如果有哪位高手知道system lock是个什么情况，期待您的留言。写作不易，如果帮到了你，希望你点个赞，鼓励下博主。