Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1725013
  • 博文数量: 362
  • 博客积分: 10587
  • 博客等级: 上将
  • 技术积分: 4098
  • 用 户 组: 普通用户
  • 注册时间: 2009-09-10 18:15
文章分类

全部博文(362)

文章存档

2014年(1)

2013年(58)

2011年(115)

2010年(112)

2009年(76)

分类: Mysql/postgreSQL

2011-08-13 13:59:11

问题描述:

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

阅读(2414) | 评论(0) | 转发(1) |
0

上一篇:MySQL主从同步关键句

下一篇:php连接mysql

给主人留下些什么吧!~~