072024.06

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

2024.06.07

提问:作为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的会话。

图片1.png


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;

图片

2.png


通过排查,找到比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执行效率,就能很大程度上规避这个问题。