wal_keep_segments为什么是最小,而不是最大?[英] wal_keep_segments why minimum, not maximum?

本文是小编为大家收集整理的关于wal_keep_segments为什么是最小,而不是最大?的处理方法,想解了wal_keep_segments为什么是最小,而不是最大?的问题怎么解决?wal_keep_segments为什么是最小,而不是最大?问题的解决办法?那么可以参考本文帮助大家快速定位并解决问题。

问题描述

根据docs

<块引用>

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

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

然后如果你创建一个超过 16M*64=1GB 的事务,slave 会被破坏,说它需要删除 WAL 文件.因为文件的最大数量少于所需的数量,对吗?..那么问题来了:为什么要MINIMUM?为什么不最大?

更新:AS 文档在第一句话中指出我正在谈论流复制

<块引用>

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

master,不是slave(没有级联复制)

<块引用>

18.6.1.发送服务器

archive_command 是"无所事事"cd . 和 recovery.conf 中的 restore_command 根本没有设置

推荐答案

直接回答你的问题,为什么是最小值,为什么不是最大值?因为新的 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=+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

本文地址:https://www.itbaoku.cn/post/1763826.html