MYSQL异常处理日志:主从库同步延迟时间过长的分析

问题描述:

程序上表现为对 主库 更新操作之后,从 从库 查询数据没发生改变。怀疑是主从库同步延迟导致。上从库查看主从同步状态,发现Seconds_Behind_Master时间长达一千多秒。正常情况下主从库延时个十几秒还可以容忍,一千多秒显然就有问题了么。。。

 

问题分析:

我们在一个MYSQL实例上创建了四五个Database,其中一个Database数据量和压力都比较大,从 从库的processlist可以看到从库在处理日志时经常发生lock的状况,但是lock只是压力大database为何会影响到其他database也延迟呢?

 

原来从库是单线程处理同步日志,也就是说无论多少个database都是通过一个线程去执行更新操作,所以主从库同步延迟的时间不是针对database的,是针对一个MYSQL实例的。

 

 

那么,为何从库在处理日志时会发生lock的状态呢?

 

一般我们都将主从库读写分离,主库负责写操作,从库负责读操作。而一般的web应用读数据的操作要远远大于写数据的量,所以我们在主库上几乎看不到因为更新数据导致的lock。那么从库的lock怎么发生的呢?

 

 

从上面可以看出,我们在select的时候默认是会阻塞写请求的,当一个表数据量到达了千万级别,那么执行一个select很有可能就会变得比较费劲,再加上一定的压力,不断地select操作,虽然读数据不会受到影响,但是却阻塞了从库处理同步日志的操作。长此以往。。。可想而知。。。

 

问题处理:

1.首先一个MYSQL实例不要创建太多database,否则一旦其中一个库压力大经常被锁,会导致所有库同步都延迟,你伤不起啊。。。

2.压力较大的情况下使用几个从库值得考量,如果使用多个从库也是可以适当缓解上面lock的情况发生。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值