Pgpoolの各動作モードの使いどころ

Pgpoolには、以下のような動作モードがあり、用途によって使い分けることができます。それぞれの特徴やメリットをまとめた上で、各動作モードの使いどころを整理してみたいと思います。特にレプリケーション機能に関する違いがポイントとなります。

ここでは、Pgpool2.3.3をベースに記述しています。

レプリケーションモードでの利用

この動作モードは、Pgpool単体で、レプリケーション機能を提供できるという特徴があります。

• 動作概要
  • INSERT,UPDATE,DELETEはマスタ、スレーブ両方に発行
  • SELECTは、マスタ、スレーブのどちらかに発行
  • SELECTは、複数のサーバに対して、負荷分散可能

• 機能的なメリットやデメリット
  • Pgpoolのみでレプリケーション可能であり、他のミドルウェアは不要（○）
  • 同期レプリケーションであるため、SELECTを負荷分散した場合も、ノードによって結果が異なることはない（○）
  • 但し、全サーバの更新が完了するまで、クライアントは待たされる。データ更新遅延の可能性（×）
  • ステートメントベースのレプリケーションであり、実行時に不定な関数（sysdate(),random()）をSQL内で利用できないことに注意が必要（×）
  • データベースクラスタ単位のレプリケーションであり、一部のテーブルのみを対象とすることはできない。（△）*1

参考http://ossipedia.ipa.go.jp/capacity/EV0612150226/

pgpool.conf設定のポイント

replication_mode = true・・1
load_balance_mode = false・・2
master_slave_mode = false・・3

1. レプリケーションモードで動作させる場合はtrueを指定します。
2. デフォルトはfalse。trueを指定すると、SELECT文を複数のノードに対して、ロードバランスを行います。
3. falseにします。(replication_modeの項目と同時にtrueにはできません)

参考http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-ja.html

マスタ/スレーブモードでの利用

この動作モードは、Pgpoolがレプリケーション機能を提供しないため、Slony-Iなどのマスタ-スレーブ方式のレプリケーションソフトと併せて利用する必要があるという特徴があります。

• 動作概要
  • INSERT,UPDATE,DELETEはマスタにのみ発行
  • SELECTは、マスタ、スレーブのどちらかに発行
  • SELECTは、複数のサーバに対して、負荷分散可能

• 機能的なメリットやデメリット
  • レプリケーションを行うには、他のミドルウェア（Slony-Iなど）が必要（×）
  • Slony-Iは、非同期レプリケーションであるため、SELECTを負荷分散した場合、ノードによって結果が異なる場合がある（×）
  • 非同期レプリケーションであるため、クライアントはマスタサーバが更新される間のみ待つだけでよく、データ更新のレスポンスが早くなることが期待できる。（○）*2
  • Slony-Iは、トリガベースのレプリケーションであり、実行時に不定な関数（sysdate(),random()）をSQL内で利用可能（○）*3
  • Slony-Iは、テーブル単位のレプリケーションであり、一部のテーブルのみを対象とすることができる。（△）*4

参考http://ossipedia.ipa.go.jp/capacity/EV0612230252/

pgpool.conf設定のポイント

replication_mode = false・・1
load_balance_mode = true・・2
master_slave_mode = true・・3

1. falseにします。(master_slave_modeの項目と同時にtrueにはできません)
2. デフォルトはfalse。trueを指定すると、SELECT文を複数のノードに対して、ロードバランスを行います。
3. マスタ/スレーブモードで動作させる場合はtrueを指定します。

参考http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-ja.html

まとめ。結局、どちらがよいのか。

Pgpoolを導入する目的は、結局は、アクセス負荷対策です。従って、どちらの動作モードを選択するかは、どんなアクセス負荷の傾向（重要なのは更新アクセスと参照アクセスの比率）が想定されるのか、更新のレスポンス時間はどの程度重要視する必要があるのかなどを総合的に考えて判断することになります。

• 更新と参照の割合で、極端に参照が多く(更新:参照＝1:100など)、更新のレスポンスがそれほど重要でない場合は*5、Pgpool単体でレプリケーションを実現できる『レプリケーションモード』を採用することを考えます。『レプリケーションモード』の弱点は、全ノードに対する更新が終わるまで、待たなければならないため、更新のレスポンスが悪いということですが、更新性能が問われないのであれば、簡易に実現できるこのモードは有利だと思っています。

• 逆に、更新のレスポンス時間が重要というケース*6は、『マスタ/スレーブモード』の採用を考えます。Slony-Iを併せて構築、運用する必要があるため面倒ですが、更新レスポンスが重要な場合には仕方がないと思います。

(2011.1.6 追記)補足 SELECT文が負荷分散される条件

pgpool.confで以下のように設定されている場合、SELECT文が複数ノード間で負荷分散されます。

load_balance_mode = true

但し、上記の設定を行うだけではダメです。以下の条件も満たす必要があります。*7

• 明示的なトランザクション内のSELECTは負荷分散されません。（つまり、BIGINコマンドが発行された場合、マスタをSELECTします）*8
• SELECT文であること。（クエリ文字列の先頭が「SELECT」であること）
  • SELECT INTO 文ではない
  • SELECT FOR UPDATE/SELECT FOR SHARE文ではない
• PostgreSQLのバージョンが7.4以降である

*1:個人的にはテーブル単位より分かりやすいし、あまりテーブル単位でやりたいシーンが思い浮かばないので、全然問題ないと思っています。

*2:但し、マスタサーバの更新負荷が下がるわけではないので、マスタサーバの負荷対策は別途必要になる場合があります。

*3:但し、Pgpoolでの日付関数は影響がある場合があります。

*4:個人的にはテーブル単位というのや、開発や運用面でやや面倒なので、あまり好きではないです。

*5:CMSを利用し、一般ユーザにコンテンツ配信をしている場合などが、このケースに該当すると思います。更新はあくまでCMS管理者のみであり、一般ユーザは参照のみであるためです。

*6:一般ユーザ自身が更新を行う、CGM系サービスなどのケースが該当すると思います。この場合は、更新レスポンス時間が重要と考えられるため、このモードを利用します。

*7:『マスタ／スレーブモード』の場合は特に重要な条件です。例えば、SELECT文を、明示的なトランザクション中で発行すると、全てマスタサーバに集中することになり、Pgpoolの意味がなくなります。

*8:メジャーバージョンアップ版であるPgpool3.0では、明示的なトランザクション内のSELECTでも負荷分散できるようになりました。