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

查看:219
本文介绍了wal_keep_segments为什么最小值而不是最大值?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据文档


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

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

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

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.

然后,如果您创建一个超过16M * 64 = 1GB的事务,则奴隶被破坏,表示需要删除WAL文件。因为文件的最大数量少于需要的数量,对吧?..
那么问题是:为什么 MINIMUM ?为什么不 MAXIMUM

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?

更新:AS文档的第一句话是我在谈论流复制

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


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

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

是主服务器,不是从属服务器(没有级联复制)

master, not slave (no cascaded replication)


18.6.1。发送服务器

18.6.1. Sending Server(s)

archive_command 是不执行任何操作 <$未在 recovery.conf 中设置c $ c> cd。和 restore_command 全部

archive_command is "do-nothing" cd . and restore_command in recovery.conf is not set up at all

推荐答案

直接回答您的问题,为什么最小值而不是最大值?因为新的WAL段的增长速度快于 RemoveOldXlogFiles(_logSegNo,recptr)函数可以删除旧的WAL段。

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段可能数量的公式也是错误的。我总是比 checkpoint_segments + wal_keep_segments + 1 多一些WAL,更准确的公式是: wal_keep_segments + 2 * checkpoint_segments + 1

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 + 1 A much more accurate formula is this: wal_keep_segments + 2 * checkpoint_segments + 1

这里有一个古老但很不错的帖子: http://www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=+kxhiepJsHu7EO06- com

There's an old-ish, but really good post on this here: http://www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=+kxhiepJsHu7EO0J6-LEVO-ek5oPkg@mail.gmail.com

如果您进行大量插入操作,则WAL段的增长速度将超过其删除范围。这让我刚好在这个星期。我期望pg_xlog保持相对恒定的大小。晚上有一个很大的过程,第二天早晨我上班时,我的postgres实例崩溃了,因为我装入这些WAL的卷已完全装满。 Postgres填满了该卷,试图写更多的WAL,但没有,突然死了。幸运的是,我们在pgpool2后面运行了副本。

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.

如果您有好奇心,建议您浏览postgres源代码。它很大,用C语言编写,但是代码注释确实有帮助。当深入了解检查点的工作原理以及如何删除旧的WAL段时,此文件特别具有启发性: https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c

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

这篇关于wal_keep_segments为什么最小值而不是最大值?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆