Postgresql 不会重新建立延迟复制答案

【问题标题】：Postgresql doesn't reestablish delayed replicationPostgresql 不会重新建立延迟复制
【发布时间】：2021-09-22 10:21:14
【问题描述】：

我在 PG 13.3 上运行 master & replica。我决定使用延迟复制（recovery_min_apply_delay 参数中配置的 30 分钟）。最重要的是，WAL 归档已配置好并且运行良好。

当 master 上的负载长时间很高时，复制会落后，直到超过 max_slot_wal_keep_size（请参阅我的另一个相关问题：Replication lag - exceeding max_slot_wal_keep_size, WAL segments not removed）。一旦落后太远，插槽就会“丢失”，并且副本会回退到从存档中恢复 WAL。到目前为止一切都很好。问题是，它再也不会尝试复制。重新启动从站没有帮助。我有两种方法可以恢复复制：

重启和配置编辑

从副本中删除延迟配置
重新启动 postgres。然后它从存档中恢复所有 WAL，一旦没有任何东西，它将再次开始复制 - 但没有任何延迟。然后我再次编辑配置以引入复制，它有时有效，有时无效。我认为这取决于负载。

从存档中删除 WAL 段

从 postgresql 日志中查看当前恢复的 WAL 段，并暂时从 WAL 存档中移动以下一段。当 PG 尝试恢复时，它会失败并回退到复制

这似乎不是正确的做法，不是吗？

谢谢，

-- 马辛

【问题讨论】：

标签： postgresql replication postgresql-13

【解决方案1】：

据我所知，这不是问题。

如果您希望将复制延迟 30 分钟，并且每半小时存档多个 16MB WAL 段，则无需复制。信息也可以从档案中读取。如果最新存档的 WAL 段中的最新条目恰好早于recovery_min_apply_delay，则备用数据库将联系主数据库并进行复制。

如果您坚持复制而不是存档恢复，请从配置中删除 restore_command 和 max_slot_wal_keep_size。但我不明白这一点。

如果您担心在主节点发生灾难时丢失活动 WAL 段，请使用 pg_receivewal 而不是 archive_command 来填充 WAL 存档。

【讨论】：

据我所知，我的情况的主要区别是：restore_command 仅在需要应用日志时调用，而复制将在 WAL 发生时流式传输，但稍后应用。因此 restore_command 可能会导致更大的数据丢失（最多 16MB，尽管在我的情况下它是 256MB）。我使用 max_slot_wal_keep_size 是因为在任何情况下我都不希望插槽杀死主人。
使用pg_receivewal，如我的扩展答案中所示。
是的，我可以这样做，尽管这是另一个需要担心的过程。令人惊讶的是，PG 不会尝试重新建立复制，作为保持副本运行的首选选项。由于已经描述的原因，在我的情况下，从存档恢复更糟糕，并且给存档存储 (NFS) 带来了更大的压力。我希望它仅在复制失败时使用，但不再是必需的。