PostgreSQL WALの先行記録、crash recovery、複製条件

PostgreSQLのWrite-Ahead Logging（WAL）は、データページを書き換える前に変更を説明するWAL recordを永続ストレージへ記録する原則です。これによりcommitごとにすべてのtable pageをdata fileへ書かず、障害後にWALをREDOして復旧できます。実際の耐久性はWALがflushされる時点と、synchronous_commit、fsync、storage stack、transactionの種類などに依存します。すべてのcommitが返答時点で無条件に永続化済みとは言えません。LSNはWAL stream上の位置を示し、recoveryやreplicationの進捗比較に使います。

専門家の視点：PostgreSQL貢献者が解説するcheckpoint

PostgreSQL core teamのメンバーで長年の貢献者であるBruce MomjianのWAL資料は、WAL record、crash recovery、PITR、物理・論理replication、replication slotを扱っています。PostgreSQL文書によるとcheckpoint位置はpg_controlに保存され、復旧時にはcheckpoint recordからWALを前方へ読みREDOします。checkpointがあるから、それ以前のWALを直ちにすべて削除できるという意味ではありません。crash recovery、replication、archiveに必要なWALは別条件で保持されます。復旧が常に数秒から数分で終わる保証もなく、再生量、data量、I/O、設定で変わります。

checkpoint調整と障害後の作業

checkpointはdirty bufferの書き込みを調整し、crash recoveryで処理する範囲を制限します。頻度が高すぎると書き込み負荷やfull-page image WALが増え、間隔を長くすると復旧作業量やWAL保持量が増える場合があります。max_wal_sizeはディスク使用量の絶対上限ではありません。archive失敗、replication slot、遅延consumerがWALを保持し続ける可能性があるため、disk監視が必要です。checkpoint_completion_targetなどはPostgreSQL versionと実測workloadに基づいて調整し、機械的にdefaultを変更しないでください。

replication、backup、耐久性目標を分ける

streaming replicationはWALをstandbyへ送り再生します。非同期replicationではprimary障害時にstandby未着の直近commitを失う可能性があります。同期replicationは設定したstandby応答をcommit条件にできますが、遅延と可用性のtrade-offがあります。replication slotはconsumerに必要なWALを保持しますが、停止中のslotはdisk使用量を増やす場合があります。PITRはbase backupとWAL archiveを組み合わせ、指定時点へ復旧しますが、archiveの完全性とrestore手順の検証が前提です。RPO/RTOを定め、replication・slot・archive失敗・diskを監視し、本番と同じversionで復旧訓練を行ってください。

参考資料