PostgreSQL 从库查询被莫名KILL，为什么，群友问题--大聪明给你回答一下

AustinDatabases

发布于 2026-03-12 19:03:11

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

最近一篇文章，引出一个群里的同学的问题，他是看完PolarDB for PG中的对于PG 数据库主从复制中的关于在主库进行vacuum 或者checkpoint的时候，从库正在运行的SQL会被kill的问题的原因是什么的思考。

PG的主从复制与PolarDB的主从模式区别

我们确认几点

1 PG 的主从复制是通过streaming replication 流复制机制，将主库的WAL中的操作，重放到从库，来保证主从数据的一致。在从库中查询只能查到已经用WAL的位置上的数据，如果查询要访问的页面们，注意是“们”，那么查询就会出现数据一致性的问题。比如重放两个表的数据，那是在串行重放，你一个JOIN语句，1表和2表的数据很可能不一致，你就会出现读数据的冲突，而我们怎么发现这个冲突。

那就是在从库中有一个机制叫 hot standby conflict resolution，当主库在做vacuum, checkpoint 从库重放这些WAL ，会发现与正在运行的查询有冲突。

举例你主库进行CHECKPOINT ，然后你在CHECKPOINT前做了一个事情DROP TABLE ，从库在接受到这些，他必须进行对应的操作，而此时你的查询就查询了这个DROP TABLE 的 TABLE，你猜从库会怎样，他们必须KILL 你的查询，因为这个表没有了。

出现这样的情况被KILL的种类会比较多，比如snapshot confilct with recovery, canceling statement due to conflict with recovery,等等，数据的一致性优先于你的从库查询。

说到这里，一定有人说，这很容易你就调整 max_standby_streaming_delay，我个人认为，这属于身体有病，不去医院，找杜冷丁。

怎么说呢，纯粹作死！！

你调整了时长，你从库可以在查询到这个地方的时候，WAL在从库不推进了，你查询过去了，你主从延迟可就大发了。你从库replay被停滞了。

其实在PG中很多一些场景，一些大聪明都这么给主意，什么模拟ORACLE 的闪回了，类似的等等，用去吧，谁用谁倒霉。

那么正确的方案是什么？

1 你别那从库当你的OLAP的从库，很多人都是大聪明，那物理复制的从库当OLAP的从库，什么大查询都网上放，以为是MYSQL了。

正确的方案是做逻辑复制，而不是物理复制，你确定好几张表，然后做逻辑复制，通过逻辑复制的方案来查询这些数据，OLAP 也好OLTP也可以，这样就不会出现我们上面说的查询被KILL的问题，因为是逻辑的方式。

PostgreSQL 从库查询被莫名KILL，为什么，群友问题--大聪明给你回答一下

PostgreSQL 从库查询被莫名KILL，为什么，群友问题--大聪明给你回答一下

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐