PolarDB for PG 查杀连接，自己想的很麻烦，其实人家早就有方案

原创于 2025-12-05 06:00:58 发布 · 356 阅读

CC 4.0 BY-SA版权

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

这是一个长系列，我们会记录我们从PostgreSQL 迁移到PolarDB for PG的一个过程，这是长篇的第三篇，这一篇要说的是改变，逐步在生产中使用了PolarDB for PG后我们遇到了一个我们必须遇到，但很快被解决的问题。

这个问题其实我们在PolarDB for MySQL的时候遇到过，就是查询系统信息的问题，这里我们稍微给不懂polardb的小白在补充一点基础知识。

1 PolarDB for PG PolarDB for MySQL 是一个云原生的数据库产品

2 PolarDB for M PolarDB for P 是一个shared storage 的结构（注意PolarDB 是一个数据库体系的名字，不是一个数据库的名字，我们这里仅仅针对我们上述的两个系列里面的产品）

3 PolarDB for PG ，PolarDB for MySQL 必须有代理，且代理是这个云原生数据库关键的部分。

那么我们遇到了什么问题呢？对了查询数据库系统信息和对数据库信息进行一些基础操作的问题。

这里我们举例：我们要查询 PolarDB for PG中的时间超过1分钟的链接，并进行清理。在单机PostgreSQL中，我们只需要运行如下的语句即可。

SELECT 
    pg_terminate_backend(pid)
FROM 
    pg_stat_activity
WHERE 
    state = 'active'
    AND now() - query_start > interval '1 minute'
    AND pid <> pg_backend_pid();

但是在PolarDB FOR PG中，这样操作是错误的。为什么？想学PolarDB for PG的看这里。

PolarDB的简易架构图

我们可以看到我们的所有的连接到数据库中都是通过代理的，代理在接收到数据请求后，开始判断我们的这次处理应该打到那个节点。

代理有以下的功能：

1 区分数据的读或写请求，自动进行可读写分离的语句的读写分离

2 对数据库session进行代理级别的复用，降低建立连接的数量和速度

3 甄别从节点的数据与主节点的数据是否一致，如一致，将数据打入到读库，如果发现数据有不一致情况，将数据访问返回到写节点提取数据，全自动化。

那么这里有问题了，你查询的节点一条查询语句下去，pg_stat_activity读取的数据是一个明确的节点，他要么是，写节点，要么是读节点，或另一个读节点，因为PolarDB 支持15个读节点同时在线。

这就产生一个问题，我们在查询后，我们查杀会出现这样的结果

1 我们查询的节点，不是我们想要查杀的节点

2 我们查询的数据后，再次发起查杀，两次操作，可能并不是同一个节点。

那么这里，数据库的状态收集和数据库的操作，就会出现问题。

怎么办！

方案1，建立功能明晰的代理（但有功能限制）

image

大家看方案1中，代理是可以建立多个，你一个节点建立一个代理是可以的，一个节点可能有多个代理，一个代理也可以有多个节点，有点像绕口令，简略的说，一对多，多对多，多对一，在节点和代理之间的关系是非常灵活的。

方案1中的我们建立只读节点代理，也就是我们图上的从节点代理他只针对从节点，在大部分情况下，1个只读节点就足够了。这样建立后，就形成了，只读节点本身只负责自己的一个只读节点，写节点代理只负责自己的写节点，集群的代理给应用连接使用。

代理就分成两个功能：

1 数据库运行维护类的代理

2 应用系统代理

我们对我们的数据库运维的程序进行重新的梳理，对于一些操作直接接入主节点代理，而另一些则接入到两个运行维护代理中进行使用。

而阿里云的老师给我们一个提议，其实我们并不需要这么麻烦，我们只需要对监控程序进行一个简单的改造就可以，整体的工作并非我们想的那么的复杂。

PolarDB的简易架构图

然后我们还是通过PolarDB 代理，稍微将语句进行一个改动在我们要 pg_stat_terminate(PID) 的select语句前面加入 /FORCE_ALL/ 即可进行广播节点式的查杀工作。

这里需要提醒，不能在查杀语句中直接使用now() 这样的函数，原因很简单，因为每个节点的NOW()得到的时间未必一致，可能有毫秒的差别，那么now() 函数又怎么能返回一个确定的值，所以语句需要修改，将now() 改成一个具体的时间，而这个具体的时间是一个变量我们输入即可，而变量的时间可以通过任意方法产生。当然这不是一个重点。

所以之前是我们多想了，还弄出一个方案1，设计上PolarDB FOR PG FOR MYSQL 两个数据库可以通过集群代理，来访问到数据库运维中所要去的所有节点，而这里有人会提到。

有必要这么麻烦吗？节点固定好不就可以了，你固定去定位到固定的节点也可以，实际上PolarDB 是一个serverless的数据库，也就是他可能上一分钟，是2个节点，下一分钟就弹出一个节点，变成3个节点，你是无法固定这些节点的ID或者位置，所以记住今天说了这么多，PolarDB 中的一个命令。

/Force_ALL/ 他可以解决你在单点上可以解决，在云原生上你认为无法解决的 90%的问题。

好了今天就到这里，每天都是学习知识的一天。

置顶

SQLite 开发中的数据库开发规范 --如何提升业务系统性能避免基础BUG

把我的第一次给 “金仓” 数据库社区活动之我要作妖

给PG鸡蛋里面挑骨头--杭州PostgreSQL生态大会

在杭州阿里云总部数据库会议 20分钟演讲的--背后

该给一头热的AI 降降温了--一盆冷水清醒一下投资的资本

微软布局PostgreSQL 就在昨天发布新品--云厂商爱PG到底是个什么梗！！

2022年 Sqlite白皮书对比DuckDB差异 -- 什么叫做关公战秦琼