huaweitman的专栏

专注于数据结构、算法、c/c++、python、数据挖掘等

主从库

问题描述:

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

 

问题分析:

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

 

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

 

 

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

 

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

 

  1. 对MyISAM表的读操作(加读锁),不会阻塞其他进程对同一表的读请求,但会阻塞对同一表的写请求。只有当读锁释放后,才会执行其它进程的写操作。  
  2. 对MyISAM表的写操作(加写锁),会阻塞其他进程对同一表的读和写操作,只有当写锁释放后,才会执行其它进程的读写操作。  
 

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

 

问题处理:

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

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

阅读更多
个人分类: mysql
上一篇$ git push -u origin master
下一篇linux运维
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭