pg_walには十分な容量のファイルがある。それなのに、停止していたスタンバイが必要なWALを取得できない。ファイルの量だけを見ると、不思議に感じる場面ですね。

Christophe Pettus氏のmin_wal_sizeの解説は、この食い違いを考えるきっかけになります。「何GB残すか」という設定に見えても、次の書き込みに使う容量と、過去の変更を読み返せる履歴は別物です。

この違いを押さえると、バッチ開始時の性能を調整したい場合と、スタンバイの停止に備えたい場合で、選ぶ設定が変わる理由が分かります。具体的な設定と監視項目はPostgreSQL 18の公式ドキュメントを基準に整理します。

WALファイルの再利用で変わるのは履歴の読み出し先

WALはデータベースの変更を記録するログです。チェックポイントが進み、回復などに不要になった古いWALセグメントは、削除されるか、将来のセグメント名へ変更されて再利用されます。後者ではファイルの領域を使い回せますが、以前のセグメントとしてスタンバイへ提供することはできません。WALの管理仕様に、この削除と再利用の区別が示されています。

min_wal_sizeが下限を設けるのは、この再利用側です。再利用量は過去のチェックポイント周期のWAL使用量からも見積もられるため、設定値がそのままディレクトリの実使用量になるわけではありません。

ここで、ファイルが存在することと、必要な履歴を取得できることを分けて考えたいところです。ディレクトリの合計サイズだけをレプリケーションの安全余裕と読み替えることはできません。

この役割分担は新しい仕様変更ではありません。min_wal_sizeとmax_wal_sizeは、PostgreSQL 9.5でcheckpoint_segmentsに代わって導入されました。9.5のリリースノートからも、WALファイルの割り当てと不要になった後の扱いを調整するための設定だと分かります。

min_wal_sizeは次のバッチでファイルを作る負担を抑える

再利用用のファイルを残す利点は、書き込みが増えたときに新しいファイルを作る処理を減らせることです。公式ドキュメントも、大きなバッチなどのWAL使用量の急増を用途に挙げています。一方、max_wal_sizeは自動チェックポイントに関係するソフトリミットであり、ディスク使用量の厳密な上限ではありません。WAL設定の説明

ただし、下限を引き上げるだけで、その容量までファイルが即座に作られるわけではありません。Pettus氏は、書き込み済みのWALを再利用してプールが育つことと、静かな時間帯を挟んだ負荷試験で高い再利用下限が末尾側の応答時間に効いたことを報告しています。これは著者の測定結果であり、すべての環境で同じ改善を保証するものではありません。検証と考察

調整するなら、通常時の平均だけでなく、バッチ再開時の遅い応答とWALファイル作成の重なりを見るのが筋です。PostgreSQL 18では、pg_stat_ioのobjectがwal、contextがinitの行で作成時のI/Oを追えます。WALのI/O時間を測るにはtrack_wal_io_timingが必要です。pg_stat_ioの列と計測条件

再利用する容量を増やす判断には、ディスク容量との兼ね合いもあります。また、wal_recycleを無効にしている環境では、再利用を増やす前提が成立しません。Copy-on-Writeファイルシステムでは新規作成が速い場合もあるため、ファイルシステムを含めて効果を見たいですね。wal_recycleの設定

スタンバイの停止に備えるなら保持量と取得経路を決める

スタンバイが後から読むWALを残す目的には、wal_keep_sizeがあります。これはストリーミングレプリケーションのために残す過去のWAL量の下限です。遅れがその量を超えると、必要なセグメントが削除される可能性があります。wal_keep_sizeの仕様

容量から時間を考えるときは、WAL生成速度も必要です。たとえば生成速度を一定の10 MiB/秒と仮定すると、10分で生成されるWALは6,000 MiB、約5.9 GiBです。これは計算例であって推奨設定値ではありません。実際の保持量を決めるには、停止中のピークと復帰後の追従も考慮する必要があります。

スタンバイに対応するレプリケーションスロットを使えば、消費側に必要なWALを保持できます。ただし、消費が止まったスロットはpg_walのディスクを埋める原因にもなります。アーカイブからの取得経路を設ける方法もあり、必要なセグメントを取得できれば、送信側に残っていない履歴を補えます。スロットとスタンバイのWAL取得

max_slot_wal_keep_sizeでスロットの保持量に上限を付けると、容量増加を制限できますが、必要なWALが削除されてレプリケーションを継続できなくなる場合があります。既定値の-1では、この設定による保持量の制限はありません。スロットの保持上限

設定値とスロットの状態を別々に読む

運用中の環境では、まずWALを送る側の設定を読み取るところから始められます。SHOWは現在の設定値を表示するコマンドです。次のSQLは設定を変更しません。SHOWの仕様

-- 再利用、チェックポイント、履歴保持の設定を読み取る。
SHOW min_wal_size;
SHOW max_wal_size;
SHOW wal_recycle;
SHOW wal_keep_size;
SHOW max_slot_wal_keep_size;

スロットを使っている場合は、同じ送信側で状態も見ます。次の例はPostgreSQL 18のpg_replication_slotsを対象とする読み取り専用のSQLです。既存スロットがなければ0行となり、スロット以外の保持設定を別途見る必要があります。

-- 既存スロットの利用状態と、WAL保持の余裕を読み取る。
SELECT slot_name, slot_type, active, restart_lsn,
       wal_status, safe_wal_size
FROM pg_replication_slots;

safe_wal_sizeは、そのスロットがlostになる危険を避けて追加生成できるWAL量をバイトで表します。NULLは「余裕がない」という意味に固定できず、すでにlostの場合も、max_slot_wal_keep_size = -1の場合もあります。wal_statusと設定値を併せて読む必要があります。pg_replication_slotsの列定義

冒頭の疑問に戻ると、pg_walの大きさだけでは、スタンバイが必要な地点から読み直せるかは判断できません。性能のためにはファイル作成時のI/Oを、復帰のためには保持設定と取得経路を評価する。この二つの判断を分ければ、min_wal_sizeを増やすべき場面も、別の仕組みを整えるべき場面も見えてきます。

出典

• Title: Christophe Pettus: All Your GUCs in a Row: min_wal_size
• URL: https://postgr.es/p/9wX