他のバージョンの文書 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 仕様(各 UNIX 間の互換性の仕様)を満たしているか注意してください。 ( 項17.2.1を見てください)。 本解法には重大な制約があり、共有ディスクアレイが故障または破損したとき、プライマリサーバもスタンバイサーバも機能しなくなります。 また、プライマリサーバが稼動している間は、スタンバイサーバが共有記憶装置にアクセスしてはなりません。

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

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

ポイントインタイムリカバリ(PITR)を用いたウォームスタンバイおよびホットスタンバイ

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

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

トリガベースのマスタ・スタンバイレプリケーション

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

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

文に基づいたレプリケーションのミドルウェア

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

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

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

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

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

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

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

商業的な解法

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

表(表25-1)は、上述した種々の解法の性能を抜粋したものです。

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

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

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

データの分割

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

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

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