I. Overview
官方文档中对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.
Above do not understand English, it does not matter, followed by the translation of experimental vernacular, afraid you do not understand.
We now consider a question, assume that when the library from unplanned downtime, while from the relay log with the library also damaged, and the main library log has spread from the library, but the library has not had time to use these logs, then from the library how to deal with?
CONCLUSIONS
1 is not provided or set off in the library from the relay_log_recovery, encountered if the above case, that will be lost from the library without logging applications, the master will be inconsistent.
2. Set in the library from relay_log_recovery is on, false if you encounter the above situation, will not give up the implementation of all relay log from the library, rebuild a relay log, and redirected to the new position io thread from library the relay log. Sql thread position and return to be consistent with the position io thread, start the synchronization again, so that the transaction will not be lost from the library. This parameter is recommended that you turn. Is not it around, it does not matter, look at the experiment.
Third, experiment
1. Introduction experimental environment
mysql version: 5.7.25, operating system version: centos6.10
main library ip: 10.40.16.61, ip from the library: 10.40.16.62
added parameter skip-slave-start parameter file from the library, from the library to prevent the automatic start slave .
2. relay_log_recovery set off
By default, this parameter is off, there is no need to set
Check the main library status
View from the library status
Can be seen from the above output from the current master is synchronized, and the parameters from the library is OFF relay_log_recovery
Close the sql threads library
stop slave sql_thread (root @ localhost) [hello]>;
Libraries to be made several changes to the master
(the root @ localhost) [Hello]> INSERT INTO T1 values (20 is);
(the root @ localhost) [Hello]> INSERT INTO T1 values (30);
View t1 table in the main library
In the view from the library table t1
Check the main library status
View from the library status
View log from the relay library
[root @ mysqlb relaybin] # mysqlbinlog -vv slave-relay-bin.000010
You can see the main library has been transferred to the relay log in the log, but did not execute it from the library. Now the simulation from the library unplanned downtime.
[root @ mysqlb relaybin] # reboot
Once finished booting from the library node to delete log from the last relay library
[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;
From the status of the library can be seen Exec_Master_Log_Pos not changed, Read_Master_Log_Pos growth, and I do not understand here why not sql thread execution log it, but also more than a thread System lock?
Check relay log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000014
After you can see the start slave threads, but also generated a new relay log, and relay log entries not previously executed and indeed into the new relay log in the. But at the moment sql thread does not perform relay log, system lock should be is at play.
Zoom trick, restart from the library to achieve the purpose of releasing the lock, and then start the slave threads
Slave_SQL_Running_State can see now is not the System lock up.
See table t2 from the repository data can be seen and without any loss of data, thus confirming it from the library relay_log_recovery set to ON, the main relay log can avoid the damage caused from the library from the inconsistencies.
IV Summary
It is preferably provided in the relay_log_recovery from the library to ON. If there is any expert system lock to know what the situation is, we look forward to your message. Writing is not easy, if you help, I hope you point a praise, encouragement bloggers.