问题描述
我在 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 尝试恢复时它失败并回退到复制
这似乎不是正确的做法,是吗?
谢谢,
-- 马辛
解决方法
据我所知,这不是问题。
如果您希望复制延迟 30 分钟,并且每半小时存档一个 16MB 以上的 WAL 段,则无需复制。信息也可以从档案中读取。如果最新存档的 WAL 段中的最新条目恰好早于 recovery_min_apply_delay
,则备用数据库将联系主数据库并进行复制。
如果您坚持复制而不是存档恢复,请从配置中删除 restore_command
和 max_slot_wal_keep_size
。但我不明白这一点。
如果您担心在主服务器发生灾难时丢失活动的 WAL 段,请使用 pg_receivewal
而不是 archive_command
来填充 WAL 存档。