Postgres 流复制错误：请求的 WAL 段已被删除答案

【问题标题】：Postgres Streaming Replication Error: requested WAL segment has already been removedPostgres 流复制错误：请求的 WAL 段已被删除
【发布时间】：2018-05-18 15:13:12
【问题描述】：

我已在主服务器和辅助服务器之间设置流式复制。我已启用存档。在 Postgres 日志文件中，我看到以下错误。

< 2017-12-05 03:08:45.374 UTC > WARNING:  archive_mode enabled, yet archive_command is not set
< 2017-12-05 03:08:46.668 UTC > ERROR:  requested WAL segment 0000000100000000000000E3 has already been removed
< 2017-12-05 03:08:51.675 UTC > ERROR:  requested WAL segment 0000000100000000000000E3 has already been removed
< 2017-12-05 03:08:56.682 UTC > ERROR:  requested WAL segment 0000000100000000000000E3 has already been removed

我们是否需要为流复制启用archive_mode = on？如何避免上述错误？

max_wal_senders = 3
wal_keep_segements = 32

【问题讨论】：

我会先在 master 上增加 wal_keep_segements
我已经将 wal_keep_segments 设置为 32
我会增加到至少 1GB（~60 wals）。在你看到上面的错误之后，你可以重建奴隶。或者启用archive_command而不是增加wal_keep_segments，但同样 - 在你的情况下，你无论如何都必须重建奴隶
每次发生这种情况都重建slave是否理想？如果即使增加到 60 后仍会出现此问题怎么办？
请重新阅读我的答案中有关如何计划和设置流复制的链接。如果你设置到 60 却失败了，那么 60 太低了。例如，最多设置 2000 个，或控制 master 上的事务，或使用下面链接中描述的任何其他方法

标签： postgresql master-slave

【解决方案1】：

https://www.postgresql.org/docs/current/static/warm-standby.html

如果您使用流式复制而不使用基于文件的连续归档，服务器可能会在待机已经收到了。如果发生这种情况，备用机将需要从新的基本备份重新初始化。您可以通过设置来避免这种情况 wal_keep_segments 到一个足够大的值以确保 WAL 段不会过早回收，或者通过为备用。如果你设置了一个可以从备用，这些解决方案不是必需的，因为备用可以始终使用存档来赶上，前提是它保留了足够的段。

强调我的。

所以要么将wal_keep_segments 增加到足够大（足以满足您的块更改量），或者配置archive_command 并设置一些存储以保持从主服务器删除的wals 可用于从服务器。或者为备用配置一个复制槽...

【讨论】：

您可能希望添加复制槽作为一种解决方案，并且比 wal_keep_segments 更可靠。
我正在使用基于文件的归档。用recovery.conf 文件有restore_command。但是一段时间后，存档目录中的 WAL 日志堆积起来导致空间不足的问题。推荐基于文件的归档还是复制槽？如果我做复制槽，我不必担心 WAL 日志的归档？我也可以使用 recovery.conf 文件中的 archive_cleanup_command 来清理旧的 WAL 日志吗？
@LaurenzAlbe 如果我使用复制槽，我可以避免空间问题，但是这种方法对性能有影响吗？复制槽（日志传送）使用异步复制。失败时数据丢失怎么办？
使用 WAL 存档是一个很好的解决方案。您必须确保档案被删除 - 为此使用pg_archivecleanup。复制槽没有性能损失。您使用复制槽或 WAL 存档 - 两者都使用是不必要的。
@LaurenzAlbe 持续归档会对重负载产生 I/O 影响。当您要写入大量数据时，复制槽会更好。