内部

PostgreSQL 8.0.0 文書
前のページ | 巻戻し | 第 25章ログ先行書き込み (WAL) | 早送り | 次のページ

# 25.3. 内部

WALは自動的に有効になります。 WALログが必要とするディスク容量を確保すること、そして必要ならばチューニングすることを除いては（項25.2を参照）、管理者は何もする必要はありません。

WALログは、データディレクトリ以下の`pg_xlog`ディレクトリに、通常16Mバイトのサイズを持つセグメントファイルの集合として格納されています。 各セグメントは通常8Kバイトのページに分割されます。 ログレコード用のへッダは`access/xlog.h`に記述されています。 レコードの内容は、ログの対象となる事象の種類によって異なります。 セグメントファイルは名前として`000000010000000000000000`から始まる、常に増加する数が与えられています。 今のところ、数字は巡回しませんが、利用可能な数字を使い尽くすには非常に長い時間がかかるはずです。

WALバッファとその制御用構造体は共有メモリ上にあり、サーバの子プロセスが使用します。 これらは軽量ロックで保護されています。 必要な共有メモリの量はバッファの数によります。 WALバッファの大きさはデフォルトで、8kバイトのバッファが8個、つまり、全体で64Kバイトです。

主要なデータベースファイルが置いてあるディスクとは別のディスクにログを置くと利点があります。 これは`pg_xlog`ディレクトリを別の場所に（もちろんサーバを終了しておいてから）移動し、主データディレクトリ以下の元々の場所から新しい場所へのシンボリックリンクを張ることによって可能となります。

WALの目的である、確実にデータベースレコードが変更される前にログが書き出されることは、実際にはキャッシュにしかデータがなく、ディスクには格納されていない時に格納に成功したとカーネルに虚偽の報告を行なうディスクドライブによって失われてしまいます。 そのような状況では、電源が落ちた際に、復旧不可能なデータの破壊が起ることがあります。 管理者は、PostgreSQLのWALログを保持しているディスク装置がそのような嘘の報告をしないように保証するべきです。

チェックポイントが実行され、ログが吐き出された後、チェックポイントの位置は`pg_control`に保存されます。 したがって、リカバリを行う場合はサーバはまず`pg_control`を読み、次にチェックポイントレコードを読みます。 そして、チェックポイントレコード内で示されたログの位置から前方をスキャンすることでREDO処理を行います。 データページの内容全体は、チェックポイント後の最初のページ変更時にログ内に保存されますので、そのチェックポイント以降に変更された全てのページは一貫した状態に復旧されます。

`pg_control`が壊れた場合に備え、ログセグメントを逆順に読み（すなわち新しいものから古いものへと）、最終チェックポイントを見付ける方法を実際には実装した方がよいと思われます。 まだこれはできていません。 `pg_control`はかなり小さなもの（1ディスクページ未満）ですので、一部のみ書き込みされるという問題は起こりません。 またこの書き込みの時点では、`pg_control`自体の読み込みができないことによるデータベースエラーという報告はありません。 このため、`pg_control`は理屈では弱点ですが、実質問題になりません。

前のページ | ホーム | 次のページ
WALの設定 | 上に戻る | リグレッションテスト