关闭

主从库

836人阅读 评论(1) 收藏 举报
分类:

问题描述:

程序上表现为对 主库 更新操作之后,从 从库 查询数据没发生改变。怀疑是主从库同步延迟导致。上从库查看主从同步状态,发现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的情况发生。

1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1006965次
    • 积分:14449
    • 等级:
    • 排名:第826名
    • 原创:680篇
    • 转载:69篇
    • 译文:1篇
    • 评论:105条
    文章分类
    最新评论