mysql recovery参数_Mysql - 关于relay_log_recovery参数的测试

一、概述

官方文档中对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,所以无须设置

查看主库状态

7173fcd75bc35dfd2cfbc87827568757.png

查看从库状态

f2fa8a9ed301b6859c525c324167b844.png

从上面的输出可以看到,当前主从是同步的,而且从库的relay_log_recovery参数是OFF

关闭从库的sql线程

([email protected])[hello]> stop slave sql_thread;

主库随意做几个更改

([email protected])[hello]> insert into t1 values(20);

([email protected])[hello]> insert into t1 values(30);

在主库查看t1表

7cf519d05677fbf6f13a1f4a13883321.png

在从库查看t1表

2df97d5144c8dadace07d1ae1ad20849.png

查看主库状态

2aed55107c437a24f87b243e8c6df895.png

查看从库状态

b8555ab5b277a03e59b70b1e04bf5543.png

查看从库的relay log

[[email protected] relaybin]# mysqlbinlog -vv slave-relay-bin.000010

591455a33cd13ee2f132bf0c4db1fcc0.png

可以看到主库已经将日志传送到relay log中了,只是从库没有执行而已。现在模拟从库意外宕机。

[[email protected] relaybin]# reboot

等从库节点启动完毕后删除从库最后的relay log

[[email protected] relaybin]# rm -f slave-relay-bin.000010

然后启动从库

[[email protected] relaybin]# service mysql start

查看relay log目录,发现又生成了一个slave-relay-bin.000010

22ceaad9d69982605bd9bb3ff265b453.png

去看看这个重新生成的slave-relay-bin.000010内容

[[email protected] relaybin]# mysqlbinlog -vv slave-relay-bin.000010

8328965af1c94c82fe24b314f2235bd8.png

可以看到啥都没有,这是因为数据库在重启的时候,会自动重新生成一个relay log,但是这个特性跟上面提到的参数relay_log_recovery没有任何关系

再去从库看看当前的从库状态

0755afde224a12159b51c53e805354d9.png

发现与重启前的状态信息是的一致的

启动从库的slave线程,再去从库看看当前的从库状态

f4add33ad6b3c20974aebc10a9323fb5.png

可以看到从库又开始同步了,而且Exec_Master_Log_Pos=Read_Master_Log_Pos,还重新生成了一个slave-relay-bin.000011

再去从库看当前的slave log

125cee79de600b8ddb08ca9051548ffc.png

[[email protected] relaybin]# mysqlbinlog -vv slave-relay-bin.000010

f999d57f9f21f7aa413c081ca2e5ed67.png

[[email protected] relaybin]# mysqlbinlog -vv slave-relay-bin.000011

fff9ae0d33176fe5c4504bb94397fd0f.png

可以看到都是些空事务,也就是从库对于那些还没有执行的语句,全部抛弃了。强制将Exec_Master_Log_Pos移到了Read_Master_Log_Pos。

主库

a23b4cf5d09b4c9ea42b99fabe45a2fb.png

从库

d4710da3b8ae07dd372ac8446ae913b5.png

看到了吧,t1表中的20和30这两条记录就丢失了。

2. 将relay_log_recovery设置为on

在从库参数文件中设置参数(relay_log_recovery = 1)并重启从库

6c6cc397c761ceca3d5f9d29ccb69f9c.png

查看主库状态

1cba21cadad3ba0b01000830f92f69f1.png

查看从库状态

41246c4936d46e13d8c04ed865bf6dc8.png

停掉重库的sql线程

([email protected])[hello]> stop slave sql_thread;

主库做点改动,这次选用t2表

00257a37befa3b84395e796389f96562.png

从库查看t2表

39fc40f05858e6e627f2ce0e5c188296.png

从库查看状态

77edc44262f44ef5a10bc3e842d17fbd.png

从库查看slave log

[[email protected] relaybin]# mysqlbinlog -vv slave-relay-bin.000013

3450078649c61abdfa1917ebdc20e206.png

可以看到日志已经进入到slave log中了

现在模拟从库意外宕机,等启动后删除从库最新的relay log,跟第一个实验步骤一致

[[email protected] relaybin]# reboot

[[email protected] relaybin]# rm -f slave-relay-bin.000013

[[email protected] relaybin]# service mysql start

查看从库的状态

40e20290b5e0387df7132d00a896cd28.png

可以看到Read_Master_Log_Pos已经由重启前的5429退回到了5124,跟Exec_Master_Log_Pos保持一致。

查看从库的relay log

8143074cd8db4beac15b1466cd62abc9.png

[[email protected] relaybin]# mysqlbinlog -vv slave-relay-bin.000013

4a5749f555c4a93750511f586962e32f.png

从库照例又生成了一个slave-relay-bin.000013,不过这个依然是个空日志

启动从库的slave线程

([email protected])[hello]> start slave;

查看从库的状态

327c902a76fc5635a78376de0e8d2744.png

可以看到Exec_Master_Log_Pos没变,Read_Master_Log_Pos增长了,我就在这里不明白,为什么sql线程不去执行日志呢,而且还多了一个线程System lock?

查看relay log

24ed549c192e5d0cdf5d8f752f22d1bc.png

[[email protected] relaybin]# mysqlbinlog -vv slave-relay-bin.000014

7cf31af7b418a9f1da745a5b42c956f5.png

可以看到启动slave线程后,又生成了一个新的relay log,而且之前没有执行的relay log条目的确又进到这个新的relay log中了。但是此刻sql线程并没有执行relay log,应该就是system lock在作怪。

放大招,重启从库来达到释放锁的目的,再启动slave线程

ffeb41d99fd568b793bd448174667276.png

可以看到现在Slave_SQL_Running_State已经不是System lock了。

在从库查看t2表的数据

9797f840184ee5d4715f008ec712af1c.png

可以看到数据并没有任何丢失,由此证明在从库中将relay_log_recovery设置为ON,能避免由于从库relay log损坏导致的主从不一致的情形。

四、总结

在从库中最好将relay_log_recovery设置为ON。如果有哪位高手知道system lock是个什么情况,期待您的留言。写作不易,如果帮到了你,希望你点个赞,鼓励下博主。

原文:https://www.cnblogs.com/ddzj01/p/11592148.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值