wal_keep_segments为什么是最小值而不是最大值？

Question

根据文档：

wal_keep_segments（整数）指定在pg_xlog目录中保留的过去日志文件段的最小数量。

同时根据我的经验，您可以创建从库并将wal_keep_segments从默认值更改为64，观察xlog数量增加直到达到64个文件，我认为这是最大值，而不是最小值。

然后，如果您创建的事务超过16M * 64 = 1GB，则从库会报错，因为最大文件数小于所需数，对吧？那么问题来了：为什么是最小值？为什么不是最大值？ 更新：正如文档中第一句话所述，我谈论的是流复制。

这些设置控制内置流复制功能的行为

主服务器（没有级联复制），而不是从服务器。

18.6.1 发送服务器

archive_command是“do-nothing” cd .，recovery.conf中也没有设置restore_command。

- Vao Tsun

---

你是指一个 流复制 从库，没有 WAL 归档和已配置的 restore_command 吗？ - Craig Ringer

所以在没有日志传送的情况下，64 对于您来说太低了。另一方面，设置“最大”wal文件数量将毫无意义。Postgres会通过保持在其下方来尊重此最大值，并且当次要服务器落后太远时仍然会错过缺失的文件。 - Daniel Vérité

Answer 1

直接回答你的问题，为什么是最小值而不是最大值？因为新的 WAL 段可以比 RemoveOldXlogFiles(_logSegNo, recptr) 函数删除旧的段更快地增长。

此外，文档中用于计算可能数量的 WAL 段的公式是错误的。我总是有比 checkpoint_segments + wal_keep_segments + 1 更多的 WAL。一个更准确的公式是： wal_keep_segments + 2 * checkpoint_segments + 1 这里有一篇有点老但真的很好的文章：http://www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=[e-mail] 如果你进行大量插入操作，你的 WAL 段会比它们被删除的速度更快地增长。这就是我本周遇到的情况。我期望 pg_xlog 保持相对恒定的大小。晚上运行了一个大进程，第二天早上当我去上班时，我的 postgres 实例崩溃了，因为我挂载到 plop 那些 WAL 的卷已经完全满了。Postgres 填充了该卷，试图写入更多 WAL，无法写入，并突然死机。幸运的是，我们在 pgpool2 后面运行副本。

如果你有好奇心，我鼓励你浏览 postgres 源代码。它很大而且是用 C 写的，但代码注释真的很有帮助。这个文件特别值得一看，因为它涉及到检查点如何工作以及如何移除旧的 WAL 段：https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c

- bbuckley123

---

请注意，checkpoint_segments 选项在9.5版本后不再使用。 - mlt

Answer 2

“xlogs”的数量开始增长，直到达到64个文件。我认为这是最大值，而不是最小值。 不，这不是最大值。最大值的公式在文档http://www.postgresql.org/docs/current/static/wal-configuration.html中给出。

总会有至少一个WAL段文件，并且通常不会超过（2 + checkpoint_completion_target）* checkpoint_segments + 1或checkpoint_segments + wal_keep_segments + 1个文件。每个段文件通常为16 MB（尽管可以在构建服务器时更改此大小）。您可以使用此来估计WAL的空间要求。

您提到的关于从服务器需要删除的WAL文件的问题应该在上下文中查看，即如何配置日志传送或根本未配置以及是否正在使用热备份或流复制。

请参见https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial以获得比主要文档更易于理解的说明。

- Daniel Vérité

Answer 3

这是最小值，因为 WAL 文件保留以备恢复需要，它们可能在短时间内超过 wal_keep_segments，但永远不会少于此值，因为 WAL 文件的数量决定了备用服务器落后多少才无法赶上。

- Oberix

---

就像我之前所说的，我曾经遇到过主服务器擦除 WAL 的情况，因为它比“wal_keep_segments”文件的数量要老，但从未出现相反的情况。 - Vao Tsun

Answer 4

正如生活中的许多其他事物一样，这也是由于历史原因。自从PostgreSQL 13.0版本以来，存在另一个配置参数称为max_slot_wal_keep_size，它可以与永久复制槽一起使用，以允许槽自动定义正确的最小值，并使用max_slot_wal_keep_size设置最大值，以避免主服务器因从服务器无法跟上而耗尽磁盘空间。

基本上，旧的风格（12.x版本或更低版本）是“使用wal_keep_segments来猜测正确的最小/实际大小”或“使用无限的最大大小，并希望您不会耗尽磁盘空间（永久复制槽）”。

- Mikko Rantalainen