25.1. 様々な解法の比較

データベースのコピーを 1つだけ保有すればよいため、共有ディスクを用いたフェールオーバは同期によるオーバーヘッドを回避できます。 本解法では、複数のサーバが単一のディスクアレイを共有します。 主データベースサーバが故障したとき、まるでデータベースの破損から復旧したように、スタンバイサーバが元のデータベースを実装して稼動できます。 これはデータの消失がない高速なフェールオーバを行うことができます。

ハードウェアを共有するという機能は、ネットワーク上の記憶装置では一般的です。 ネットワークファイルシステムの利用も可能ですが、そのファイルシステムがPOSIX仕様を満たしているか注意してください。 （ 項17.2.1を見てください）。 本解法には重大な制約があり、共有ディスクアレイが故障または破損したとき、プライマリサーバもスタンバイサーバも機能しなくなります。 また、プライマリサーバが稼動している間は、スタンバイサーバが共有記憶装置にアクセスしてはなりません。

ハードウェア共有機能の改善の一つとしてファイルシステムのレプリケーションをあげることができます。 それは、あるファイルシステムに対して行われたすべての変更を他のコンピュータに存在するファイルシステムにミラーリングします。 制約はただ一つであり、スタンバイサーバがファイルシステムの一貫したコピーを自身の領域に持つようにミラーリングしなければなりません。具体的には、スタンバイサーバへの書き込みがマスタサーバへの書き込みと同じ順序でおこなわれなければなりません。 LinuxにおけるDRBDは、ファイルシステムレプリケーションで広く受けいれられている手法です。

ウォームスタンバイおよびホットスタンバイサーバは、ログ先行書き込み（WAL）のレコードを解読して最新の状態を保持できます。 プライマリサーバが故障したとき、スタンバイサーバがプライマリサーバのほぼすべてのデータを保存して、速やかに新しい主データベースを稼動できます。 本解法は同期、非同期で行うことができ、データベース全体だけを範囲として処理できます。

スタンバイサーバは、ファイル単位のログシッピング（項25.2参照）またはストリーミングレプリケーション（項25.2.5参照）または両者の併用を使用して実装できます。 ホットスタンバイの情報は 項25.5 を参照してください。

マスタとスタンバイによるレプリケーションでは、データ更新のすべての問い合わせをマスタサーバに送付します。 マスタサーバは更新したデータを非同期でスタンバイサーバに送付します。 マスタサーバが稼動している間、スタンバイサーバは読み取り問い合わせだけに応答します。 スタンバイサーバはデータウェアハウスへの問い合わせに理想的です。

この種類のレプリケーションの一例はSlony-Iであり、テーブル単位の粒度を持ち、複数のスタンバイサーバが稼動できます。 （バッチ処理によって）スタンバイサーバのデータを非同期で更新するため、フェールオーバにおけるデータ消失の可能性があります。

文に基づいたレプリケーションのミドルウェアでは、プログラムがすべてのSQL問い合わせを採取して、1つまたはすべてのサーバに送付します。 なお、各々のサーバは独立して稼動します。 読み書き問い合わせは、すべてのサーバがすべての変更を受け取るように全サーバに送付されなければなりません。 しかし、読み取り専用の問い合わせはサーバ全体の読み取り負荷を分散させるために、1つのサーバだけに送付することができます。

問い合わせを修正しないで送付した場合、random()関数による乱数値とCURRENT_TIMESTAMP関数による現在時刻およびシーケンス値が、サーバごとに異なることがあります。 その理由は、各サーバが独立して稼動しているため、および、SQL問い合わせの送付では実際に更新した行の識別値を取得できないためです。 これが許容できない場合は、ミドルウェアかアプリケーションにおいて1つのサーバにこのような問い合わせを送付し、その結果を書き込み問い合わせで使用しなければなりません。 その他の選択肢は従来のマスタとスタンバイによるレプリケーションのオプションを使用するものです。 すなわち、データ更新の問い合わせをマスタサーバだけに送付し、ミドルウェアによるレプリケーションを使わずにマスタとスタンバイによるレプリケーションを介してスタンバイサーバに伝達します。 トランザクションをコミットするか中断するかについても、全サーバが同一となるよう注意しなければなりません。 これには2相コミット（PREPARE TRANSACTION および COMMIT PREPARED）を使用することになるでしょう。 Pgpool-IIとContinuent Tungstenがこのレプリケーションの一例です。

ラップトップやリモートマシンのように、通常は接続されていないサーバ間において、データの一貫性を保持することは挑戦的な課題です。 非同期マルチマスタレプリケーションの使用により、全サーバの独立した稼動、およびトランザクションの衝突を識別するための定期的な通信を実現します。 トランザクションの衝突は、利用者および衝突回避法によって解決できるでしょう。 Bucardoはこの種のレプリケーションの一例です。

同期マルチマスタレプリケーションでは全てのサーバが書き込み要求を受理できます。 受理したサーバは更新したデータを、トランザクションをコミットする前に、他の全サーバへ配布します。 書き込み負荷が重いとき、ロックの掛かり過ぎによる作業効率の低下の原因となりえます。 実際、書き込み効率は単一サーバより悪いことが大半です。 読み取り要求はどのサーバにも送付できます。 通信による負荷を減らすには、共有ディスクが実装されます。 同期マルチマスタレプリケーションは、主に読み取り作業負荷の低減に最適ですが、全てのサーバが書き込み要求を受理できることも大きな利点です。 その利点とは、マスタとスタンバイ間で作業負荷を分けなくてよいこと、および更新データが1つのサーバから他のサーバに送付されるため、出力が確定しないrandom()関数などによる問題が起こらないことです。

PostgreSQL では、この種類のレプリケーションを提供しません。 しかし、PostgreSQL の 2相コミット（PREPARE TRANSACTIONおよびCOMMIT PREPARED）を使用すれば、アプリケーションのコードまたはミドルウェアにおいて本解法を実装できます。

PostgreSQL はオープンソースであり、容易に拡張できます。 そのため多数の企業が、PostgreSQLを取り入れて商業的な解法を作成し、フェールオーバとレプリケーションと負荷分散の機能を独自に実現していますが、ソースコードは非公開です。

データの分割とは、同じテーブルのデータを複数部分に分けることです。 各部分に書き込むことができるのは、1つのサーバだけです。 例えば、データをロンドンとパリの営業所用に分割でき、サーバをロンドンとパリのどちらにも設置できた状態を考えます。 問い合わせにロンドンとパリのデータが混在した場合、アプリケーションは両方のサーバに問い合わせることができます。 または、マスタスタンバイレプリケーションを使用して、他の営業所のデータを読み取り専用コピーとして保持できます。

上述した多くの解法は、複数のサーバが複数の問い合わせを処理するものです。 処理速度の向上のために、単一の問い合わせに複数のサーバを使用するものはありません。 本解法は複数のサーバが単一の問い合わせを共同して実行するものです。 その方法は、データをサーバ間で分割し、各サーバが部分的に問い合わせを実行し、各々の結果をプライマリサーバに送付し、プライマリサーバが合体して利用者に返送するものです。 Pgpool-IIはこの性能を持っています。 また、PL/Proxyツールセットを使用して実装できます。