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

wal_keep_segments why minimum, not maximum?

提问by Vao Tsun

According to docs

根据文档

wal_keep_segments (integer) Specifies the minimum number of past log file segments kept in the pg_xlog directory

wal_keep_segments (integer) 指定保存在 pg_xlog 目录中的过去日志文件段的最小数量

Meanwhile in my experience - you create a slave and change wal_keep_segments from default to let it be 64, and observe as the number of xlogs starts to grow untill reaches 64 files. Which I assume as maximum, not minimum.

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

Then if you create a transaction that exceeds 16M*64=1GB slave is broken saying it needs removed WAL file. Because the MAXIMUM number of files is less then it is needed, right?.. So the question: why MINIMUM? Why not MAXIMUM?

然后如果你创建一个超过 16M*64=1GB 的事务，slave 就会被破坏，说它需要删除 WAL 文件。因为文件的 MAXIMUM 数量少于需要的数量，对吧？.. 所以问题是：为什么是MINIMUM？为什么不是MAXIMUM？

Update: AS documentation states in first sentence I'm talking about streaming replication

更新：AS 文档在第一句话中说明我正在谈论流式复制

These settings control the behavior of the built-in streaming replication feature

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

master, not slave (no cascaded replication)

主，不是从（没有级联复制）

18.6.1. Sending Server(s)

18.6.1. 发送服务器

archive_commandis "do-nothing" cd .and restore_commandin recovery.confis not set up at all

archive_command是“什么也不做” cd .，并restore_command在recovery.conf没有设置在所有

回答by bbuckley123

To answer your question directly, why minimum and why not maximum? Because the new WAL segments can grow faster than the RemoveOldXlogFiles(_logSegNo, recptr)function can delete the old ones.

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

Also, the formula for calculating the probable number of WAL segments in the docs is wrong. I always have a few more WALs than checkpoint_segments + wal_keep_segments + 1A much more accurate formula is this: wal_keep_segments + 2 * checkpoint_segments + 1

此外，用于计算文档中 WAL 段的可能数量的公式是错误的。我总是比checkpoint_segments + wal_keep_segments + 1一个更准确的公式多一些 WAL是这样的：wal_keep_segments + 2 * checkpoint_segments + 1

There's an old-ish, but really good post on this here: http://www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=[e-mail]

这里有一个陈旧但非常好的帖子：http: //www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=[e-mail]

If you do massive inserts, your WAL segments will grow faster than they can be removed. This got me just this week. I expected the pg_xlog to maintain a relatively constant size. There was a large process run at night and when I got to work the following morning, my postgres instance crashed because the volume I mounted to plop those WALs on was completely full. Postgres filled the volume, tried to write even more WALs, could not, and abruptly died. Luckily we run replicas behind pgpool2.

如果您进行大量插入，您的 WAL 段的增长速度将超过它们可以删除的速度。这让我这周。我希望 pg_xlog 保持相对恒定的大小。晚上有一个大型进程在运行，当我第二天早上上班时，我的 postgres 实例崩溃了，因为我安装的用于放置这些 WAL 的卷已经完全满了。Postgres 写满了卷，试图写更多的 WAL，但写不出来，突然死了。幸运的是我们在 pgpool2 后面运行副本。

If you have a curious mind, I encourage you to browse the postgres source code. It's giant and in C, but the code comments really help. This file in particular is enlightening as it gets into the nuts and bolts of how checkpointing works and how removing old WAL segments happens: https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c

如果您有好奇心，我鼓励您浏览 postgres 源代码。它是巨大的，并且是用 C 语言编写的，但是代码注释确实很有帮助。这个文件特别有启发性，因为它深入了解检查点的工作原理以及删除旧的 WAL 段是如何发生的：https: //github.com/postgres/postgres/blob/master/src/backend/access/transam/日志文件

回答by Daniel Vérité

the number of xlogs starts to grow untill reaches 64 files. Which I assume as maximum, not minimum.

xlog 的数量开始增长，直到达到 64 个文件。我认为这是最大值，而不是最小值。

No, it's not a maximum. The formula for the maximum is given in the documentation at http://www.postgresql.org/docs/current/static/wal-configuration.html

不，这不是最大值。最大值的公式在http://www.postgresql.org/docs/current/static/wal-configuration.html的文档中给出

There will always be at least one WAL segment file, and will normally not be more than (2 + checkpoint_completion_target) * checkpoint_segments + 1 or checkpoint_segments + wal_keep_segments + 1 files. Each segment file is normally 16 MB (though this size can be altered when building the server). You can use this to estimate space requirements for WAL.

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

The problem you mentioned about a slave requiring deleted WAL files should be looked in context, that is, how is log shipping configured or is it not configured at all, and if you're using Hot Standby or Streaming Replication.

您提到的有关需要已删除 WAL 文件的从属设备的问题应该在上下文中查看，即日志传送是如何配置的或根本没有配置，以及您是否使用热备或流式复制。

See https://wiki.postgresql.org/wiki/Binary_Replication_Tutorialfor explanations that might be easier to digest than the main documentation.

请参阅https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial以获得比主要文档更容易理解的解释。

回答by Oberix

It is minumum because WAL files are kept in case you need to recovery, they can be more than wal_keep_segmentsfor a short period, but never be less because the number of WAL files determine how much a standby server can fall behind before being unable to catch up.

这是最小的，因为 WAL 文件被保留以防您需要恢复，它们可以在wal_keep_segments短时间内多，但绝不会少，因为 WAL 文件的数量决定了备用服务器在无法赶上之前可以落后多少.