wal_keep_segments为什么最小,不是最大？

Question

根据文件

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

同时根据我的经验 - 你创建一个slave并从默认值更改wal_keep_segments让它为64,并观察随着xlogs的数量开始增长直到达到64个文件.我认为这是最大值,而不是最小值.

然后,如果你创建一个超过16M的事务*64 = 1GB奴隶被打破说它需要删除WAL文件.因为MAXIMUM文件的数量少于需要它,对吧？所以问题:为什么MINIMUM？为什么不MAXIMUM？

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

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

主人,不是奴隶(没有级联复制)

18.6.1.发送服务器

archive_command是"什么也不做" cd .,并restore_command在recovery.conf没有设置在所有

Answer 1

要直接回答您的问题,为什么最低限度,为什么不最大？因为新的WAL段可以比RemoveOldXlogFiles(_logSegNo, recptr)函数更快地增长,所以可以删除旧的段.

另外,计算docs中可能的WAL段数的公式是错误的.我总是有几个WAL比checkpoint_segments + wal_keep_segments + 1一个更准确的公式是这样的:wal_keep_segments + 2 * checkpoint_segments + 1

这里有一个古老但非常好的帖子:http://www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=+kxhiepJsHu7EO0J6-LEVO-ek5oPkg@mail.gmail.com

如果你进行大量插入,你的WAL段将比它们被移除的速度更快.这让我这个星期.我希望pg_xlog保持相对恒定的大小.有一个大的过程在晚上运行,当我第二天早上上班时,我的postgres实例崩溃了,因为我安装到那些WAL上的音量已经完全充满了.Postgres填满了音量,试图写更多的WAL,不能,并且突然死亡.幸运的是,我们在pgpool2后面运行复制品.

如果您有好奇心,我建议您浏览postgres源代码.它是巨型的,在C中,但代码注释确实有帮助.这个文件尤其具有启发性,因为它进入了检查点如何工作以及如何删除旧的WAL段的细节:https://github.com/postgres/postgres/blob/master/src/backend/access/transam/ xlog.c