mysql slave同步异常处理过程

最近一个mysql备库的/log目录使用率告警，登陆检查发现是relaylog目录占用的，relaylog在应用后是自动删除的，但log目录下保存了40多天的日志。

初步怀疑是因为slave进程断掉导致无法应用，积压了日志。

从slave状态看，进程都正常，至少没有断开。但是RELAY_LOG_POS和RELAY_LOG_FILE是一直不变的，SLAVE_SQL_RUNNING_STATE在等待waiting for dependent transaction to commit.

在网上查了一些资料，都认为此种现象是由长事务导致的。但对于此次的故障不适用，因为已经延迟了四十多天了，继续等似乎不会解决问题。

这时想起登陆数据库时，因为服务器上装了不同端口数据库，在ps -ef|grep mysql时发现有很多备份进程，都是在出问题的这个端口上。会不会和备份进程有关呢？

继续检查数据库的进程

通过系统和数据库内部进程看，初步可以判断是因为备份进程导致的slave同步异常，slave应用从最早的备份进程那天就停止了。

经过咨询二线，判定就是因为备份进程导致了同步延迟。

Waiting for global read lock和Waiting for commit lock 产生了互斥。

所以，kill掉这些备份进程就可以了。

在kill掉备份进程后，slave已经正常同步。

这个问题暂时通过表象来判断原因，并没有很彻底的理解（模拟重现），后面能重现这个问题时会再写一下测试步骤和大家分享。有理解的小伙伴也可以发一下步骤，怎样重现上面的问题。