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

概述根据 docs wal_keep_segments (integer) Specifies the minimum number of past log file segments kept in the pg_xlog directory 同时根据我的经验 – 你创建一个slave并从默认值更改wal_keep_segments让它为64,并观察随着xlogs的数量开始增长直到达到64个文件.我 根据 docs

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

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

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

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

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

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

18.6.1. Sending Server(s)

archive_command是“do-nothing”cd.并且根本没有设置recovery.conf中的restore_command

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

另外,计算docs中可能的WAL段数的公式是错误的.我总是比checkpoint_segments更多的WALs 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

总结

以上是内存溢出为你收集整理的postgresql – wal_keep_segments为什么最小,不是最大？全部内容，希望文章能够帮你解决postgresql – wal_keep_segments为什么最小,不是最大？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。