在PostgreSQL的流复制架构中，备库通常承担读写分离里的读请求，同时也负责回放主库传来的WAL日志。这两件事本质上是相互干扰的：回放需要修改数据页，而查询需要一个稳定的数据视图。当两者撞在一起，PostgreSQL会做出取舍，多数情况下是牺牲查询、保住回放进度，于是业务侧就会看到canceling statement due to conflict with recovery这样的报错。这篇文章就来把这个冲突的来龙去脉讲清楚，并给出几套实际可用的解决方案。
恢复冲突到底是怎么发生的
备库在回放WAL时，如果发现某个操作会影响到正在执行的查询，就会触发冲突检测。最典型的一类是快照丢弃冲突：查询开始时持有的是一个MVCC快照，回放过程中主库删除或更新了查询要访问的元组，备库为了保持与主库一致，必须清理这些旧版本数据，但查询的快照可能还需要它们，此时查询会被取消。除此之外还有锁冲突，比如主库上执行了ALTER TABLE加锁，回放到备库时与正在访问该表的查询互斥；缓冲区失效冲突，主库truncate或vacuum了某张表导致备库共享缓冲区中的页必须失效；以及表空间删除、数据库删除这类更为激烈的冲突。可以在日志中观察recovery conflict相关的详细输出，日志通常会标明冲突类型，比如recovery conflict on snapshot或者recovery conflict on lock，这是定位问题的第一手信息。
需要理解的一点是，PostgreSQL的设计哲学是优先保证备库最终与主库一致。参数max_standby_streaming_delay控制的是备库在流复制持续接收WAL的情况下，最多愿意等待多久。超过这个时间窗口，还没回放的WAL会继续回放，冲突的查询直接被取消。这个值默认是30秒，也就是说一个长查询如果与回放冲突且等待超过30秒，基本必挂。
另外要注意，冲突被取消的是备库上的查询，主库完全不受影响。所以有些业务把关键报表放在备库跑，一旦频繁被取消，就要认真评估下面的几种方案了。
参数调优：max_standby_streaming_delay与hot_standby_feedback
第一个思路是给回放设置更大的容忍窗口。把max_standby_streaming_delay调大，比如从默认的30秒改为300秒甚至更长，备库在遇到冲突时会先暂停回放，给查询留出执行时间。代价是备库与主库的延迟会拉大，如果查询持续不断，备库可能一直处于滞后状态。这个方案适合备库上偶发长查询、且业务对主从延迟不敏感的场景。如果希望干脆不等待，也可以设为-1，表示无限等待，但这在生产环境风险很高，一旦查询长时间不结束，备库延迟会无限累积。
第二个思路是启用hot_standby_feedback，在备库的postgresql.conf中设置：
# 备库配置 hot_standby_feedback = on max_standby_streaming_delay = 300s
开启后，备库会定期把最老的活跃事务ID反馈给主库的walsender进程，主库据此推迟清理旧版本元组，从源头上避免快照丢弃冲突。代价则转嫁到了主库：主库的死元组清理被推迟，表和索引可能出现膨胀，写频繁的数据库尤其明显。所以这个参数适合备库查询以读旧数据为主、主库写压力可控的场景，且要求主备版本兼容。
两者的本质区别在于：前者是备库侧"拖时间"，后者是主库侧"保数据"。实际使用中也可以组合，先开feedback消除快照类冲突，再用一个合理的delay兜底处理锁类和DDL类冲突。此外还有一个更粗粒度的参数max_standby_archive_delay，它针对的是从归档恢复WAL的场景，流复制正常时一般不用动它。
从业务与架构层面根治冲突
参数调优只能缓解，有些冲突类型调参数是无效的。比如锁冲突：主库执行TRUNCATE TABLE或ALTER TABLE，备库回放时要获取排他锁，无论delay设多大，只要备库上有查询占着这个表，最终要么查询被取消，要么回放被无限推迟。这类问题要从业务侧解决：把DDL安排在业务低峰期执行，执行前确认备库上没有长事务；对报表类长查询设置statement_timeout，避免它们无限期占用快照；定期检查pg_stat_activity中备库上的长查询：
-- 查看备库上运行时间超过5分钟的查询 SELECT pid, now() - query_start AS duration, state, query FROM pg_stat_activity WHERE state = 'active' AND now() - query_start > interval '5 min' ORDER BY duration DESC; -- 必要时手动终止冲突查询 SELECT pg_terminate_backend(pid);
架构层面也有几个方向可以考虑。一是拆分读流量：把对一致性要求高、查询时间长的请求留在主库，备库只承接短平快的查询，冲突概率自然下降。二是增加专门的延迟备库或用快照方式跑报表，让承担回放职责的备库保持轻载。三是升级到较新版本的PostgreSQL，新版本在冲突处理和清理机制上有持续改进，比如对feedback机制的优化和更细粒度的冲突日志。
最后给一套排查顺序供参考：先看备库日志确认冲突类型，再检查pg_stat_replication和pg_last_wal_replay_lsn()评估主从延迟状况，然后根据冲突类型决定是调参数、改业务还是调架构。恢复冲突不是一个开关能解决的问题，理解"读与回放争资源"这个本质，才能在延迟、膨胀和可用性之间做出符合业务的取舍。
PostgreSQL备库恢复冲突流复制hot_standby修改时间：2026-09-04 04:38:35