Postgresql 查询报错ERROR: canceling statement due to conflict with recovery

最新推荐文章于 2025-03-20 16:31:21 发布

魂醉

最新推荐文章于 2025-03-20 16:31:21 发布

阅读量1.3w

点赞数 5

分类专栏： # PostgreSQL

本文链接：https://blog.csdn.net/dazuiba008/article/details/104966409

版权

PostgreSQL 专栏收录该内容

206 篇文章

订阅专栏

Caused by: ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed.

场景描述

这里我们是流复制环境，仓库从现网的备节点抽取数据导致以上报错。
原理很简单，就是主节点的相关表做了DDL或者DML，wal在备节点回放的时候，备节点的查询还在进行，如此就会发生冲突，干掉备节点查询的语句，报出以上错误。

下图简单演示了报错原理，这里是由DML中的UPDATE引起的冲突，行版本不一致造成相关的错误。
在这里插入图片描述

上图可见一个参数max_standby_streaming_delay默认为30秒，也就是说vacuum的时候，相关需要清理的数据仍有事物在使用，则认为有冲突，等待这个参数设置的值，也就是30秒，30秒后则中断连接，报出以上错误。所以这里可能是DDL，比如drop table,truncate table,drop database,drop tablespace等等,也可能是DML，delete,update等等语句都会引起错误发生。

所以这里分为两类处理方式：处理DDL和处理DML

要避免DDL发生，那么需要设置参数max_standby_streaming_delay为-1，这样就会一直等待查询的语句结束为止。如果是从归档中回放产生的冲突，那就max_standby_archive_delay设置为-1。
要避免DML,也就是VACUUM产生的冲突，当然以上的方法也是可用的，这里引入另外一个参数hot_standby_feedback，可以打开该参数(设置为on)避免。

hot_standby_feedback 的原理很简单，就是将备节点的最小活跃事务 ID 定期告知主节点，使得主节点在执行 VACUUM 时对这些事务还需要的数据手下留情。

设置 hot_standby_feedback 的好处是可以减少备节点执行查询时复制冲突的可能，但也有其弊端，即会使主节点先关表的数据延迟回收，从而导致数据膨胀；极端情况下，如果备节点有一个很长的事务，且涉及表上 DML 操作又很频繁，则表的膨胀则会很严重。

另外也可以考虑设置vacuum_defer_cleanup_age参数，这个参数可以延迟清理dead row，使得在备节点的查询可以读取这些dead row,默认为0，这个参数是在主节点上设置，也是由主节点度量的，所以这个值很难确定设置多少为有效，如果主节点事物数增长很快，那么很快dead row就会被清理，对于备节点的查询冲突没什么效果，所以以上引发的错误，我个人不建议设置该参数解决。