官方文档中对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保持一致,重新开始同步,这样在从库中事务不会丢失。这个参数建议开启。是不是很绕,没关系,看实验。
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没有任何关系
再去从库看看当前的从库状态
发现与重启前的状态信息是的一致的