xtrabackup flush all tables with read lock中的坑

xtrabackup flush all tables with read lock中的坑

xtrabackup不失为一种很好的备份方式，但是使用不当的情况下可能会造成让你万劫不复的后果。

场景描述：

某日凌晨两点多，开发发现使用一个业务账号链接数据库时，发现报too many connections的错误，随即通过zabbix查看数据库链接，

然后去看zabbix监控的tcp连接，然后发现数据库链接突然飚上去了，

然后接着业务开始报警，登陆服务器发现连接暴增，有很多等待flush table线程（备份在flush table）然后退出后，登陆不上。

解决过程:

第一时间dev向我反应错误的时候，以为是他使用的账号做了链接限制，但是进去之后发现，此账号仅仅只有20个链接左右，并且大多数sleep状态，

然后，zabbix开始报警，我使用root账号进入数据库，通过show processlist，链接已经到了4000多，直到5000（数据库最大连接数），

所有链接处在锁等待的状态，是因为xtrabackup在进入最后阶段时，又一个flush all tables with read lock，而就是在这个阶段的时候，遇到了dev的一个select count（*） from 一个两亿3千万条记录的表，此查询执行下来，进行了2万多秒。

此时本业务基本上处于瘫痪状态，更重要的是，另外一个业务的链接在等此库返回的数据（业务依赖），已经处在基本上整个app不能使用的状态了。当时跟op协商停服处理，但实际上是不需要的，要不就是我kill掉这个全表扫，放flush table with read lock，要不就是kill 备份。

随后的做法是，kill点了备份进程，（此时，备份是次要的），放所有链接通过，数据库链接才慢慢降低下来，有兴趣的同学可以看一下我之前的帖子，xtrabackup备份的过程

最后总结：

慢查询语句一定要定时查看，甚至应该设置日志警报，因为说不定哪个开发的一条语句，与你自己的计划相冲突，可能就会导致异常灾难。在制定备份计划时，还是要多加考虑的。