他のバージョンの文書 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

第 26章信頼性とログ先行書き込み

目次
26.1. 信頼性
26.2. ログ先行書き込み(WAL)
26.3. WALの設定
26.4. WALの内部

本章では、効率的に信頼できる操作を得るためにログ先行書き込みがどのように使用されているかについて説明します。

26.1. 信頼性

信頼性は、すべての深刻なデータベースシステムで重要な特性です。 PostgreSQLは信頼できる操作を保証することができます。 信頼できる操作とは、コミットされたトランザクションにより記録されたデータはすべて不揮発性の領域に格納され、電源断、オペレーティングシステムの障害、ハードウェアの障害(当然ですが、不揮発性の領域自体の障害は除きます。)があっても安全であるという点です。 通常、コンピュータの永続的格納領域(ディスク装置など)へのデータ書き込みの成功がこの条件を満たします。 実際、コンピュータに致命的な障害が発生したとしても、もしディスク装置が無事ならば、類似のハードウェアを持つ別のコンピュータに移すことができ、コミットされたトランザクションを元通りに復元できます。

データを周期的にディスクプラッタに書き出すことは簡単な操作に思われるかもしれませんが、そうではありません。 ディスク装置は主メモリ、CPU、コンピュータの主メモリとディスクプラッタの間にある各種のキャッシュ層と比べ非常に低速であるからです。 まず、オペレーティングシステムのバッファキャッシュが存在します。 これは頻繁にアクセス要求があるディスクブロックをキャッシュし、ディスクへの書き込みをまとめます。 好運にもすべてのオペレーティングシステムがバッファキャッシュをディスクに強制書き込みさせる方法をアプリケーションに提供しています。 PostgreSQLはこの機能を使用します。 (これを調整する方法についてはwal_sync_methodパラメータを参照してください。)

次に、ディスク装置のコントローラキャッシュが存在する可能性があります。 特に、RAIDコントローラカードでは、これは一般的です。 これらはwrite-throughキャッシュ、つまり、データが届いた時に即座に書き込みがディスク装置に対して行なわれる、の場合があります。 また、write-backキャッシュ、つまり、多少遅れて書き込みがディスク装置に対して行なわれる、の場合もあります。 こうしたキャッシュではディスクコントローラキャッシュが揮発性、つまり、電源障害の際にその内容が失われてしまいますので、信頼性に関する障害が発生する可能性があります。 より優れたコントローラカードではバッテリ付きの キャッシュを持ちます。 つまり、システムの電源が落ちている上体でもキャッシュに電源を供給します。 後で電源が復旧した後に、データがディスク装置に書き出されます。

最後に、ほとんどのディスク装置がキャッシュを持っています。 一部はwrite-throughであり、一部はwrite-backです。 ディスクコントローラキャッシュの場合と同様にwrite-backのディスク装置キャッシュの場合にはデータが損失する恐れがあります。 一般消費者向けのIDE装置では特に、よくwrite-backキャッシュを使用しています。これは電源障害時にデータが残りません。

オペレーティングシステムが、ディスクハードウェアに書き込み要求を送信した時、データがシステム上の不揮発性格納領域に本当に届いたかどうかを確認することはほぼできません。 ですので、格納用要素がデータ整合性を保証することを確実にするのは、管理者の責任です。 バッテリを持たない書き込みキャッシュを持つコントローラを使用しないでください。 装置レベルでは、もし装置が停止前にデータが書き出されることを保証できないのであれば、write-backキャッシュを無効にしてください。

ディスクプラッタの書き込み操作自体によってもデータ損失が発生することがあります。 ディスクプラッタは、通常512バイトのセクタに分割されています。 物理的な読み込み操作、書き込み操作はすべて、セクタ全体を処理します。 書き込み要求がディスクに達した時、その要求は512バイトに収まるかもしれませんし、1024バイト、または8192バイトに収まるかもしれません。 電源断により、一部の512バイトのセクタに書き込みが行なわれ、残りの書き込みが行なわれていない時点であっても、書き込み処理は失敗します。 こうした問題の対策として、PostgreSQLは、ディスク上の実際のページを変更するに定期的にページ全体のイメージを永続的格納領域に書き出します\。 これにより、PostgreSQLはクラッシュリカバリ時に部分的に書き出されたページを復旧させることができます。 バッテリ付きのディスクコントローラ、または、ファイルシステムソフトウェア(例えばReiser4)により部分的なページ書き出しを防止できるのであれば、full_page_writesを使用してページイメージ作成を無効にすることができます。