★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 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

30.3. ログ先行書き込み(WAL) #

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

ヒント

WALによりデータベースファイルの中身を障害後にリストアするため、信頼性のある格納領域にあるデータファイルやWALファイルに対しては、ジャーナルファイルシステムは必要ありません。 実際、特に、もしファイルシステムのデータをディスクにフラッシュさせている場合には、ジャーナリングのオーバーヘッドは性能を劣化させることがあります。 幸運なことに、ジャーナリング中のデータのフラッシュをマウントオプションにより無効にできることが多いです。例えばLinuxのext3ファイルシステムでは、data=writebackと指定します。 ジャーナルファイルシステムは障害後の起動速度を改善します。

WALを使用することでディスクへの書き込み回数が大幅に減少します。 と言うのも、トランザクションがコミットされたことを保証するために、そのトランザクションで変更された全てのデータファイルではなく、WALファイルだけをディスクにフラッシュする必要があるからです。 WALファイルへの書き込みはシーケンシャルに行われるため、データページをフラッシュするコストに比べWALの同期はずっと低コストになります。 これは特に、データ格納領域の様々な部分を変更する小さなトランザクションを多く扱うサーバで顕著に現れます。 さらに、サーバが小規模なトランザクションを同時に多く処理する時、WALファイルを一度fsyncすることで、多くのトランザクションをコミットすることができる場合もあります。

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