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

问题描述：

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