DevOpsナレッジハブ
DevOpsナレッジハブ

高いWALアクティビティのトラブルシューティングとアーカイブログディスク領域の管理

PostgreSQLにおける過剰なWrite-Ahead Log (WAL) 生成のトラブルシューティングと管理方法を学びます。本ガイドでは、バルク操作やレプリケーションの問題など、高いWALアクティビティの一般的な原因を扱い、WALアーカイブの設定、レプリケーションスロットの管理、およびディスク領域の枯渇防止のための実践的な解決策を提供します。安定性と効率的なディスク領域利用に焦点を当てたPostgreSQL管理者にとって必読です。

43 ビュー

高いWALアクティビティのトラブルシューティングとアーカイブログディスクスペースの管理

PostgreSQLにおける高いWrite-Ahead Log (WAL) アクティビティは、深刻な問題となり、急速なディスク容量の消費やデータベースのダウンタイムを引き起こす可能性があります。WALは、PostgreSQLがデータの永続性と回復性を保証するための仕組みです。データベースに加えられたすべての変更は、データファイルに適用される前に、まずWALに書き込まれます。WALは不可欠ですが、過剰なWAL生成は、特にアーカイブまたはクリーンアッププロセスが最適に構成されていない場合、利用可能なディスクスペースをすぐに逼迫させてしまいます。

本記事では、WAL生成量が多くなる一般的な原因を深く掘り下げ、アーカイブログのディスクスペースを効率的に管理するための実践的な戦略を提供します。基盤となるメカニズムを理解し、適切な構成を実装することで、ディスク関連の障害を防ぎ、PostgreSQL環境の健全性を維持することができます。

Write-Ahead Logging (WAL) の理解

トラブルシューティングを行う前に、WALがどのように機能するかを理解することが重要です。PostgreSQLはWALを使用して、トランザクションが不可分性 (Atomic)、一貫性 (Consistent)、独立性 (Isolated)、永続性 (Durable) (ACID) であることを保証します。データベースに変更が加えられると、その変更を記述したレコードがWALバッファに書き込まれ、その後ディスク上のWALファイルにフラッシュされます。これにより、データページが更新される前にサーバーがクラッシュした場合でも、リカバリ中にWALから変更を再適用できるようになります。

WALファイルはセグメント単位で管理され、通常デフォルトで16MBのサイズです。新しいトランザクションが発生すると、新しいWALファイルが作成されます。これらのファイルは急速に蓄積される可能性があり、適切に管理（例：アーカイブおよび削除）されないと、利用可能なディスクスペースをすべて消費してしまいます。

WALの主要な概念:

  • 永続性 (Durability): トランザクションがコミットされると、システム障害が発生しても存続することを保証します。
  • レプリケーション (Replication): WALはストリーミングレプリケーションの基本であり、スタンバイサーバーはWALレコードを受け取り、プライマリと同期を保ちます。
  • ポイントインタイムリカバリ (PITR): WALアーカイブはPITRに不可欠であり、データベースを任意の特定の時点に復元できるようにします。
  • WALセグメント: WALデータは、セグメントと呼ばれる一連のファイルに書き込まれます。

高いWALアクティビティの一般的な原因

いくつかの要因が、通常よりも大量のWAL生成に寄与する可能性があります。根本原因を特定することが、効果的なトラブルシューティングの最初のステップです。

1. 大量のデータロードと変更

INSERT、UPDATE、DELETE、TRUNCATE、COPY のような操作は、大量のWALを生成する可能性があります。特に大規模なテーブルに対する一括操作は、小さな個別のトランザクションよりも自然に多くのWALレコードを生成します。

  • 例: 数百万行を挿入するための単一の COPY FROM コマンドは、ギガバイト単位のWALデータを生成する可能性があります。
  • 例: 大規模なデータ移行またはバッチ更新スクリプトの実行。

2. レプリケーション遅延とスタンバイの問題

スタンバイサーバーがプライマリに追いついていない（レプリケーション遅延）場合、WALファイルはプライマリに蓄積されます。プライマリサーバーは、完了したWALセグメントが、接続されているすべてのスタンバイに送信され処理されたことが確認されるまで（wal_keep_size または max_slot_wal_keep_size が構成されていない場合、またはスロットが正しく使用されていない場合）、削除できません。

  • シナリオ: スタンバイサーバーがダウンしている、切断されている、またはパフォーマンスの問題が発生しているため、プライマリからのWALレコードを消費できない。

3. 過度な fsync 呼び出し（稀だが可能性あり）

WAL自体が主な要因ではありますが、非効率なアプリケーションロジックや特定のPostgreSQL構成により、ディスクへのフラッシュが頻繁に発生し、間接的にWALアクティビティが増加する可能性があります。ただし、これは一括操作やレプリケーションの問題に比べると稀です。

4. 管理されていない pg_wal ディレクトリの肥大化

WALアーカイブが有効になっていないか、失敗している場合、新しいWALセグメントが生成されるにつれて、プライマリサーバー上の pg_wal（以前は pg_xlog）ディレクトリは無制限に増大します。

5. 回収されないレプリケーションスロット

レプリケーションスロットは、特定のスタンバイまたは論理デコーディングクライアントによって消費されるまで、WALセグメントが削除されないことを保証します。スロットが作成されたものの、コンシューマが停止または切断され、スロットが破棄されない場合、そのスロットが必要とするWALセグメントは、スタンバイがアクティブでなくなったとしても保持され続けます。

WALディスクスペースの管理：構成と解決策

高いWALアクティビティに対処するには、監視、構成チューニング、および適切なメンテナンス手順を含む多角的なアプローチが必要です。

1. WALアーカイブの有効化と監視

WALアーカイブは、ディスクスペースを管理し、PITRを可能にするための最も重要なメカニズムです。アーカイブが有効になると、完了したWALファイルは別の場所（例：ネットワークファイル共有、S3バケット、または別のディスク）にコピーされます。

構成:

postgresql.conf ファイルを変更します。

wal_level = replica         # Or logical for logical replication
archive_mode = on           # Enable archiving
archive_command = 'cp %p /path/to/archive/%f'

# Example for S3 using wal-g or similar tool:
# archive_command = 'wal-g wal-push %p'
  • %p: アーカイブされるWALファイルへのフルパスのプレースホルダーです。
  • %f: WALファイルのファイル名のプレースホルダーです。

重要: archive_command は正常に実行できる必要があります。ゼロ以外の終了コードを返した場合、PostgreSQLはアーカイブが失敗したとみなし、WALファイルが削除されない原因となる可能性があります。宛先ディレクトリに十分なスペースがあり、PostgreSQLを実行しているユーザーが書き込み権限を持っていることを確認してください。

アーカイブの監視:

SQLクエリを使用してアーカイブのステータスを確認します。

SELECT archived_count, failed_count FROM pg_stat_archiver;

SELECT pg_current_wal_lsn() AS current_lsn,
       pg_walfile_name_offset(pg_current_wal_lsn()) AS current_wal_file,
       pg_last_wal_replay_lsn() AS replay_lsn; -- On standby

-- Check for WAL files that haven't been archived yet (can indicate issues)
SELECT pg_wal_lsn_segments(pg_current_wal_lsn() - pg_last_archived_wal_lsn()) AS segments_since_last_archive;

2. pg_wal ディレクトリサイズの管理

アーカイブが有効になっていても、アーカイブ後にWALセグメントが削除されない場合、プライマリ上の pg_wal ディレクトリは肥大化する可能性があります。これは次の場合に発生します。

  • スタンバイが追いついておらず、wal_keep_size（またはスロットを使用している場合は max_slot_wal_keep_size）が十分なWALを保持するには小さすぎる場合。
  • レプリケーションスロットがWALファイルを保持している場合。

wal_keep_size (PostgreSQL 13より前)

プライマリサーバー上のこのパラメータは、ストリーミングレプリケーションのために pg_wal ディレクトリに保持する必要があるWALデータ量（MB単位）を指定します。スタンバイが遅れすぎ、追いつくために必要なWALの量が wal_keep_size を超えると、スタンバイは再接続できなくなる可能性があります。

# postgresql.conf on primary
wal_keep_size = 1024 # Keep 1GB of WAL on disk

注記: wal_keep_size は旧来のアプローチです。堅牢なレプリケーションには、通常レプリケーションスロットの使用が推奨されます。

max_slot_wal_keep_size (PostgreSQL 13以降)

これは、レプリケーションスロットを使用する際のWAL保持を管理するための推奨される方法です。これは、すべてのレプリケーションスロットが保持できるWALディスクスペースの合計量（MB単位）を制限します。

# postgresql.conf on primary
max_slot_wal_keep_size = 2048 # Limit slots to retain 2GB of WAL

# Also consider: wal_keep_size -- still relevant for non-slot based streaming
# wal_keep_size = 1024 # Keep 1GB for non-slot streaming

アクティブなスロットが必要とするWALの総量が max_slot_wal_keep_size を超えると、そのスロットによって消費されたとしても新しいWALファイルは削除されず、ディスクが一杯になる原因となります。このパラメータは、問題のあるスロットによるWALの無制限な蓄積を防ぎます。

レプリケーションスロット

レプリケーションスロットは、WALの損失を防ぎ、信頼性の高いレプリケーションを保証するために不可欠です。しかし、正しく管理されていない場合、WALファイルが蓄積する原因となることがあります。

  • 問題: レプリケーションスロットが作成されたものの、コンシューマ（スタンバイまたは論理クライアント）が切断または失敗し、スロットが破棄されない場合、プライマリサーバーはそのスロットが待機しているすべてのWALファイルを保持し続けます。
  • 解決策: 定期的にレプリケーションスロットを監視し、使用されなくなったスロットは破棄します。
-- List replication slots
SELECT slot_name, plugin, slot_type, active, wal_status FROM pg_replication_slots;

-- Drop an unused slot
SELECT pg_drop_replication_slot('slot_name_to_drop');

警告: レプリケーションスロットを破棄すると、接続されているすべてのコンシューマはその位置を失います。破棄する前に、そのコンシューマが不要になったか、適切に再初期化されていることを確認してください。

3. min_wal_size と max_wal_size のチューニング

これらのパラメータは、PostgreSQLが事前に割り当てるWALの最小量と最大量を制御します。これらはWALの生成を直接引き起こすわけではありませんが、事前割り当てにより、アクティビティが高い期間に pg_wal ディレクトリがどれだけ速く増大するかに影響します。

  • min_wal_size: 少なくともこれだけのWALスペースが利用可能であることを保証し、頻繁な事前割り当てを防ぎます。設定を低くしすぎると、pg_wal ディレクトリが頻繁に拡張される可能性があります。
  • max_wal_size: PostgreSQLが維持するWALの最大量。この制限を超える古いセグメントは、アーカイブまたはレプリケーションで不要になると、リサイクルまたは削除されます。
# postgresql.conf
min_wal_size = 1GB
max_wal_size = 4GB

max_wal_size を増やすと、書き込み負荷のピーク時にシステムにより多くの余裕を与えることができますが、その分、事前割り当てされたWALファイルによって占有されるディスクスペースも増加します。

4. アーカイブされたWALファイルの定期的なクリーンアップ

WALアーカイブはリカバリに不可欠ですが、アーカイブされたファイルが全くクリーンアップされない場合、ディスクスペースの問題を引き起こす可能性もあります。アーカイブされたWALファイルの保持を管理するための戦略が必要です。

  • 戦略: スクリプトを実装するか、専用のツール（pg_archivecleanup、pgBackRest、wal-g、barmanなど）を使用して、PITRやレプリケーションに不要になった古いWALファイルをアーカイブ場所から削除します。

  • pg_archivecleanup の使用:
    このユーティリティは、プライマリサーバーで実行して、アーカイブディレクトリから古いWALファイルを削除できます。
    bash # On the primary server, in the PostgreSQL bin directory: pg_archivecleanup /path/to/archive/location <timelineID> <lsn_to_keep_until>
    あるいは、これを archive_command に統合することもできます（ただし、これは一般的ではなく、複雑になる可能性があります）。

    より一般的なアプローチは、pg_archivecleanup を定期的に実行するようにスケジュールし、最後の成功したバックアップ時点までのWALファイルを保持することです。

    ```bash

    Example cron job to run daily, keeping WAL files up to 24 hours old

    Ensure this aligns with your backup strategy!

    0 0 * * * pg_archivecleanup -d -v /path/to/archive/location
    ```

    重要: クリーンアップ戦略が、バックアップおよびリカバリのPoint-In-Time Recovery (PITR) 要件と常に一致していることを確認してください。目的のリカバリウィンドウをカバーできるだけの期間、WALファイルを保持する必要があります。

5. ディスクスペースとWAL生成率の監視

予防的な監視は、ディスクスペースの枯渇を防ぐための鍵となります。

  • ディスクスペースの監視: システム監視ツール（例：Nagios、Prometheus、Zabbixなど）を使用して、データディレクトリとアーカイブ場所の空きスペースを追跡します。

  • WAL生成の監視: pg_stat_wal_receiver（スタンバイ上）と pg_stat_archiver（プライマリ上）をクエリして、WALアクティビティとアーカイブの成功状況を把握します。

    ```sql
    -- Check WAL generation rate (approximate)
    SELECT pg_size_pretty(pg_current_wal_lsn()::bigint - pg_last_wal_write_lsn()::bigint) AS current_wal_written;

    -- Check WAL file age
    SELECT pg_walfile_name(f.path) AS wal_file, pg_wal_file_name(f.path) < pg_current_wal_lsn() AS is_old
    FROM pg_ls_dir('/path/to/your/pg_wal') AS f(path)
    ORDER BY f.path;
    ```

ディスク満杯時のトラブルシューティング手順

WALアクティビティによりディスクが既に満杯になっている場合は、直ちに対応が必要です。

  1. 原因の特定: pg_stat_archiver でアーカイブの失敗を確認します。pg_replication_slots で未使用または問題のあるスロットを調べます。スタンバイでのレプリケーション遅延を確認します。
  2. スペースの解放（一時的な措置）:
    • アーカイブが有効で機能している場合: リカバリに不要であると確信できる非常に古いアーカイブ済みWALファイルを、手動でいくつか削除することを試みます（細心の注意を払ってください）。
    • アーカイブが有効になっていない、または失敗している場合: 可能な場合は、完了したWALファイルを pg_wal から別のディスクに一時的に移動する必要があるかもしれません。または、バックアップがある場合は、データベースの再初期化を検討します（これは極端な措置です）。
  3. 根本原因への対処:
    • アーカイブの修正: archive_command が正しいこと、および宛先にスペースがあることを確認します。
    • スロットの管理: 未使用のレプリケーションスロットを破棄します。
    • レプリケーションの修正: スタンバイの遅延を引き起こしている問題に対処します。
    • ディスクスペースの増加: 一時的または永続的にストレージを追加します。
  4. アーカイバの再起動（スタックしている場合）: アーカイバプロセスがスタックすることがあります。PostgreSQLを再起動すると役立つ場合がありますが、その影響を理解していることを確認してください。

結論

高いWALアクティビティは、PostgreSQL環境で一般的な課題であり、多くの場合、集中的な書き込み操作やレプリケーションおよびアーカイブに関する問題に起因します。WALアーカイブを慎重に有効化および監視し、max_slot_wal_keep_size と wal_keep_size を使用して保持ポリシーを正しく構成し、レプリケーションスロットを管理し、アーカイブされたWALファイルに対して堅牢なクリーンアップ戦略を実行することにより、ディスクスペースの枯渇を効果的に防ぎ、健全で信頼性の高いPostgreSQLデータベースを維持することができます。これらの問題に対する最善の防御策は、予防的な監視であり続けます。