29.1. 信頼性

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

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

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

最後に、ほとんどのディスク装置がキャッシュを持っています。一部はwrite-throughであり、一部はwrite-backです。ディスクコントローラキャッシュの場合と同様にwrite-backのディスク装置キャッシュの場合にはデータが損失する恐れがあります。一般消費者向けのIDEおよびSATA装置では特に、よくwrite-backキャッシュを使用しています。これは電源障害時にデータが残りません。ATAPI-6にはZFSext4などで使用しているドライブキャッシュのフラッシュ用コマンド(FLUSH CACHE EXT)が導入されています。(SCSIの SYNCHRONIZE CACHEは長く利用されています。)多くのSSDも揮発性のwrite-backキャッシュを持っており、多くはデフォルトでキャッシュフラッシュ用のコマンドを持っていません。

Linux上で書き込みキャッシュを検査するためにはhdparm -Iを使用してください。 Write cacheの次に *があれば有効です。 hdparm -Wは書き込みキャッシュを無効にします。 FreeBSDではatacontrolを使用してください。 (SCSIディスクの場合、WCEを無効にするためにはsdparmを使用してください。) Solarisではディスク書き込みキャッシュはformat -eで制御されます。 (Solaris ZFSファイルシステムは、独自のディスクキャッシュ吐き出しコマンドを発行しますので、ディスク書き込みキャッシュを有効にしても安全です。) Windowsで、wal_sync_methodopen_datasync(デフォルト)の場合、書き込みキャッシュを無効にするためには、My Computer\Open\{select disk drive}\Properties\Hardware\Properties\Policies\Enable write caching on the diskのチェックを外してください。 Windows上ではまた、fsyncfsync_writethroughは書き込みキャッシュをまったく行いません。

writeバリアを用いている多くのファイルシステム(ZFSext4など)では、write-backが有効なドライブ上にてディスクプラッタにデータをフラッシュするため、FLUSH CACHE EXTSYNCHRONIZE CACHEコマンドを内部的に使用しています。不幸なことに、このようなwriteバリアを持つファイルシステムは、バッテリバックアップ装置付き(BBU)のディスクコントローラと組み合わせた際に、好ましくは動作しません。このような処理の流れにおいて、同期コマンドはBBUにあるデータを全てディスクへ強制的に書き込みを行うため、BBUのメリットの大半を失わせています。PostgreSQLのソースツリー内のsrc/tools/fsyncユーティリティを使うことで、あなたの環境が影響を受けるかどうかを確認できます。もし影響を受けるようであれば、ファイルシステムのwriteバリアを無効にするか、(オプションがあれば)ディスクコントローラを再設定することで、BBUキャッシュによる性能上の効果を得ることできるでしょう。もしwriteバリアを無効にした場合は、バッテリが稼動していることを確認しておきましょう。バッテリの欠陥はデータロスの可能性に繋がります。ファイルシステムやディスクコントローラの設計者が、いずれはこの動作を修正してくれることが望まれます。

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

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