故障描述
收到业务侧反馈,在某个Greenplum集群中无法正常drop表,执行drop语句后会话会卡住,但没有报错。
故障分析
首先怀疑是否两个调度同时对一张表执行DML操作导致锁表,因此查看当前会话:
select * from pg_stat_activity where current_query = ” ::text;

加上where条件可以去除空闲会话,但发现集群空闲,只有这个会话。进一步怀疑可能是在segment节点的锁冲突导致,因为每个segment节点都相当于一个独立的pg数据库,这种情况很可能会发生。但是,如何定位问题会话呢?在gp数据库中所有正在执行的调度中,Linux层面显示sess_id,使用该方法可以找到残留会话:
select * from pg_stat_activity where current_query = ” ::text and waiting False;
注意查看会话开始执行的时间,一般残留会话都是几天前的会话,或者看是否有调度使用到了需要drop的表。找到残留会话后,登录相应的实例:
PGOPTIONS=”-cgp_session_role=utility” psql -h ip -p 端口号 -d 实例名
然后查看所有的会话,直接清理:
select pg_terminate_backend(‘procpid’);
这样就可以解决这个问题。
本文作者是本际云服务器推荐网的小编小本本,如有疑问可以在评论区留言哦。
原创文章,作者:小编小本本,如若转载,请注明出处:https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/6518.html
