pgpool-II の概要

サーバが切り離されます（フェイルオーバ）。

○ 負荷分散

レプリケーションを運用している場合、どのサーバに問い合わせても同じ結果が返ってきます。 多数の検索リクエ ストをそれぞれのサーバで分担して負荷を軽減させ、システム全体の性能を向上させることができます。最良の場 合にはサーバ台数に比例した検索性能向上が見込めます。

○ パラレルクエリ

複数のサーバにデータを分割して受け持たせ、それぞれのサーバに同時に検索問い合わせを投げて、 問い合わ せの処理時間を短縮するパラレルクエリが利用できます。 特に大規模なデータベースに対して検索を実行すると きに威力を発揮します。

○ レプリケーション機能

本検証で主に利用する機能はレプリケーションと負荷分散です。レプリケーションについて詳しく見ていきます。

pgpool-II では、2 つのレプリケーションモードがあります(pgpool-II を起動する際にどれかを選択します)。この他、

Slony-I を使うレプリケーションモードもありますが、現在ではあまり使われていないので、説明は省略します。

1) ネィティブレプリケーションモード

更新クエリをすべての PostgreSQL に送信することにより、データベースのレプリケーションを実現します。

2) ストリーミングレプリケーションモード

pgpool-II自体はレプリケーションを行なわず、PostgreSQL にストリーミングレプリケーションを設定することに よって、レプリケーションを実現する方法です。

pgpool-II は、コネクションプーリングと負荷分散、それにフェイルオーバのみを行ないます。

図 3.19: pgpool-II のレプリケーションモード

（3） ネィティブレプリケーションモード

今回の検証で利用したのはネィティブレプリケーションモードです。この方式では、以下のようにレプリケーションが 行なわれます。

このように、クライアントに更新クエリの応答が返ってきた後はすべてのサーバで更新が完了していることが保証 されるため、これは同期レプリケーションとなります。

同期レプリケーションでは、クライアントは負荷分散によって異なるサーバに振り分けられた SELECTがタイミング によって異なる結果（古い結果）を受け取る可能性がないため、PostgreSQL に直接接続していることを前提にした プログラムの修正の必要がありません。

ただし、ステップ 2-3 で応答待ちを行なう必要があるため、直接PostgreSQL に接続して更新を行なう場合に比 べて、必ず更新性能は悪くなります。

• PostgreSQL 2ノードの場合、マスタ(ノード 0)の更新を待ってからノード 1 を更新するので総合性能は PostgreSQL を直接使う場合の半分、つまり 50%の性能

• PostgreSQL 3ノード以上では、2, 3...ノードは並列に更新を行なうので、やはり 50%

• ノードあたりの性能は、全体性能が2ノード以上、何ノードになっても全体性能が50%なので、ノード数 に応じて性能低下

図に、pgpool-II の同期レプリケーションにおける更新性能の理論値を示します。

図 3.20: PostgreSQL のストリーミングレプリケーションと pgpool-II の組み合わせ

1. クライアントは更新クエリを pgpool-II に送信します。

2. pgpool-II はまず更新クエリをマスタサーバ(健全なサーバのうち、最初に設定ファイルに記述されてい るサーバ)に送信、応答を待ちます。

3. マスターサーバから応答が返ってきたら、他のサーバにも同時に更新クエリを送信します。

4. すべてのサーバから更新コマンドの実行完了が返ってきたら、応答をクライアントに返します。

一方、ストリーミングレプリケーションモードでは、マスタサーバのデータよりもスタンバイサーバのデータが遅れて いることを常に意識するように、プログラムや運用で工夫をする必要があります（たとえば、画面から更新を受け付け た後「更新が反映されるまで少し時間がかかる場合があります」のようなメッセージを出力するなど）。

反面、更新性能の低下は、ネィティブレプリケーションモードほど激しくありません。