Postgres 订阅者节点花了一些时间来反映发布者配置更改，这导致 postgres 重新启动问题

Question

我知道这里提到的 postgres 配置警告：

确保这不会成为问题的最简单方法是将备用数据库上的这些参数设置为等于或大于主数据库上的值

例如，当我将参数

max_connections 从 300 减少到 200 时，首先我减少发布者，然后在订阅者中执行相同的操作以避免上述问题。

在这里，我发现，如果我们立即在订阅者中执行此操作（例如在发布者中更新后 2 秒内），就会遇到以下问题：

hot standby is not possible because max_connections = 200 is a lower setting than on the master server (its value was 300) 发布者中的配置更新更改似乎未传输/订阅者仍然不知道发布者中的更新。

所以我引入了一个延迟，例如：replication_lag + 2秒（不确定，是否正确）。现在一切正常了。

所以我的问题是：

• 首先在发布者中更新配置时如何避免此问题/最佳实践步骤？
• 如果引入延迟就可以了，如何正确计算延迟？
• 或者有什么可以检查并确认发布者配置更新已传输给所有订阅者吗？

PS：更新1：

• 集群设置（具有 2 节点集群的测试设置）- 流式复制

• 对于每个配置更新，postgres 都会重新启动。

• 使用新值重新启动订阅者节点时看到的问题日志。还使用

  pg_settings

   表验证了发布者已更新为新值 (200)。

• 这些步骤是使用发布者节点中的自定义脚本完成的，该脚本可以更新两个节点中的配置（还可以在更新时重新启动服务）。

• 确认订阅者节点 max_connections=200 在发布者节点配置更新后立即（2秒内）更新（postgres也重新启动）（postgres重新启动并验证pg_settings中的值）。

Answer 1

max_connections

只能在服务器重新启动时更改。当服务器启动时，在完成崩溃恢复（如果有）之后，它将写入包含当前 

max_connections

 设置的 WAL 记录。一旦备用服务器收到并重播该记录，它就会知道新设置，您可以更改备用服务器上的参数。

所以你可以遵循这样的程序：

• 更改主设备上的参数并重新启动

• 在主

  上获取

  pg_current_wal_lsn()

  的结果

• 轮询

  pg_stat_replication

  ，直到备用数据库的

  replay_lsn

  达到或超过该日志序列号

• 在备用机上更改参数并重新启动