9.2. 実装

WALは7.1以降では自動的に有効になります。 WALログが必要とする追加ディスク容量を確保すること、 そして必要ならばチューニングすることを除いては(Section 9.3参照)、システム管理者は何もする必要はあり ません。

WAL$PGDATA/pg_xlogディレ クトリに、16MBのサイズをもつセグメントファイルの集合として格納されてい ます。セグメントは8KBのページに分割されます。 ログレコード用のへッダーはaccess/xlog.hに記述され ています;レコード内容は、ログの対象となる事象のタイプによって異なりま す。セグメントファイルは名前として 0000000000000000からはじまる順序数が与えられてい ます。いまのところ、数字は巡回しませんが、利用可能な数字を使い尽くすには 非常に長い時間がかかるはずです。

WALバッファは共有メモリ上の制御構造で、バックエンド が使用します。保護はスピンロックで行います。必要な共有メモリの量はバッ ファの数によります。WALバッファはデフォルトでは64KB です。

主要なデータベースファイルが置いてあるディスクとは別のディスクにログを 置くと利点があります。これはpg_xlogディレクトリを 別な場所に(もちろんpostmasterを落しておいてから)移動し、 $PGDATAの元々の場所からシンボリックリンクを 張ることによって可能となります。

WALの目的は、データベースレコードが置き換えられたり、 あるいは、実際にはディスクドライブのキャッシュにデータがあり、まだディ スクに書き込まれていないのに、書込が成功したと嘘の報告をカーネルにする ようなディスクドライブによってデータが破壊されたりする前に、ログが書き 込まれることを保証することにあります。そのような情況では、電源が落ちた 際に、復旧不可能なデータの破壊が起ることがあります。システム管理者は、 PostgreSQLのデータとログを保持しているディ スク装置がそのような嘘の報告をしないように保証するべきです。

9.2.1. WALによるデータ回復

チェックポイントが実行され、ログがフラッシュされた後、チェックポイント の位置はpg_controlに保存されます。したがって、デー タ回復を行う場合はバックエンドはまず pg_control を読み、次にチェックポイントレコードを読みます。そして、チェックポイン トに位置が記録されているredoレコードを読み、REDO操作を開始します。チェッ クポイント後最初のページ変更によってページ内容全体がログに保存されてい るので、そのページは最初に一貫した状態に復旧されます。

pg_controlのチェックポイント位置を使うことによっ て回復処理のスピードは早くなりますが、pg_control が壊れた場合に備え、ログセグメントを逆順に読み -- すなわち新しいものか ら古いものへと --、最終チェックポイントを見付ける方法を実際には実装し た方が良いと思います。リリース7.1ではまだこれはできていません。