PostgreSQL 9.6 理解 wal 文件答案

【问题标题】：PostgreSQL 9.6 understanding wal filesPostgreSQL 9.6 理解 wal 文件
【发布时间】：2019-12-20 14:32:46
【问题描述】：

我正在尝试了解 wal 文件的行为。数据库的wal相关设置如下：

"min_wal_size"  "2GB"   
"max_wal_size"  "20GB"
"wal_segment_size"  "16MB"
"wal_keep_segments" "0"
"checkpoint_completion_target"  "0.8"
"checkpoint_timeout"    "15min"

wal文件数始终为1281或更高：

SELECT COUNT(*) FROM pg_ls_dir('pg_xlog') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';
-- count 1281

据我了解，这意味着 wal 文件目前永远不会低于 max_wal_size (1281 * 16 MB = 20496 MB = max_wal_size) ??

我希望 wal 文件的数量在达到检查点并且数据同步到磁盘后立即减少到最大值以下。但显然情况并非如此。我错过了什么？

【问题讨论】：

标签： postgresql postgresql-9.6 wal

【解决方案1】：

作为per the documentation（强调添加）：

pg_xlog 目录中 WAL 段文件的数量取决于min_wal_size、max_wal_size 以及在之前的检查点周期中生成的 WAL 数量。 当不再需要旧的日志段文件时，会将它们删除或回收（即，重命名为按编号顺序成为未来的段）。如果由于日志输出速率的短期峰值，超过了max_wal_size，则将删除不需要的段文件，直到系统回到此限制之下。低于该限制，系统会回收足够的 WAL 文件来满足下一个检查点之前的估计需求，并删除其余文件

因此，根据您的观察，您可能正在观察“回收”效应——旧的 WAL 文件被重命名而不是被删除。这为磁盘节省了一些 I/O，尤其是在繁忙的系统上。

请记住，一旦特定文件被回收，在使用之前不会重新考虑删除/回收（即，达到相关 LSN 并checkpointed）。如果您的系统突然变得不那么活跃，这可能需要很长时间。

【讨论】：

感谢您的解释。这对我的系统意味着什么？我应该增加 max_wal_size 还是减少 checkpoint_timeout？还是这完全正常，我不应该做任何事情？
你的 pg_xlog 分区有多大？就个人而言，如果您不希望定期出现更多此类活动高峰，我会不理会它。 Postgres 不会根据配置阻止 WAL 活动——它可能会给你警告，但你不应该看到任何服务中断。增加 max_wal_size 可能对您不利——如文档中所述：它可能会增加崩溃恢复的时间。
如果这些峰值经常发生怎么办？我在调查查询性能的定期下降时看到了这种行为，这可能与磁盘 i/o 问题或瓶颈有关。
我认为这个问题的答案不一定简单，因为还需要一些额外的数据点——您是否有任何可以从日志中提供的信息（例如，表明检查点正在发生的消息太频繁了）？您是否有任何图表表明性能下降与检查点活动一致？您甚至可能会因为 shared_buffers 设置得太高而遭受痛苦，从而导致大量缓存刷新到磁盘。尝试诊断所有可能超出此 SO 问题范围的所有内容（尽管我愿意在这里展开聊天并进一步讨论）

【解决方案2】：

如果您的服务器非常繁忙，然后突然变得大部分空闲，您可能会遇到日志失败的情况，即长时间保持在 max_wal_size。在它决定是删除还是回收文件时，它很快就用完了它们，因此决定回收到 max_wal_size 以供预测的未来使用，而不是删除它们。一旦被回收，它们在被使用之前永远不会被删除（你可以说这是一个错误），如果服务器现在大部分时间处于空闲状态，那么它们将需要很长时间才能被使用并因此被删除。

【讨论】：