包拯断案 | 数据库集群出现大量会话等待刷新锁，怎么破？@还故障一个真相

提问：作为DBA运维的你是否遇到过这些烦恼

1、集群会话出现了大量的waiting for table flush，这是怎么产生的？

2、如何快速将数据库集群业务恢复到正常状态？

心中有章，遇事不慌

作为DBA的你，遇到问题无从下手，除了在问题面前徘徊，还能如何选择？如果你一次或多次遇到该问题还是无法解决，又很懊恼，该如何排忧呢？关注公众号，关注《包拯断案》专栏，让小编为你排忧解难~

#包拯秘籍#

一整套故障排错及应对策略送给你，让你像包拯一样断案如神：

 #首先

遇到此类问题后，我们要做到心中有章（章程），遇事不慌。一定要冷静，仔细了解故障现象（与研发/用户仔细沟通其反馈的问题，了解故障现象、操作流程、数据库架构等信息）

#其次

我们要根据故障现象进行初步分析。心中要想：是什么原因导致会话等待刷新锁大量出现？例如：是SQL语句有错误，还是计算节点出了问题？

#然后

针对上述思考，我们需要逐步验证并排除，确定问题排查方向。

#接着

确定了问题方向，进行具体分析。通过现象得出部分结论，通过部分结论继续排查并论证。

#最后

针对问题有了具体分析后，再进行线下复现，最终梳理故障报告。

真刀实战，我们能赢

说了这么多理论，想必实战更让你心动。那我们就拿一个真实案例进行分析---某运营商项目要搭建一套数据库集群binlog server环境，需要dump一份集群元数据，因dump操作导致集群出现大量会话等待刷新锁，这种问题该如何快速分析处理：

1、故障发生场景

在项目现场兢兢业业准备搭建数据库环境的你，花了几分钟想dump一份元数据，几分钟都没导出来，就手动中断了dump操作，几分钟后收到运维反馈：前台访问数据库报错can’t lock file了，DBA心中警铃大作，立马着手排查。

2、故障排查分析

DBA人员首先查询数据库集群状态，发现集群状态都是正常的。接着查询集群活跃会话，发现存在大量waiting for table flush的会话。

Waiting for table flush出现，一定是有会话发出flush tables或flush table with read lock命令。DBA人员浏览了全部会话，并未发现flush tables相关命令，因此联想到刚刚那个未成功备份的操作，怀疑是备份惹的祸。但备份操作已经中止，为什么仍有那么多会话在waiting for table flush呢？一时间没有搞清原因，但解决问题是首要的，当务之急是先处理故障。

3、故障处理

查询全局会话，执行下面语句:

select * from information_schema.greatdb_global_processlists where command!='sleep' order by time;

通过排查，找到比waiting for table flush会话耗时长的语句，发现有一条个人账户执行的SQL语句已经执行了15万秒。根据显示的计算节点IP信息，登录对应计算节点，将此会话kill掉，问题就迎刃而解了，再去查询其他全局会话视图，会发现那些waiting for table flush的语句已经全部消失，数据库集群业务恢复正常，因此主要原因是刚才那个SQL语句执行了长查询，才会导致大量会话等待刷新锁的出现。

复盘总结

01阻塞原因

出现刷新锁一般是因为长查询阻塞了flush tables命令，而flush tables命令又会阻塞其他会话。简单来说与交通道路堵塞是一个原理，一条路不畅通导致了其他道路接连发现拥堵；

02聚焦问题解决

无论flush tables命令是否已中止，只要最初阻塞flush table命令的会话未结束，其他会话仍然会受到阻塞。因此故障发生后，迅速查杀最初阻塞flush table命令的会话，第一时间解决问题是必要的；

03DBA避坑操作指南

对于DBA而言，一是尽量不要在业务高峰期进行备份操作，二是要明确自己发出的备份命令是否会触发flush tables命令。如使用greatsqldump进行备份，--flush logs --single-transaction一起使用时，或者带选项--source-data而不带选项--single-transaction时，都会发出flush tables命令；

04提高SQL执行效率

从根源层面来说，要规避大量会话等待刷新锁的出现这一故障，就要优化系统SQL，提高SQL的执行效率。个人用户执行SQL时要注意：效率低的SQL要及时中止，优化处理后再执行。

此外，由于项目网络环境复杂，前台navicat会话超时中断的SQL也要及时通知DBA，因为数据库此时可能仍在执行着效率低的SQL。因此，提升SQL执行效率，就能很大程度上规避这个问题。