案例分享：Greenplum无法drop表

IT那活儿 2022-11-19

878

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

一

故障描述

收到业务侧在某集群无法正常drop表的情况。就是执行drop语句这条会话会卡在那里，也没有任何报错提示。

二

故障分析

遇到这种情况第一时间想的是会不会两条调度同时对一张表执行dml操作导致的冲突，也就是锁表。于是第一时间查看当前会话。

select * from pg_stat_activity where current_query <> ‘<IDLE>’::text;

加上where条件可以去除空闲会话。

但是drop的时候集群空闲，只有这一个会话。

那会不会是在segment节点的锁冲突导致呢，因为greenplum数据库中的每个segment节点都是相当于一个独立的pg数据库，完全可能出现这种情况。

但是这样的会话怎么定位？生产集群有几十台主机几百个实例总不能一个一个实例登录吧。

这里有个方法，在gp数据库中所有执行的调度中会在Linux层面显示sess_id。

上图不是问题会话，如果在segment节点有残留会话会在idle的位置显示waiting。

找到残留会话就需要登录那个实例：

PGOPTIONS="-c gp_session_role=utility" psql -hip -p端口号 -d实例名

然后查看所有的会话：

select * from pg_stat_activity where current_query <> ‘<IDLE>’::text;

注意看会话开始执行的时间，一般残留会话都是几天前的会话，或者看有没有调度使用到了drop的表。直接清理。

select pg_terminate_backend(‘procpid’);

这样就解决了这个问题。

本文作者：徐瑞(上海新炬王翦团队）

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。