一旦具有值-1的`max_standby_archive_delay`和`max_standby_streaming_delay`是否会导致复制在重载时停止？

Question

在aws RDS上postgresql主从复制方案上的复制服务器中，我得到以下错误：

SQLSTATE[40001]: Serialization failure: 7 ERROR:  canceling statement due to conflict with recovery

据我所知，原因是复制的发生就像数据库迁移一样简单。一个查询序列是写一些叫做WAL的东西，然后用FIFO序列执行。

另外，我了解到，一旦在执行wal时执行查询，就会导致冲突，因为有时当前正在执行的查询可能会导致获取陈旧的数据。

因此，根据文档，有一些延迟允许首先执行当前的查询，然后应用wal更改。它们是：

1. max_standby_archive_delay
2. max_standby_streaming_delay

但是在大量查询(查询执行时间>30)上将这些值设置为-1会导致副本有较长时间的陈旧数据？

Answer 1

是的，就是这个主意。在复制冲突的情况下，PostgreSQL只有两个选项：

1. 取消查询
2. 延迟复制更改的应用。

将max_standby_streaming_delay设置为-1将无限期地延迟复制。

有一些方法可以减少复制冲突：

• 设置hot_standby_feedback = on以删除由VACUUM引起的复制冲突。您要付出的代价是，在待机状态下长时间运行的查询会使您的表膨胀。
• 在您的工作负载中没有任何像DROP TABLE、TRUNCATE、ALTER TABLE等导致ACCESS EXCLUSIVE锁的语句。
• 在PostgreSQL v12中，您可以设置atable (vacuum_truncate = off)；以禁用自动真空截断(这也会导致ACCESS EXCLUSIVE短锁)。在较早的版本中，只有将old_snapshot_threshold设置为默认值以外的其他内容的粗略和无文档说明的解决方法。

这一切都很复杂，而且可能会产生意想不到的效果，因此最好的建议是:如果您想要的待机时间不超过必要，但也希望在备用服务器上运行长时间运行的查询，则应该使用两台备用服务器，一台用于这些冲突的目的。