他のバージョンの文書 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.1. 様々な解法の比較

共有ディスクを用いたフェールオーバ

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

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

ファイルシステム(ブロックデバイス)レプリケーション

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

非同期マルチマスタレプリケーション

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

同期マルチマスタレプリケーション

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

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

商業的な解法

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

表25.1「高可用性、負荷分散およびレプリケーションの特徴」は上述した種々の解法の機能を要約したものです。

表25.1 高可用性、負荷分散およびレプリケーションの特徴

特徴共有ディスクを用いたフェールオーバファイルシステムのレプリケーショントランザクションログシッピングマスタとスタンバイによるトリガに基づいたレプリケーション文に基づいたレプリケーションのミドルウェア非同期マルチマスタレプリケーション同期マルチマスタレプリケーション
最も一般的な実装NASDRBDストリーミングレプリケーションSlonypgpool-IIBucardo 
通信方法共有ディスクディスクブロックWALテーブル行SQLテーブル行テーブル行および行ロック
特別なハードウェアが不要 
複数のマスタサーバが可能    
マスタサーバにオーバヘッドがない    
複数のスレーブサーバを待たない 同期が無効の場合  
マスタの故障によるデータ損失がない同期が有効の場合  
スタンバイは読み取り問い合わせだけを受理  ホットスタンバイ使用時
テーブルごとの粒度となる    
コンフリクトの回避が不要  

上の分類に該当しない解法もあります。

データの分割

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

複数サーバによる問い合わせの並列実行

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