WALは自動的に有効になります。 WALログが必要とするディスク容量の確保することと、必要なチューニングを実施すること以外は(30.5を参照)、管理者は何もする必要はありません。
新しいレコードが作成されるごとに、WALレコードがWALログに追加されます。
挿入位置はログシーケンス番号(LSN)によって記録されます。LSNはログのバイトオフセットで、新しいレコードごとに単調増加します。
LSN値は、pg_lsn
データ型として返されます。
2つのLSN値を比較することでWALデータの差分量を計算することができるので、レプリケーションやリカバリの進捗状況を測定できます。
WALログは、データディレクトリ以下のpg_wal
ディレクトリに、通常16メガバイトのサイズを持つセグメントファイルの集合として格納されています(ただし、このサイズはinitdbの--with-wal-segsize
オプションで変更できます)。
各セグメントは通常8キロバイトのページに分割されます(このサイズは--with-wal-blocksize
というconfigureオプションで変更できます)。
ログレコード用のヘッダはaccess/xlogrecord.h
に記述されています。レコードの内容は、ログの対象となるイベントの種類によって異なります。
セグメントファイルは名前として000000010000000000000001
から始まる、常に増加する数が与えられています。
数字は巡回しませんが、利用可能な数字を使い尽くすには非常に長い時間がかかるはずです。
主要なデータベースファイルが置いてあるディスクとは別のディスクにログを置くと利点があります。
これはpg_wal
ディレクトリを別の場所に(もちろんサーバを終了しておいてから)移動し、主データディレクトリ以下の元々の場所から新しい場所へのシンボリックリンクを張ることによって可能となります。
WALの目的である、確実にデータベースレコードが変更される前にログが書き出されることは、実際にはキャッシュにしかデータがなく、ディスクには格納されていない時にディスクドライブが格納に成功したとカーネルに虚偽の報告を行うことによって失われる可能性があります。 そのような状況では、電源が落ちた際に、復旧不可能なデータ破損が起こることがあります。 管理者は、PostgreSQLのWALログを保持しているディスク装置がそのような嘘の報告をしないように保証するべきです。(30.1を参照して下さい。)
チェックポイントが実行され、ログがフラッシュされた後、チェックポイントの位置はpg_control
に保存されます。
したがって、リカバリの開始時は、サーバはまずpg_control
を読み、次にチェックポイントレコードを読みます。
そして、チェックポイントレコード内で示されたログの位置から前方にスキャンしてREDO処理を行います。
データページの内容全体は、チェックポイント後の最初のページ変更時にログ内に保存されますので(full_page_writesパラメータが無効にされていないという前提です)、そのチェックポイント以降に変更された全てのページは一貫した状態に復旧されます。
pg_control
が壊れた場合に備え、ログセグメントを逆順に読み(すなわち新しいものから古いものへと)、最終チェックポイントを見つける方法を実際には実装した方が良いと思われます。
まだこれはできていません。
pg_control
はかなり小さなもの(1ディスクページ未満)ですので、一部のみ書き込みされるという問題は起こりません。
またこの書き込みの時点では、pg_control
自体の読み込みができないことによるデータベースエラーという報告はありません。
このため、pg_control
は理屈では弱点ですが、実質問題になりません。