他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

第 25章ログ先行書き込み (WAL)

目次
25.1. WALの利点
25.2. WALの設定
25.3. 内部

ログ先行書き込みWAL)はトランザクションのログを残すための一般的な手法です。 詳細にわたって全てを網羅しているとはいえませんが、たいていのトランザクション処理について書かれた書籍に記載されています。 簡単にいうと、WALの基本的な考え方は、データファイルへの変更はログに記録され、つまり、変更内容を記述したログレコードが永続格納領域に書き出され、その後にのみ(テーブルやインデックスがある)データファイルに書き出されなければならないということです。 このような手順に従って処理を行えば、たとえクラッシュが起きてもログを使ってデータベースをリカバリすることができるため、トランザクションのコミットの度にデータページをディスクに吐き出す必要がなくなります。 リカバリの時点では、まず、データページに対してまだ行われていない変更分はログレコードを使って再実行されます。(これがREDOとして知られているロールフォワードリカバリです。)

25.1. WALの利点

WALを採用する1つ目の明白な利点はディスクへの書き込み回数が大幅に減ることです。 というのは、トランザクションコミットの時にそのトランザクションで変更された全てのデータファイルではなく、ログファイルだけをディスクに吐き出せばよいからです。 マルチユーザ環境では、多くのトランザクションのコミットをログファイルの1回のfsync()で済ますことができます。 それだけではなく、ログファイルへの書き込みはシーケンシャルに行なわれるため、データページを吐き出すコストに比べログファイルの同期はずっと低コストになります。 これは特に、データ格納領域の様々な部分を変更する小さなトランザクションを多く扱うサーバで顕著に現れます。

2つ目の利点は、データページの一貫性です。 実際、WALが導入される前は、PostgreSQLはクラッシュした時に一貫性を保てるという保証はありませんでした。 WAL導入以前では、書き込み中にクラッシュした場合に次のようなことが起こる可能性がありました。

  1. 存在しないテーブル行をインデックス行が指す

  2. 分割処理中にインデックス行が失われる

  3. 部分的にしかデータページが書かれていないために、完全にテーブルやインデックスのページの内容が壊れてしまう

このインデックスに関わる問題(上記の1と2)は、fsyncの呼び出しを追加すれば解決できる可能性があります。 しかしWALが無い場合、最後の問題を解決するかというのはわかりません。 WALは、クラッシュ後の修復時にページの一貫性を保証するために必要とされるページであれば、そのデータページ内容全体をログに保存します。

最後に、WALにより、項22.3で説明するオンラインバックアップとポイントインタイムリカバリをサポートすることができます。 WALのデータを保持することにより、そのWALデータが範囲内とする任意の時点に戻すことができます。 単純にデータベースの主となる物理バックアップをインストールし、WALログを目的の時点まで単に再生することで実現できます。 更に、物理バックアップはインスタンス化可能なデータベース状態のスナップショットである必要もありません。 ある程度の時間を経過して作成されたバックアップであっても、その期間用のWALを再生することにより、内部の不整合を修復します。