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

说了这么多理论，想必实战更让你心动。那我们就拿一个真实案例进行分析---某运营商项目要搭建一套数据库集群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语句执行了长查询，才会导致大量会话等待刷新锁的出现。