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

27.1. 様々な解法の比較

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

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

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

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

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

先行書き込みログシッピング

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

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

論理レプリケーション

論理レプリケーションにより、データベースサーバが他のサーバに、データ更新のストリームを送ることができます。 PostgreSQLの論理レプリケーションは、WALから論理的なデータ更新のストリームを構築します。 論理レプリケーションでは、テーブル単位でデータ変更をレプリケーションすることができます。 さらに自分の変更をパブリッシュしているサーバは同時に他のサーバから変更をサブスクライブできるので、複数の方向にデータを流すことができます。 論理レプリケーションの更なる情報については、第31章をご覧ください。 なお、ロジカルデコーディングインタフェース(第49章)を使って、サードパーティー拡張は同様の機能を提供できます。

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

トリガベースのレプリケーションの構成では、通常はデータを変更する問い合わせを指定されたプライマリサーバに送り込みます。 テーブル単位で処理を行い、プライマリサーバはデータの変更を(典型的には)非同期でスタンバイサーバに送信します。 スタンバイサーバは、プライマリが処理中に問い合わせに応答し、ローカルでのデータ変更あるいは書き込み処理を行うことができます。 この形式のレプリケーションは、大量のデータ分析の負荷軽減や、データウェアハウスの問い合わせにしばしば利用されます。

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

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

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

問い合わせを修正しないで送付した場合、random()関数による乱数値とCURRENT_TIMESTAMP関数による現在時刻およびシーケンス値が、サーバごとに異なることがあります。 その理由は、各サーバが独立して稼動しているため、および、実際のデータ変更ではなくSQL問い合わせが送信されるからです。 これが許容できない場合は、ミドルウェアかアプリケーションで単一のソースからそのような値を確定し、その結果を書き込み問い合わせで使用しなければなりません。 トランザクションをコミットするか中断するかについても、全サーバが同一となるよう注意しなければなりません。 これには2相コミット(PREPARE TRANSACTIONおよびCOMMIT PREPARED)を使用することになるでしょう。 Pgpool-IIContinuent Tungstenがこのレプリケーションの一例です。

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

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

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

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

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

表 27.1は上述した種々の解法の機能を要約したものです。

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

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

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

データの分割

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

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

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

また、PostgreSQLはオープンソースで、容易に拡張できるので、多くの企業がPostgreSQLをもとにして、独自のフェイルオーバー、レプリケーション、負荷分散機能を備えたクローズドソースの製品を開発していることに注意してください。 これらについては、ここでは議論しません。