Last modified: Mon Feb 22 14:03:07 JST 2010

Welcome to pgpool -II page

pgpool-IIとは

pgpool-IIはPostgreSQL専用のミドルウェアで、PostgreSQLのデータベースクライアントとPostgreSQLサーバの間に割り込む形で動作し、PostgrSQLに以下のような機能を追加します。

コネクションプーリング
PostgreSQLへの接続を保存しておき、再利用することによってPostgreSQLへの接続オーバヘッドを低減でき、システム全体のスループットを向上させることができます。
レプリケーション
pgpool-IIは複数のPostgreSQLサーバを管理することができます。レプリケーションを使用することにより、物理的に2台以上のディスクにリアルタイムでハードディスクのバックアップを取ることができ、万が一どれかのディスクに障害が発生しても運用を継続することができます。
負荷分散
レプリケーションを運用している場合、すべてのPostgreSQLデータベースの内容が一致しているので、どのサーバに問い合わせても同じ結果が返ってきます。このことを利用して、多数のリクエストをそれぞれのサーバで分担して負荷を軽減させ、システム全体の性能を向上させることができます。最良の場合にはサーバ台数に比例した性能向上が見込めます。特に多数のユーザが大量の問い合わせを投げるような環境で威力を発揮します。
接続数の制限
PostgreSQLに接続可能なセッション数には限界があり、それを超えて接続することはできません。かと言って、同時セッション数をむやみに多く設定すると、メモリーなどのリソースが多く消費されてパフォーマンスに影響があります。pgpool-IIでもクライアントからの接続数には上限がありますが、それを超えてもただちにエラーになることはなく、一定の間待たされるようになっています。したがって、pgpool-IIはPostgreSQLへの接続要求を実質的にキューイングし、PostgreSQLへの過大な接続数を制限することが可能です。
パラレルクエリ
複数のサーバにデータを分割して受け持たせ、それぞれのサーバに同時に検索問い合わせを投げて、問い合わせの処理時間を短縮するパラレルクエリが利用できます。特に大規模なデータを検索するときに威力を発揮します。

pgpool-IIはPostgreSQLバックエンドとフロントエンドの通信プロトコルを理解してその間を中継します。すなわち、PostgreSQLのデータベースアプリケーションからはPostgreSQLサーバに、PostgreSQLからはデータベースアプリケーションに見えるように設計されています。そのため、PostgreSQLそのものはもちろん、アプリケーションの開発言語によらず、PostgreSQLのデータベースアプリケーションにほとんど手を加えることなく、pgpool-IIの機能が利用できます。

pgpool-IIの稼働環境

pgpool-IIは、Linuxをはじめ、SolarisやFreeBSDなどのほとんどのUNIX環境で動作します。Windowsでは動きません。対応するPostgreSQLのバージョンは、PostgreSQLの6.4以降です。ただしパラレルクエリモードを使用するときはPostgreSQL 7.4以降をお使いください。

pgpool-IIのインストール

Linux用のRPMパッケージは、CentOS、Fedora用などが提供されています。該当リポジトリをチェックしてみてください。

pgpool-II のソースコードはpgpool開発ページからダウンロードできます。

pgpool-IIのソースコードからのインストールには、gcc 2.9以上、およびGNU makeが必要です。また、pgpool-IIはlibpq(PostgreSQL付属のクライアントライブラリ)を使用するので、ビルドを行うマシン上にlibpqがインストールされていることが必要です。

configureの実行

ソースコードのtar ballを展開したら、configureを実行します。

./configure

configureに指定できるオプションは以下です。

--prefix=path
pgpool-II本体や関連ファイルをインストールするトップディレクトリを指定します。デフォルトは/usr/localです。
--with-pgsql=path
PostgreSQLのクライアントライブラリなどがインストールされているトップディレクトリを指定します。デフォルトはpg_configコマンドで取得できるパスです。
--with-openssl
pgpool-IIをOpenSSLサポート付で作成します。デフォルトではOpenSSLサポートは無効です。

makeの実行

make
make install

でインストールが完了します(GNU makeが必要なので、FreeBSDなどでは makeをgmakeに読み替えてください)。

pgpool-IIの設定

pgpool-IIの設定ファイルはデフォルトでは/usr/local/etc/pgpool.confおよび /usr/local/etc/pcp.confです。pgpool-IIは動作モードによって使用できる機能と、必要な設定項目が異なります。

使用できる機能/モード	rawモード	コネクションプールモード	レプリケーションモード	マスタスレーブモード	パラレルクエリモード
コネクションプーリング	×	○	○	○	○
レプリケーション	×	×	○	×	△(*)
負荷分散	×	×	○	○	△(*)
フェイルオーバ	○	○	○	○	×
パラレルクエリ	×	×	×	×	○
サーバ台数	1以上	1以上	2以上	2以上	2以上
システムDB	不要	不要	不要	不要	必要

(*)パラレルクエリモードでは、レプリケーションまたは負荷分散を有効にする必要があります。ただし、分割して保存しているテーブルに対しては、レプリケーションならびに負荷分散の機能は使用されません。

pcp.confの設定

どの動作モードでも、pcp.confの設定は必要です。pgpool-IIには管理者がpgpool-IIの停止や情報取得などの管理操作を行うためのインターフェイスが用意されています。そのインターフェイスを利用するためにはユーザ認証が必要になるので、そのユーザ名とパスワードをpcp.confに登録します。 pgpool-IIをインストールすると、$prefix/etc/pcp.conf.sampleができるので、それを $prefix/etc/pcp.confという名前でコピーします。

cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf

pcp.confでは空白行や#で始まる行はコメントと見なされます。ユーザとパスワードは、

ユーザ名:[md5暗号化したパスワード]

のように指定します。 [md5暗号化したパスワード]は、$prefix/bin/pg_md5コマンドで作成できます。

./pg_md5 foo
acbd18db4cc2f85cedef654fccc4a4d8

パスワードを引数に渡したくない場合は pg_md5 -p を実行してください。

./pg_md5 -p
password: <パスワードを入力>

pcp.confは、pgpool-IIを動作させるユーザIDで読み取り可能になっていなければなりません。

pgpool.confの設定

前述のように、動作モードによって、pgpool.confの設定項目が異なります。 pgpool-IIをインストールすると、$prefix/etc/pgpool.conf.sampleができるので、それを $prefix/etc/pgpool.confという名前でコピーします。

cp $prefix/etc/pgpool.conf.sample $prefix/etc/pgpool.conf

pgpool.confでは空白行や#で始まる行はコメントと見なされます。

rawモード

単にpgpool-IIを経由して接続するだけのモードです。PostgreSQLサーバへの接続セッション数を制限したり、2台以上のPostgreSQLサーバを用意してフェイルオーバ動作をさせたいときに利用します。

listen_addresses

pgpool-IIがTCP/IPコネクションを受け付けるアドレスをホスト名またはIPアドレスで指定します。「*」を指定するとすべてのIPインタフェースからのコネクションを受け付けます。「''」を指定するとTCP/IPコネクションを受け付けません。デフォルト値は「localhost」です。 UNIXドメインソケット経由のコネクションは常に受け付けます。このパラメータを変更した時には pgpool-II を再起動してください。

port

pgpool-IIがコネクションを受け付けるポート番号です。デフォルト値は9999 です。このパラメータを変更した時には pgpool-II を再起動してください。

socket_dir

pgpool-IIがコネクションを受け付けるUNIXドメインソケットを置くディレクトリです。デフォルト値は'/tmp'です。このパラメータを変更した時には pgpool-II を再起動してください。

pcp_port

pcpが使用するポート番号です。このパラメータを変更した時には pgpool-II を再起動してください。

pcp_socket_dir

pcpがコネクションを受け付けるUNIXドメインソケットを置くディレクトリです。デフォルト値は'/tmp'です。このパラメータを変更した時には pgpool-II を再起動してください。

backend_socket_dir

UNIXドメインソケット経由でpgpool-IIがPostgreSQLと接続する際に使用する PostgreSQLのUNIXドメインソケットが置かれているディレクトリ。デフォルト値は/tmpです。このパラメータを変更した時には pgpool-II を再起動してください。

pcp_timeout

pcpがpgppoolと接続する際のタイムアウト値。0にするとタイムアウトしません。デフォルト値は10(秒)です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

num_init_children

preforkするpgpool-IIのサーバプロセスの数です。デフォルト値は32になっています。なお、問い合わせのキャンセルを行うと通常のコネクションとは別に新たなコネクションが張られます。したがって、すべてのコネクションが使用中の場合は問い合わせのキャンセルができなくってしまうので、ご注意下さい。問い合わせのキャンセルを必ず保証したい場合は、想定されるコネクション数の倍の値を設定することをおすすめします。このパラメータを変更した時には pgpool-II を再起動してください。

child_life_time

pgpool-IIの子プロセスの寿命です。アイドル状態になってから child_life_time秒経過すると、一旦終了して新しいプロセスを起動します。メモリーリークその他の障害に備えた予防措置です。child_life_timeのデフォルト値は300秒、すなわち5分です。0を指定するとこの機能は働きません（すなわち起動しっ放し）。なお、まだ一度もコネクションを受け付けていないプロセスにはchild_life_timeは適用されません。このパラメータを変更した時には設定ファイルを再読み込みしてください。

child_max_connections

各pgpool-II子プロセスへの接続回数がこの設定値を超えると、その子プロセスを終了します。child_life_timeやconnection_life_timeが効かないくらい忙しいサーバで、PostgreSQLバックエンドが肥大化するのを防ぐのに有効です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

client_idle_limit

前回クライアントから来たクエリから、client_idle_limit 秒越えても次のクエリが届かない場合は、クライアントへの接続を強制的に切断し、クライアントからの次のコネクションを待つようにします。デフォルト値は 0(無効)です。このパラメータは、オンラインリカバリのセカンドステージでは無視されます。このパラメータを変更した時には設定ファイルを再読み込みしてください。

authentication_timeout

認証処理のタイムアウト時間を秒単位で指定します。0 を指定するとタイムアウトを無効にします。authentication_timeout のデフォルト値は 60 です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

logdir

pgpool-IIの各種ログファイルを格納するディレクトリです。この下にDBノードの状態を記録するpgpool_statusファイルが書かれます。

pid_file_name

pgpool-IIのpid file(プロセスIDを格納したファイル)のフルパス名です。デフォルト値は'/var/run/pgpool/pgpool.pid'です。このパラメータを変更した時には pgpool-II を再起動してください。

print_timestamp

trueならばpgpool-IIのログにタイムスタンプを追加します。デフォルトは trueです。このパラメータを変更した時には設定ファイルを再読み込みしてください。

connection_cache

trueならPostgreSQLへのコネクションをキャッシュします。デフォルトはtrueです。このパラメータを変更した時には pgpool-II を再起動してください。

health_check_timeout

pgpool-IIはサーバ障害やネットワーク障害を検知するために、定期的にバックエンドに接続を試みます。これを「ヘルスチェック」と言います。障害が検知されると、フェイルオーバや縮退運転を試みます。このパラメータは、ネットワークケーブルが抜けた際などにヘルスチェックが長時間待たされるのを防ぐためのタイムアウト値を秒単位で指定します。デフォルトは20秒です。0を指定するとタイムアウト処理をしません。なお、ヘルスチェックを有効にすると、ヘルスチェックのための余分の接続が1つ必要になりますので、PostgreSQLのpostgresql.confの設定項目の max_connectionsを少くとも1増やすようにしてください。このパラメータを変更した時には設定ファイルを再読み込みしてください。

health_check_period

ヘルスチェックを行う間隔を秒単位で指定します。0を指定するとヘルスチェックを行いません。デフォルトは0です(つまりヘルスチェックを行いません)。このパラメータを変更した時には設定ファイルを再読み込みしてください。

health_check_user

ヘルスチェックを行うためのPostgreSQLユーザ名です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

failover_command

ノードが切り離された時に実行するコマンドを指定します。特殊文字を指定すると、pgpool が必要な情報に置き換えてコマンドを実行します。

文字	意味
%d	切り離されたノード番号
%h	切り離されたノードのホスト名
%p	切り離されたノードのポート番号
%D	切り離されたノードのデータベースクラスタパス
%M	古いマスターのノード番号
%m	新しいマスターのノード番号
%%	'%'文字

このパラメータを変更した時には設定ファイルを再読み込みしてください。

フェイルオーバー時には、pgpoolはまず子プロセスを切断します(結果として、すべてのセッションが切断されます)。次に、pgpoolはフェイルオーバコマンドを実行し、その完了を待ちます。そのあとで新しいpgpoolの子プロセスが起動され、クライアントからの接続を受け付けられる状態になります。

failback_command

ノードが復帰した時に実行するコマンドを指定します。特殊文字を指定すると、 pgpool が必要な情報に置き換えてコマンドを実行します。

文字	意味
%d	復帰したノード番号
%h	復帰したノードのホスト名
%p	復帰したノードのポート番号
%D	復帰したノードのデータベースクラスタパス
%M	古いマスターのノード番号
%m	新しいマスターのノード番号
%%	'%'文字

このパラメータを変更した時には設定ファイルを再読み込みしてください。

fail_over_on_backend_error

trueならば、バックエンドのソケットへの書き込みに失敗するとフェイルオーバします。これはpgpool-II 2.2.xまでの挙動と同じです。 falseにすると、フェイルオーバせず、単にエラーがレポートされてセッションが切断されます。このパラメータをfalseにする場合には、health checkを有効にすることをお勧めします。なお、このパラメータがfalseの場合でも、クライアントがpgpoolに接続する際にバックエンドへの接続に失敗した場合、あるいはバックエンドがシャットダウンされたことをpgpool-IIが検知した場合にはフェイルオーバが起きることに注意してください。このパラメータを変更した時には設定ファイルを再読み込みしてください。

ignore_leading_white_space

trueならば、load balanceの際にSQL文行頭の空白を無視します(全角スペースは無視されません)。これは、DBI/DBD:Pgのように、勝手に行頭にホワイトスペースを追加するようなAPIを使い、ロードバランスしたいときに有効です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

log_statement

trueならばSQL文をログ出力します。この役目はPostgreSQLの log_statementオプションと似ていて、デバッグオプションがないときでも問い合わせをログ出力して調べることができるので便利です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

log_per_node_statement

log_statementと似ていますが、DBノード単位でログが出力されるので、レプリケーションや負荷分散の確認が容易です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

log_hostname

trueならば、psコマンドでの状態表示時にIPアドレスではなく、ホスト名を表示します。また、log_connectionsが有効な場合にはログにホスト名を出力します。このパラメータを変更した時には設定ファイルを再読み込みしてください。

log_connections

trueならば、全てのクライアント接続をログへ出力します。このパラメータを変更した時には設定ファイルを再読み込みしてください。

enable_pool_hba

trueならば、pool_hba.confに従ってクライアント認証を行います。詳細はクライアント認証(HBA)のためのpool_hba.conf設定方法を参照してください。このパラメータを変更した時には pgpool-II を再起動してください。

backend_hostname

使用するPostgreSQLサーバのホスト名を指定します。空文字を指定するとUNIXドメインソケットで接続します。実際には、"backend_hostname"の後に0, 1, 2...と数字を付加して使用する複数のPostgreSQLを区別します。この数字のことを「DBノードID」と呼びます。 DBノードID == 0のPostgreSQLは、特別に「マスターDB」と呼ばれます。なお、複数のDBノードを運用している場合、条件によってはマスターDBがダウンしても運用を続けることができます。この場合は、稼働中かつDBノードIDがもっとも若いものが新しいマスターDBになります。

1台しかPostgreSQLを使用しない場合は、"backend_hostname0"としてください。

backend_hostname は新しく追加した行を設定ファイル再読み込みで追加することができます。すでにある情報を途中で変更することはできません。変更する場合には pgpool-II を再起動してください。

backend_port

使用するPostgreSQLサーバのポート番号を指定します。実際には、"backend_port"の後に0, 1, 2...とDBノードIDを付加して使用する複数のPostgreSQLを区別します。1台しかPostgreSQLを使用しない場合は、 "backend_port0"としてください。

backend_port は新しく追加した行を設定ファイル再読み込みで追加することができます。すでにある情報を途中で変更することはできません。変更する場合には pgpool-II を再起動してください。

backend_weight

使用するPostgreSQLサーバに対する負荷分散の比率を0以上の整数または浮動小数点で指定します。 "backend_weight"の後には、DBノードIDを付加して使用する複数のPostgreSQLを区別します。 1台しかPostgreSQLを使用しない場合は、"backend_weight0"としてください。負荷分散を使用しない場合は、「1」を設定してください。

backend_weight は新しく追加した行を設定ファイル再読み込みで追加することができます。 pgpool-II 2.2.6/2.3以降では、設定ファイルの再読込でbackend_weight値を変更できます。新しく接続したクライアントセッションから、この新しいweight値が反映されます。

backend_data_directory

使用する PostgreSQL サーバのデータベースクラスタのパスを指定します。実際には、"backend_data_directory"の後にDBノードIDを付加して使用する複数のPostgreSQLを区別します。このパラメータはオンラインリカバリの際に使用します。オンラインリカバリを使用しない場合には設定する必要はありません。

backend_data_directory は新しく追加した行を設定ファイル再読み込みで追加することができます。すでにある情報を途中で変更することはできません。変更する場合には pgpool-II を再起動してください。

ssl

trueならばpgpool-IIとフロントエンド、pgpool-IIとバックエンドの間のSSL接続が可能になります。なお、pgpool-IIとフロントエンドの接続にSSLが利用できるためには、ssl_keyとssl_certが設定されてなければなりません。

デフォルトではSSLサポートはオフになっています。SSLサポートを有効にするためには、configure時にOpenSSLサポートを有効にする必要があります。詳細はインストールの項目をご覧下さい。

sslを有効に設定したら、pgpoolの再起動をしてください。

ssl_key

フロントエンドとの接続に使用するプライベートキーファイルのフルパスを指定します。

ssl_keyのデフォルト値はありません。 ssl_keyの設定がない場合は、フロントエンドとの接続でSSLが使用されなくなります。

ssl_cert

フロントエンドとの接続に使用する公開x509証明書のフルパスを指定します。

ssl_certのデフォルト値はありません。 ssl_certの設定がない場合は、フロントエンドとの接続でSSLが使用されなくなります。

SSL証明書の生成

証明書の扱いについてはこのマニュアルの範囲外です。 PostgreSQLドキュメントSSLによる安全なTCP/IP接続の章に自分で認証する証明書を作成するコマンドの例があります。

rawモードにおけるフェイルオーバ動作について

rawモードにおいて、2台以上のPostgreSQLサーバを指定すると、フェイルオーバが可能です。フェイルオーバでは、正常時にはbackend_hostname0で指定した PostgreSQLのみを使用し、ほかのサーバにはアクセスしません。 backend_hostname0のサーバがダウンすると、次にbackend_hostname1で指定したサーバにアクセスをこころみ、成功すればそれを使用します。以下、 backend_hostname2...でも同様になります。

コネクションプールモード

rawモードに加え、コネクションプーリングが利用できるようになります。設定項目は、rawモードでの設定項目の他に以下を設定します。

max_pool

pgpool-IIの各サーバプロセスがキープするPostgreSQLへの最大コネクション数です。pgpool-IIは、ユーザ名、データベースが同じならばコネクションを再利用しますが、そうでなければ新たにPostgreSQLへのコネクションを確立しようとします。したがって、ここでは想定される[ユーザ名:データベース名]のペアの種類の数だけをmax_poolに指定しておく必要があります。もしmax_poolを使いきってしまった場合は一番古いコネクションを切断し、そのスロットが再利用されます。 max_poolのデフォルト値は4です。なお、pgpool-II全体としては、num_init_children*max_pool 分だけ PostgreSQLへのコネクションが張られる点に注意してください。このパラメータを変更した時には pgpool-II を再起動してください。

connection_life_time

コネクションプール中のコネクションの有効期間を秒単位で指定します。0 を指定すると有効期間は無限になります。connection_life_timeのデフォルト値は0です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

reset_query_list

セッションが終了するときにコネクションを初期化するためのSQLコマンドを「;」で区切って列挙します。デフォルトは以下のようになっていますが、任意のSQL文を追加しても構いません。

   reset_query_list = 'ABORT; DISCARD ALL'

PostgreSQLのバージョンによって使用できるSQLコマンドが違います。各バージョンごとのお勧め設定は以下です(ただし、"ABORT"は必ずコマンドに含めてください)。

PostgreSQLバージョン reset_query_listの推奨設定値

7.1以前 ABORT

7.2から8.2 ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT

8.3以降 ABORT; DISCARD ALL

「ABORT」は、PostgreSQL 7.4以上ではトランザクションブロックの中にいない場合には発行されません。

このパラメータを変更した時には設定ファイルを再読み込みしてください。

コネクションプールモードにおけるフェイルオーバ動作について

rawモードと同様の動作をします。

レプリケーションモード

レプリケーションを有効にするモードです。 rawモード、コネクションプールモードに加え、以下を設定します。

replication_mode

レプリケーションモードで動作させる場合はtrueを指定してください。デフォルト値はfalseです。このパラメータを変更した時には pgpool-II を再起動してください。

load_balance_mode

trueを指定するとレプリケーションモードまたはマスタースレーブモードの際に、SELECT文をロードバランスして検索性能を向上させることができます。デフォルト値はfalseです。このパラメータを変更した時には pgpool-II を再起動してください。

replication_stop_on_mismatch

trueを指定するとマスターDBと他のDBノードの間でデータの不一致があった場合に強制的に縮退運転に入ります。このオプションがfalseの場合は、該当の問い合わせを強制的に終了するだけに留めます。デフォルト値はfalseです。

replicate_select

true を設定するとロードバランスされない SELECT 文をレプリケーションさせます。これは pgpool-II 1.0 までの挙動と同じになります。false を設定すると SELECT 文をマスタのみに送信します。デフォルト値は false です。

replicate_select、load_balance_mode、SELECT問合わせが明示的なトランザクションブロックの内側にあるかどうかどうかで、レプリケーションモードの動作が変化します。詳細を表に示します。

SELECTが明示的なトランザクションブロックの内側にある Y Y Y N N N Y N

replicate_selectがtrue Y Y N N Y Y N N

load_balance_modeがtrue Y N N N Y N Y Y

結果(R:レプリケーション, M: マスタのみに送信、L: ロードバランスされる R R M M L R M L

insert_lock

SERIAL型を使っているテーブルをレプリケーションすると、SERIAL型の列の値がDBノードの間で一致しなくなることがあります。この問題は、該当テーブルを明示的にロックすることで回避できます(もちろんトランザクションの並列実行性は犠牲になりますが)。しかし、そのためには、

   INSERT INTO ...

を

   BEGIN;
   LOCK TABLE ...
   INSERT INTO ...
   COMMIT;

に書き換えなければなりません。insert_lockをtrueにすると自動的にトランザクションの開始、テーブルロック、トランザクションの終了を行ってくれるので、こうした手間を省くことができます（すでにトランザクションが開始されている場合はLOCK TABLE...だけが実行されます）。テーブルでSERIAL型が使われていない場合には、テーブルのロックは行なわれません。なお、あまり必要ないかも知れませんが、コメントを利用して、この挙動を細かく制御することもできます。

insert_lockをtrueにして、INSERT文の先頭に/*NO INSERT LOCK*/コメントを追加する。このコメントがあると、テーブルロックは行われません。
insert_lockをfalseにして、INSERT文の先頭に/*INSERT LOCK*/コメントを追加する。このコメントがあると、このINSERT文に対してのみテーブルロックが行われます。

insert_lockのデフォルト値はtrueです。なお、insert_lockを有効にしてregression testを実行すると、少くとも PostgreSQL 8.0ではtransactions, privileges, rules, alter_tableが failします。ruleでは、viewに対してLOCKをしようとしてしまうこと、ほかのものは

   ! ERROR:  current transaction is aborted, commands ignored until end of transaction block

というようなメッセージが出てしまうためです。たとえば、transactions では、存在しないテーブルに対してINSERTを行うテストが含まれており、 pgpoolが最初に存在しないテーブルに対してLOCKを行う結果、エラーになってトランザクションがアボート状態になり、続くINSERTで上記エラーが出てしまいます。

このパラメータを変更した時には設定ファイルを再読み込みしてください。

recovery_user

オンラインリカバリを行うための PostgreSQL ユーザ名です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

recovery_password

オンラインリカバリを行うための PostgreSQL ユーザパスワードです。このパラメータを変更した時には設定ファイルを再読み込みしてください。

recovery_1st_stage_command

最初にオンラインリカバリ中に起動するコマンド名を指定します。コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にあるコマンドやスクリプトのみを呼び出します。例えば、recovery_1st_stage_command = 'sync-command' と設定してある場合、$PGDATA/sync-command を起動しようとします。 recovery_1st_stage_command を実行している間は pgpool ではクライアントからの接続を制限しません。参照や更新を行うことができます。

このパラメータを変更した時には設定ファイルを再読み込みしてください。

recovery_2nd_stage_command

2 回目のオンラインリカバリ中に起動するコマンド名を指定します。コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にあるコマンドやスクリプトのみを呼び出します。例えば、recovery_2nd_stage_command = 'sync-command' と設定してある場合、$PGDATA/sync-command を起動しようとします。 recovery_2nd_stage_command を実行している間は pgpool ではクライアントから接続、参照、更新処理を一切受け付けません。また、バッチ処理などによって接続しているクライアントが長時間存在している場合にはコマンドを起動しません。新たな接続を制限し、現在の接続数が 0 になった時点でコマンドを起動します。

このパラメータを変更した時には設定ファイルを再読み込みしてください。

recovery_timeout

pgpoolは、オンラインリカバリの際にすべてのクライアントが接続を終了するまで待ちます。 recovery_timeoutでその最大待ち時間を指定します。単位は秒です。待ち時間がrecovery_timeoutを越えると、オンラインリカバリは中止され、通常の状態に戻ります。

アイドル状態のクライアントが自分から切断するのを待ちたくない場合は、client_idle_limit_in_recoveryを利用することもできます。

recovery_timeoutは、この他、オンラインリカバリの最後にリカバリ対象のDBノードでpostmasterを起動する際の待ち時間にも利用されます。

recovery_timeoutのデフォルト値は90秒です。 recovery_timeoutを0としてもタイムアウトが無効になるわけではなく、単に即座にタイムアウトするだけですので注意してください。このパラメータを変更した時には設定ファイルを再読み込みしてください。

client_idle_limit_in_recovery

client_idle_limitと似ていますが、このパラメータはリカバリのセカンドステージでのみ効力があります。前回クライアントから来たクエリから、 client_idle_limit_in_recovery 秒越えても次のクエリが届かない場合は、クライアントへの接続を強制的に切断し、リカバリのセカンドステージの進行が妨害されるのを防ぎます。デフォルト値は 0(無効)です。このパラメータを変更した時には設定ファイルを再読み込みしてください。

lobj_lock_table

ラージオブジェクトのレプリケーションを行いたいときにロック管理に使うためのテーブル名を指定します。このテーブルが指定されていて、ラージオブジェクトの作成要求がクライアントから送信され、かつその要求の中にラージオブジェクトのIDの明示的な指定が含まれていない場合(つまり、lo_creatでラージオブジェクトを作成する場合)、 pgpool-IIは、排他制御のためにこのテーブルをロックした後、ラージオブジェクトを格納するシステムカタログpg_largeobjectのラージオブジェクトに格納されているIDの最大値を取りだし、その値+1のIDを使ってlo_create()を呼び出してラージオブジェクトの作成を行います(lo_create()を持たないバージョン8.1より前のPostgreSQLではこの処理は行われません)。この方法により、すべてのDBノードで同じIDを持つラージオブジェクトが作成されることが保証されます。

このような処理の対象となるラージオブジェクトの操作は、PostgreSQLのC言語用のAPI(libpq)で言うと、lo_creat()です。 2010年2月時点の我々の調査では、以下の言語のラージオブジェクト作成APIは、すべてlo_creat()を呼び出すか、またはlo_creat()と同じ通信プロトコルを使っているので、pgpool-IIの上記の操作の対象になり、ラージオブジェクトのレプリケーションが安全に行われるようになります。

Java(JDBCドライバ)
PHP(pg_lo_create関数、またはPDOなどの該当API)
psqlから\lo_importを呼び出す場合

上記以外であっても、ラージオブジェクトの作成APIでラージオブジェクトのIDを引数として渡すようになっていないものは間違いなくlo_creat()を使っており、pgpool-IIの上記の操作の対象になると考えて良いでしょう。

pgpool-IIの上記処理の対象とならないようなラージオブジェクトの作成処理は以下のものです。

libpqのlo_create()を使用している
C言語以外のAPIで、lo_create()を使用しているもの
バックエンド関数のlo_importをSELECTで呼び出す場合
バックエンド関数のlo_creatをSELECTで呼び出す場合

lobj_lock_tableで指定するテーブルはどのような定義のものでも構いませんが、あらかじめ作成済でかつすべてのユーザが書き込み可能でなければなりません。そのようなテーブルを作る例を示します。

CREATE TABLE public.my_lock_table ();
GRANT ALL ON public.my_lock_table TO PUBLIC;

この操作はpgpool-II経由で接続するすべてのデータベースに対して、あらかじめ実施しておかなければなりません。しかし、この操作をtemplate1データベースに対して一度行っておけば、以後作成されるデータベースにはこのテーブルが含まれるようになるので、管理の手間が省けます。

lobj_lock_tableに指定するテーブル名が空文字の場合は、ラージオブジェクトに関する上記の処理は行いません (したがって、ラージオブジェクトのレプリケーションは保証されません)。 lobj_lock_tableのデフォルト値は空文字です。

ロードバランスの条件について

load_balance_mode = true を設定した場合、以下の条件のすべてを満たした時にSELECTなどの問い合わせがロードバランスされます。

PostgreSQLのバージョンが7.4以降である
問い合わせが明示的なトランクザションブロックの内側にない(つまり、BEGINを発行していない)
SELECT文(WITH付も含む。SELECT nextval と SELECT setval は除く)またはCOPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT... のいずれかである
SELECT INTO 文ではない
SELECT FOR UPDATE/SELECT FOR SHARE文ではない
クエリ文字列が SELECTまたはWITH で始まる(ignore_leading_white_space = trueの場合は空白は無視します)

(replicate_selectの項目も参考にしてください) また、詳細な判定条件をフローチャートにしたものもご覧下さい。なお、

  /*REPLICATION*/ SELECT ...

とすることによって、本来負荷分散されたり、マスタのみに送信されるべき問合わせがすべてのバックエンドに送信される（レプリケーションされる）ようになります。副作用がある関数を含む問合わせに対してはこのテクニックが利用できます。

注意: JDBC ドライバなどのように、ドライバ内で autocommit の有効・無効のオプションがある場合、 autocommit を無効にすると、pgpoolが内部で BEGIN コマンドを実行する関係上、正しくロードバランスされない可能性があります。クエリをロードバランスさせたい場合は autocommit を有効にしてください。たとえばJDBCであれば setAutoCommit(true) を実行してください。

レプリケーションモードにおける縮退運転について

PostgreSQLサーバのうち、1台がダウンすると、そのサーバを切り離して縮退運転に入ります。1台でもサーバが生き残っていれば、システムとしての運用を継続できます。

レプリケーションモード固有のエラーについて

データの整合性を保つために、pgpoolはレプリケーション時に INSERT, UPDATE, DELETE の更新件数がすべてのノードが同じでない場合、意図的に構文エラーを起すSQLを送信することによって、トランザクションをアボートさせます(フェイルオーバは起きません)。以下のような感じになります。

   =# UPDATE t SET a = a + 1;
   ERROR: pgpool detected difference of the number of update tuples
   HINT: check data consistency between master and other db node

マスタースレーブモード

master/slaveモードは、Slony-Iのような、master/slave式のレプリケーションソフトにレプリケーションをまかせるモードです。このモードで使うためには、レプリケーションモードと同じように、DBノードのホスト情報をセットし、master_slave_modeとload_balance_modeをtrueにします。このとき、問い合わせによってマスターDBだけに問い合わせが送られる場合と、DB ノードの間でロードバランスされて問い合わせが送られる場合があります。ロードバランスの条件はレプリケーションモードと同じです。

マスタスレーブモードでは、一時テーブルの作成、更新はマスタノードでのみ実行されます。一時テーブルへの検索は、SELECT文の前に/*NO LOAD BALANCE*/というコメントを書くことによって実行できます。

マスタースレーブモードでは、pgpool.confのreplication_modeをfalseに、master_slave_mode をtrueにします。このパラメータを変更した時には pgpool-II を再起動してください。

パラレルモード

パラレルクエリ機能が利用できるモードです。テーブルを分割させ、各ノードにデータを持たせることができます。またレプリケーションや負荷分散機能も同時に使うことができます。パラレルモードでは、pgpool.confのreplication_modeまたはloadbalance_modeにtrue を設定し、master_slave をfalseにし、parallel_mode をtrueにします。このパラメータを変更した時には pgpool-II を再起動してください。

システムDBの設定

パラレルモードを利用するためには、システムDBを設定する必要があります。システムDBはデータを各PostgreSQLサーバで分割するためのルールを PostgreSQLのテーブルの形で保持します。システムDBはpgpoolが動作するホストと同じホストに置く必要はありません。システムDBの設定はpgpool.confで行います。

system_db_hostname: システムDBが動いているホスト名です。空文字を指定すると、UNIXドメインソケットで接続します。このパラメータを変更した時には pgpool-II を再起動してください。
system_db_port: システムDBのポート番号です。このパラメータを変更した時には pgpool-II を再起動してください。
system_dbname: システムDBは専用のデータベースに設置します。そのデータベース名を指定します。このデータベースはあらかじめ存在しなければなりません。ここでは、 "pgpool"というデータベース名にするものとします。このパラメータを変更した時には pgpool-II を再起動してください。
system_db_schema: システムDBは専用のスキーマに設置します。そのスキーマ名を指定します。このスキーマはあらかじめ存在しなければなりません。ここでは、 "pgpool_catalog"というスキーマにするものとします。このパラメータを変更した時には pgpool-II を再起動してください。
system_db_user: システムDBに接続するときのユーザ名です。このパラメータを変更した時には pgpool-II を再起動してください。
system_db_password: システムDBに接続するときのパスワードです。パスワードを設定していない場合は空文字にしておきます。このパラメータを変更した時には pgpool-II を再起動してください。

システムDBの初期設定

システムDBにスキーマとテーブルを作成します。初期設定用のスクリプトが $prefix/share/system_db.sqlにあるのでそれを利用します。ただし、このスクリプトではスキーマ名が"pgpool_catalog"となっているので、違うスキーマを使う場合は適当に書き換えてください。また、データベース名として"pgpool"以外を使う場合は以下を適当に読み替えてください。

psql -f $prefix/share/system_db.sql pgpool

dblinkのインストール

パラレルモードではdblinkを使います。dblinkはPostgreSQLソースファイル ($POSTGRES_SRC)

$(POSTGRES_SRC)/contrib/dblink

にあります。$POSTGRES_SRC/contrib/dblink/README.dblinkを参考にシステム DBにdblinkをインストールしてください。また、pgpoolデータベースに関数の登録が必要です。

psql pgpool < $POSTGRES_SRC/contrib/dblink/dblink.sql

コネクション数の設定

パラレルモードでは、クエリによりシステムDBからdblink経由でpgpoolに接続するので、想定される同時接続数以上のコネクションが必要になる場合があります。そのため、pgpool.confのnum_init_childrenには同時接続数より十分大きい値を設定して下さい。

目安として以下の式でnum_init_childrenを設定してください。

num_init_children = 想定される同時接続数 * ( 1 + クエリの中で使われているテーブルの最大数)

データ分割ルールの登録

データ分割を行うテーブルに対しては、テーブル情報をあらかじめ pgpool_catalog.dist_def というテーブルに登録しておきます。

CREATE TABLE pgpool_catalog.dist_def(
	dbname TEXT,	-- DB名
	schema_name TEXT,	--schema名
	table_name TEXT,	-- テーブル名
	col_name TEXT NOT NULL CHECK (col_name = ANY (col_list)),	-- 分散キー列名
	col_list TEXT[] NOT NULL,	-- tableの属性名
	type_list TEXT[] NOT NULL,	-- 属性のタイプ名
	dist_def_func TEXT NOT NULL,	-- 分散先のDBノードを決定する関数名
	PRIMARY KEY (dbname,schema_name,table_name)
);

レプリケーションテーブルのルール登録

一つのSQL文にJOIN等でデータ分割ルールに登録したテーブルと共にレプリケーションを行うテーブルを指定する場合には、レプリケーションを行うテーブルの情報をあらかじめ、pgpool_catalog.replicate_def というテーブルに登録しておきます。

CREATE TABLE pgpool_catalog.replicate_def(
	dbname TEXT,	-- DB名
	schema_name TEXT,	--schema名
	table_name TEXT,	-- テーブル名
	col_list TEXT[] NOT NULL,	-- tableの属性名
	type_list TEXT[] NOT NULL,	-- 属性のタイプ名
	PRIMARY KEY (dbname,schema_name,table_name)
);

pgbenchのテーブルを分割するルールの例を示します。

この例では、accountsテーブルに対しては分割を行い、branchesテーブルとtellersテーブルに対してはレプリケーションを行うことにします。また、accountsテーブルとbanchesテーブルはbidで結合されることを想定し branchesテーブルはレプリケーションテーブルのルール登録を行います。もし、accountsテーブル、branchesテーブルとtellersテーブルの３つのテーブルの結合が行われる場合には、あらかじめtellersテーブルに対してもレプリケーションテーブルのルール登録を行う必要があります。　

INSERT INTO pgpool_catalog.dist_def VALUES (
	'pgpool',
	'public',
	'accounts',
	'aid',
	ARRAY['aid','bid','abalance','filler'],
	ARRAY['integer','integer','integer','character(84)'],
	'pgpool_catalog.dist_def_accounts'
);

INSERT INTO pgpool_catalog.replicate_def VALUES (
	'pgpool',
	'public',
	'branches',
	ARRAY['bid','bbalance','filler'],
	ARRAY['integer','integer','character(84)']
);

ここで、pgpool_catalog.dist_def_accountsは、引数として分割キーの値を受け取り、どのPostgreSQLサーバ(「DBノード」と呼びます)を0からの番号で返す関数です。ここでは、3台のDBノードにデータを分割する関数の例を示します。

CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_accounts (val ANYELEMENT) RETURNS INTEGER AS '
  SELECT CASE WHEN $1 >= 1 and $1 <= 30000 THEN 0
	      WHEN $1 > 30000 and $1 <= 60000 THEN 1
	      ELSE 2
  END' LANGUAGE SQL;

クライアント認証(HBA)のための pool_hba.conf 設定方法

PostgreSQLのpg_hba.confと同じようにpgpoolでもpool_config.confファイルを使ったクライアント認証がサポートされています。

pgpoolをインストールするとデフォルトインストール先の設定ファイルディレクトリ"/usr/local/etc"にpool_hba.conf.sampleが一緒にインストールされます。このpool_hba.conf.sampleファイルをpool_hba.confとしてコピーし、必要であれば編集してください。デフォルトではpool_hbaによる認証は有効になっています。

pool_hba.confのフォーマットはpg_hba.confのものとほとんど同じです。

     local      DATABASE  USER  METHOD  [OPTION]
     host       DATABASE  USER  CIDR-ADDRESS  METHOD  [OPTION]

各フィールドで設定できる値の詳細は"pool_hba.conf.sample"を参照してください。

以下はpool_hbaの制限事項です。

"hostssl"接続タイプはサポートされません

現在pgpoolはSSL接続をサポートしていないので"hostssl"は指定することができません。

DATABASEフィールド値として"samegroup"はサポートされません

pgpoolはバックエンドサーバにあるユーザ情報を事前に知る事ができないため、データベース名はpool_hba.confにある値のみと比較されます。なのでグループに関する認証はpool_hbaで行うことができません。

USERフィールド値として"+"を使ったグループ指定はサポートされません

上記の"samegroup"と同じ理由で、ユーザ名はpool_hba.confにある値のみと比較されます。グループに関する認証はpool_hbaで行うことはできません。

IPv6アドレス/マスク表記法はサポートされません

現在pgpoolはIPv6をサポートしていません。

"trust", "reject", "pam"以外のメソッドはサポートされません

これも上記の"samegroup"と同じ理由によるものです。pgpoolはバックエンドのユーザ/パスワード情報を持っていないので、バックエンドに保存されているパスワードを使った認証を行うことができません。

ここで説明された機能、制限はクライアントとpgpool間で行われるクライアント認証についてだということに注意してください。クラインアントは pgpoolのクライアント認証に成功したとしても、PostgreSQLによるクライアント認証に成功しないと接続状態となりません。pool_hbaにとってはクライアントに指定されたユーザ名やデータベース名 (例. psql -U testuser testdb)が実際にバックエンド上に存在するかどうかは問題ではありません。それがpool_hba.confの値とマッチするかどうかでチェックが行われます。

pgpoolが稼働するホスト上のユーザ情報を使ったPAM認証を利用することができます。pgpoolをPAMサポート付きでビルドするにはconfigureオプションに"--with-pam"を指定してください。

     ./configure --with-pam

実際にPAM認証を有効にするには、pool_hba.confで"pam"メソッドを設定するのに加え、pgpoolのサービス設定ファイルをシステムのPAM設定ディレクトリ（通常は /etc/pam.d に作成する必要があります。サービス設定ファイルの例はインストールディレクトリの"share/pgpool.pam"を参考にしてください。

クエリキャッシュの設定方法

pgpool-IIでは、すべてのモードでクエリキャッシュを利用することができます。利用する場合には、pgpool.confの設定を以下のように設定します。

enable_query_cache = true

また、システムDBに以下のテーブルを作成してください。

CREATE TABLE pgpool_catalog.query_cache (
  hash TEXT,
  query TEXT,
  value bytea,
  dbname TEXT,
  create_time TIMESTAMP WITH TIME ZONE,
  PRIMARY KEY(hash, dbname)
);

ただし、この例ではスキーマ名が"pgpool_catalog"となっているので、違うスキーマを使う場合は適当に書き換えてください。

pgpool-IIの起動と停止

以上で設定が終わったので、各DBノードを起動し、必要ならばシステムDBも起動してからpgpool-IIを起動します。

pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-d]

-c クエリキャッシュを消去します

-f config_file pgpool-IIの設定ファイルを指定します

-a hba_file HBA認証設定ファイルを指定します

-F pcp_config_file pcpの設定ファイルを指定します

-n デーモンモードで起動しません(制御端末を切り離しません

-d デバッグモードで起動します

pgpool-IIの停止は後述のpcpコマンドでもできますが、pgpool-IIコマンドを使うこともできます。

pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop

-m s[mart] 接続中のクライアントが接続を終わるのを待ってから停止します(デフォルト)

-m f[ast] 接続中のクライアントが接続を終わるのを待たずに直ちに停止します

-m i[mmediate] -m fと同じ動作です

pgpoolが停止すると、[logdir]/pgpool_statusというファイルにバックエンドの状態を書き込みます。次回pgpoolが起動したときにこのファイルが存在すると、バックエンドの状態をそこから復元します。これによって、

バックエンドが停止してフェイルオーバ
pgpool経由で正常なDBを更新
pgpoolを停止
停止していたDBを再起動
pgpoolを再起動

というシーケンスで、不整合のあるDBからレプリケーション状態に移行することを防ぐことができます。

もしもDBの状態に不整合がなくなっている、あるいはpgpool.confを書き換えて設定を変えてしまった、というときはpgpool_statusを削除すればバックエンドの状態の復元を行いません。

pgpool-IIの設定ファイルの再読み込み

pgpool-IIの設定ファイルは、pgpool-IIを再起動することなく読み直すことができます。

pgpool [-f config_file][-a hba_file][-F pcp_config_file] reload

-f config_file pgpool-IIの設定ファイルを指定します

-a hba_file HBA認証設定ファイルを指定します

-F pcp_config_file pcpの設定ファイルを指定します

設定項目によっては、再読み込みを行なっても反映されないものがあるので、ご注意下さい。また、設定の変更はすでに接続中のセッションには反映されません。次回、クライアントがpgpool-IIに接続したときから反映されます。

オンラインリカバリ

オンラインリカバリ概要

レプリケーションモードで pgpool が動作している場合、ダウンしたノードのデータを再同期させた上で、ノードを復帰させることができます。この機能を「オンラインリカバリ」と呼びます。

オンラインリカバリを実施するためには、ノードが切り離されていると pgpool が検知している必要があります。ノードを動的に追加したい場合には pgpool.conf の backend_hostnameなどのパラメータを追加しておき、設定ファイルを再読み込みさせると、ノードが切り離された状態で pgpool にノード情報が登録されます。

また、リカバリするノードの PostgreSQL がすでに動作中であれば、あらかじめ PostgreSQL をシャットダウンさせておいてください。

pgpool ではオンラインリカバリを 2 段階に分けて実施します。pgpool のクライアントからは完全なデータの同期を取るために若干の接続待ちが発生します。リカバリ手順で以下の通りです。

CHECKPOINT 実行
ファーストステージの実施
接続がすべて切断されるまで待機
CHECKPOINT 実行
セカンドステージの実施
postmaster の起動(pgpool_remote_start の実行)
ノードの復帰

データ同期の第一段階を「ファーストステージ」と呼びます。ファーストステージ中に1 回目のデータ同期を行います。ファーストステージ中はデータの更新や参照を並行して行うことができます。

ファーストステージで処理する内容はユーザが定義することができます。スクリプトでは 3 つの引数を受け取ることができます。

マスタのデータベースクラスタパス
リカバリノードのホスト名
リカバリノードのデータベースクラスタパス

次に 2 回目のデータ同期を行います。これを「セカンドステージ」と呼びます。pgpool ではセカンドステージに入る前に接続中のクライアントがすべて接続が終了されるまで待ちます。その間に接続リクエストが来た場合には、その接続をすべてブロックします。

セカンドステージで処理する内容はユーザが定義することができます。スクリプトでは 3 つの引数を受け取ることができます。

マスタのデータベースクラスタパス
リカバリノードのホスト名
リカバリノードのデータベースクラスタパス

すべての接続が終了されると、ファーストステージ以降に更新されたデータを同期するためのセカンドステージが開始されます。そこで最終的なデータの同期を行います。この間はクライアントからは pgpool への接続が待たされる状態になります。

なお、オンラインリカバリの制限事項として、複数のホストに pgpool を配置してレプリケーションさせている場合には、オンラインリカバリは正しく動作しません。どれかの pgpool にリカバリリクエストを出した時に、他の pgpool から更新が伝搬すると、データを同期させることができなくなります。

pgpool の設定

オンラインリカバリを設定するためには、pgpool.conf の以下の値を設定してください。

backend_data_directory
recovery_user
recovery_password
recovery_1st_stage_command
recovery_2nd_stage_command

C 言語関数のインストール

次に、リカバリを実施するための PostgreSQL の C 言語関数を各ノードの template1 データベースにインストールします。ソースコードは

  pgpool-II-x.x.x/sql/pgpool-recovery/

にあります。ディレクトリを移動し、make install してください。

  % cd pgpool-II-x.x.x/sql/pgpool-recovery/
  % make install

C 言語関数のモジュールをインストールしたら、続いて C 言語関数を呼びだすための SQL をインストールします。

  % cd pgpool-II-x.x.x/sql/pgpool-recovery/
  % psql -f pgpool-recovery.sql template1

リカバリスクリプトの配置

データを同期させるためのスクリプトと、リモートから postmaster を再起動させるためのスクリプトを各ノードの $PGDATA 以下に配置します。あらかじめpgpool-II-x.x.x/sample 以下にサンプルスクリプトも用意してありますので参考にしてください。ここではサンプルスクリプトを使って、PITR によるリカバリ方法と、rsync によるリカバリ方法を説明します。

PITR によるリカバリ

ここでは PostgreSQL の PITR 機能を使ってリカバリをする設定例を説明します。PITR によるリカバリをする場合にはあらかじめ PostgreSQL の設定でログをアーカイブさせるようにしておいてください。

まずファーストステージでベースバックアップを取得し、リカバリ先へコピーするスクリプト(ここではファイル名を copy-base-backup とします)を用意します。例えば以下のようなスクリプトで取得することができます。

  #! /bin/sh

  DATA=$1
  RECOVERY_TARGET=$2
  RECOVERY_DATA=$3

  psql -c "select pg_start_backup('pgpool-recovery')" postgres
  echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" > /data/recovery.conf
  tar -C /data -zcf pgsql.tar.gz pgsql
  psql -c 'select pg_stop_backup()' postgres
  scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA

ベースバックアップ取得時に recovery.conf を生成しておきます。

restore_command = 'scp master:/data/archive_log/%f %p'

セカンドステージでは最新の状態まで PITR によるリカバリを実施できるようにするために、pgpool_recovery_pitr スクリプトを$PGDATA にコピーします。このスクリプトでは XLOG を強制的にスイッチさせるようにします。

#! /bin/sh
# Online recovery 2nd stage script
#
datadir=$1		# master dabatase cluster
DEST=$2			# hostname of the DB node to be recovered
DESTDIR=$3		# database cluster of the DB node to be recovered
port=5432		# PostgreSQL port number

# Force to flush current value of sequences to xlog 
psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
while read i
do
  if [ "$i" != "" ];then
    psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
  fi
done

psql -p $port -c 'SELECT pg_switch_xlog()' postgres

スクリプト中のwhileループは、全データベース中のシーケンス値をトランザクションログに吐き出します。これによって、シーケンスも正しくリカバリされるようになります。

スクリプトの配置が完了したら pgpool.conf に設定します。

recovery_1st_stage_command = 'copy-base-backup'
recovery_2nd_stage_command = 'pgpool_recovery_pitr'

これで PITR によるオンラインリカバリの準備が完了です。

pgpool_remote_start

データ再同期後に postmaster を起動させるスクリプトです。 pgpool からは以下の形式でスクリプトを実行します。

  % pgpool_remote_start remote_host remote_datadir
  remote_host:    リカバリノードのホスト名
  remote_datadir: リカバリノードのデータベースクラスタパス

サンプルスクリプトでは ssh 経由で postmaster を起動しています。こちらもあらかじめパスフレーズ無しで ssh 経由でログインできるように設定しておく必要があります。

PITR によるリカバリであれば、pgpool_remote_start 内でベースバックアップを展開し、recovery.conf の内容にしたがってリカバリした後に postmaster が接続可能状態になります。

#! /bin/sh
DEST=$1
DESTDIR=$2
PGCTL=/usr/local/pgsql/bin/pg_ctl

# Expand a base backup
ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2>/dev/null 1>/dev/null < /dev/null
# Startup PostgreSQL server
ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null < /dev/null &

rsync によるリカバリ

7.4 以前の場合は PITR 機能がありません。そこで PITR を使わずに rsync を使ったリカバリ方法を説明します。sample ディレクトリに pgpool_recovery というファイルがあります。マスタから復帰させるノードへのデータの物理コピーを行うスクリプトです。pgpool からは以下の形式でスクリプトを実行します。

  % pgpool_recovery datadir remote_host remote_datadir
  datadir:        マスタのデータベースクラスタパス
  remote_host:    リカバリノードのホスト名
  remote_datadir: リカバリノードのデータベースクラスタパス

サンプルスクリプトでは rsync を使って物理コピーをしています。もし rsync を使う場合は、パスフレーズ無しで ssh 経由でログインできるようにあらかじめ設定しておく必要があります。

rsyncに関する注記:

-z (or --compress)オプションは低速なネットワークでは効果がありますが、 100M以上の高速なネットワークではかえってCPU負荷を増やし、結果的に遅くなることがあります。高速ネットワークでは、このオプションを使用しないことをお勧めします。
rsync の新しいバージョン(3.0.5)では、50%も性能が良くなったという報告が pgpool-generalメーリングリストでありました。

pgpool_recovery を使う場合は pgpool.conf に以下の行を追加してください。

recovery_1st_stage_command = 'pgpool_recovery'
recovery_2nd_stage_command = 'pgpool_recovery'

リカバリの実行

以上でオンラインリカバリの準備が整いました。オンラインリカバリを実行するには pcp_recovery_node コマンドを使うか、 pgpool 管理ツールから実行してください。

注意点として、pcp_recovery_node を実行する際に、タイムアウトを長くしてください。pgpoolAdmin から実行する場合は pgmgt.conf.php 内の _PGPOOL2_PCP_TIMEOUT を大きくしてください。

制限事項

認証・アクセス制御方式

レプリケーションモードまたマスタ/スレーブモード時にはtrust, reject, clear text password, pam, 認証方式だけが利用できます。md5認証、crypt認証などの認証方式は利用できません。
それ以外のモードでは、trust, reject, clear text password, pam, crypt, md5認証方式だけが利用できます。

レプリケーションモードで注意が必要な関数など

pgpool-IIでは同じ問い合わせを送っても異なる結果を返すようなデータ、たとえば乱数やトランザクションID、OIDのようなものに関してはレプリケーションはしますが、2台のホストでまったく同じ値がコピーされる保証はありません。

シリアル型に関しては、insert_lockを有効にしておけばテーブルロックを利用して同期が取られます。シーケンスを扱う関数をSELECT setval()、SELECT nextval()で呼び出している場合は自動的にレプリケーションされるので同期が取れます。

pgpool-II 2.3以降では、テーブルのデフォルト値での利用も含め、CURRENT_TIMESTAMP, CURRENT_DATE, now()は、自動的にマスタ側から取得した時刻値に置き換えることによってレプリケーションできるようになっています。ただし、以下の点に注意してください。

DEFAULTにタイムスタンプを返す式が含まれているかどうかの判定は正確ではありません。例えば
```
CREATE TABLE rel1(
  d1 date DEFAULT CURRENT_DATE + 1
)
```
のようなものも現在のタイムスタンプとして書き換えを行います。

INSERT ... SELECTでは、列のDEFAULTに対する書き換えを行いません。例えば、

CREATE TABLE rel1(
  c1 int,
  c2 timestamp default now()
)

の時、

INSERT INTO rel1(c1) VALUES(1)

は

INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')

のように書き換えられますが

INSERT INTO rel1(c1) SELECT 1

は書き換えられません。

PostgreSQL 8.2かそれより前のPostgreSQLをお使いの場合、 CREATE TEMP TABLEで作成されたテーブルはフロントエンドがセッションを終了しても削除されません。これは、コネクションプールの効果でバックエンドから見るとセッションが継続しているように見えるからです。セッションの終了時に明示的にDROP TABLEするか、トランザクションブロックの中でCREATE TEMP TABLE ... ON COMMIT DROPをお使い下さい。

PostgreSQL 8.3以降では、reset_query_listにDISCARD ALLを指定すれば自動的に削除されるので問題ありません。

クエリについて

pgpool-II では扱うことができないクエリについて説明します。

マルチバイト文字について

制限対象:全モード

現在の実装では、マルチバイト文字の変換処理を行いません。クライアントエンコーディング、バックエンドノードのサーバエンコーディング、システム DB のサーバエンコーディングを一致させるようにしてください。

マルチステートメント

制限対象:全モード

マルチステートメント(';' で区切って複数の文をまとめた SQL)を pgpool が正しく処理することができません。必ず文を分けて送信してください。

なお、psql を使って pgpool に接続した場合は、psql 内部でマルチステートメントを分解し、1 つずつ送信します。

拡張問い合わせプロトコル

制限対象:パラレルモード

JDBC ドライバなどのような拡張問い合わせプロトコルには対応していません。必ず簡易問い合わせプロトコルを使用してください。

SELECT

制限対象:パラレルモード

postgresql.conf の add_missing_from設定値を off (デフォルト値)に設定してください。 add_missing_from 設定値が on の時に使えるクエリは正しくpgpoolで処理されない可能性があります。

INSERT

制限対象:パラレルモード

データ分割をしているテーブルに対してINSERT を行う際には、分割ルールとなる値を DEFAULT にはできません。例えばテーブル t に x というカラムがあり、x が分割ルールの対象カラムだった場合には、

  INSERT INTO t(x) VALUES (DEFAULT);

はできません。また、分割ルールとなる値が関数呼び出しの場合も対応していません。

  INSERT INTO t(x) VALUES (func());

必ず明示的に値を与える必要があります。また、SELECT INTO や INSERT INTO ... SELECT という形式もサポートしていません。

UPDATE

制限対象:パラレルモード

分割ルールとなるカラムを更新すると分割ルールに従ったデータの整合性が崩れる可能性があります。pgpool-II では特にデータの再配置ということは行いません。

もし制約違反などにより一部のノードでエラーになった場合にロールバックすることはできません。

WHERE 句にデータ分割を行ったテーブルを参照するサブクエリや関数呼び出しがある場合には正しく動かない可能性があります。

例：UPDATE branches set bid = 100 where bid = (select max(bid) from beances);

SELECT ... FOR UPDATE

制限対象:パラレルモード

WHERE 句にデータ分割を行ったテーブルを参照するサブクエリや関数呼び出しがある場合には正しく動かない可能性があります。

例：SELECT * FROM  branches where bid = (select max(bid) from beances) FOR UPDATE;

COPY

制限対象:パラレルモード

COPY BINARY には対応していません。また、ファイルからのコピーにも対応していません。COPY FROM STDIN と COPY TO STDOUT のみ対応しています。

ALTER/CREATE TABLE について

制限対象:パラレルモード

pgpool に情報を更新させるためには、pgpool を再起動する必要があります。

トランザクション

制限対象:パラレルモード

トランザクション中に発行される SELECT は dblink を経由する場合には別トランザクションになります。以下に例を示します。

  BEGIN;
  INSERT INTO t(a) VALUES (1);
  SELECT * FROM t ORDER BY a; <-- 上の INSERT した値は見えない
  END;

また制約違反などにより一部のノードでエラーになった場合にロールバックすることはできません。

View/Rule

制限対象:パラレルモード

View や Rule は各ノードに同じ内容が定義されます。

  CREATE VIEW sample AS SELECT * FROM a, b where a.i = b.i

上記のようなテーブル結合を含んだVIEWは、a と b は同じノード内でのみ結合処理を行い、各ノードからの実行結果を統合します。ノードをまたがった JOIN を行う View を作成することはできません。Rule についても同様になります。ただし、データ分割したテーブルを同じノード内でのみ結合したい場合に、VIEWを作成することは可能です。この場合にはVIEWを pgpool_catalog.dist_defテーブルにVIEWを登録しておきます。また、pgpool_catalog.dist_defテーブルのcol_nameとdist_def_funcには、VIEWで定義したカラムとVIEWに対してINSERTが発行された場合に何処のノードにクエリを問い合わせるのかを決定する関数を登録してください。

関数/トリガについて

制限対象:パラレルモード

関数は各ノードに同じ内容が定義されます。関数内で JOIN や他のノードのデータ操作を行うことはできません。

Natural Join について

制限対象:パラレルモード

Natural Join は利用できません。ON 結合条件または、USING(結合カラム) を明示的に指定する必要があります。

USING 句について

制限対象:パラレルモード

JOIN 構文の中で利用される USING 句はクエリの書き換え処理によって ON 句に変換されます。そのため、ターゲットリストに "*" を利用する問い合わせを行う場合には、同じ列名が出力されます。

デッドロックについて

制限対象:パラレルモード

ノード間をまたがるデッドロックを検出することができません。

例：accountsテーブルは以下のルールで分割されている。
    aid <= 100000 ノード 0
    aid >= 100000 ノード 1

  A) BEGIN;
  B) BEGIN;
  A) SELECT * FROM accounts WHERE aid = 100001 FOR UPDATE;
  B) SELECT * FROM accounts WHERE aid = 100000 FOR UPDATE;
  A) SELECT * FROM accounts WHERE aid = 100000 FOR UPDATE;
  B) SELECT * FROM accounts WHERE aid = 100001 FOR UPDATE;

この場合、単一のノードではデッドロックを検知できないため、pgpool は待たされた状態になります。この現象は SELECT FOR UPDATE 以外にも行ロックを獲得するクエリで発生する可能性があります。

また、あるノードでデッドロックが発生した場合は、各ノードのトランザクションの状態が異なる状況になります。そのため、デッドロックを検知した時点で以下のログを出力して pgpool は該当のプロセスを終了させます。

  pool_read_kind: kind does not match between master(84) slot[1] (69)

スキーマについて

制限対象:パラレルモード

public 以外のスキーマに属すようなオブジェクトの参照は必ず

  スキーマ.オブジェクト

と指定するようにしてください。

  set search_path = xxx

を指定し、スキーマ名を省略すると、pgpool がどの分散ルールを適用するか判断できません。

テーブル名、カラム名について

制限対象:パラレルモード

pool_で始まるテーブル、カラム名は使えません。クエリ書き換えの際に内部処理で使用します。

システム DB

分割ルール

pgpool-II では分割ルールの対象のカラムは 1 つのみとします。x と y の OR 条件などといったものには対応していません。

ビルドに必要な環境

libpq

pgpool-II では libpq をリンクします。libpq のバージョンは 2.0 の場合、 configure に失敗します。必ず libpq 3.0 (PostgreSQL 7.4) をリンクするようにしてください。また、SystemDB のバージョンも PostgreSQL 7.4 以降が必須になります。

クエリキャッシュ

現在のクエリキャッシュの実装では、キャッシュの無効化を手動で行う必要があります。

リファレンス

PCPコマンドリファレンス

PCPコマンド一覧

pgpool-IIを操作するUNIXコマンドとして、以下のものがあります。

   * pcp_node_count	- ノード数を取得する
   * pcp_node_info	- ノード情報を取得する
   * pcp_proc_count	- プロセス一覧を取得する
   * pcp_proc_info	- プロセス情報を取得する
   * pcp_systemdb_info	- システムDB情報を取得する
   * pcp_detach_node	- ノードを切り離す
   * pcp_attach_node	- ノードを復帰させる
   * pcp_stop_pgpool	- pgpool-IIを停止させる
   * pcp_recovery_node  - マスタノードを使ってノードのデータを再同期、ノード起動させる

共通引数

全てのコマンドには共通する引数があります。これは接続するpgpool-IIの情報や認証情報などです。

   ex)
   $ pcp_node_count [-d] 10 localhost 9898 postgres hogehoge

    第一引数    - タイムアウト値
		秒数でタイムアウト値を指定します。この時間内にpgpool-IIから応
		答がない場合はコネクションを切断して終了します。なお、
		このオプションは 2.1 からは無視するようになっています。
    第二引数	- pgpool-IIが稼動しているホスト名
    第三引数	- pgpool-IIが受け付けているポート番号
    第四引数	- PCPユーザ名
    第五引数	- PCPパスワード

	オプション引数として、-dがあります。-dが指定されるとデバッグ情報を出力します。

PCPユーザ名とパスワードは ./configure 時に --prefix で指定した 'インストールディレクトリ/etc' にある pcp.conf 内に記述されているものを指定します。pcp.conf ファイルの場所がデフォルト以外の場所にある場合、pgpool の -F オプションでその位置を指定することができます。パスワードはコマンドに渡す時点でmd5化されている必要はありません。

コマンド群

全てのコマンドは、実行した結果が標準出力に表示されます。

pcp_node_count

   書式：
	pcp_node_count  _timeout_  _host_  _port_  _userid_  _passwd_

pgpool-IIの pgpool.conf で定義されたノードの総数を表示します。切り離されているノードの区別はしません。

pcp_node_info

   書式：
	pcp_node_info  _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_

pgpool-IIの pgpool.conf で定義されたノードの情報を表示します。出力結果は以下の例の通りです。

   ex)
   $ pcp_node_info 10 localhost 9898 postgres hogehoge 0
   host1 5432 1 1073741823.500000

   結果は以下の順の通りです。
   1. ノードのホスト名
   2. ノードのポート番号
   3. ステータス
   4. ロードバランスウェイト

   ステータスは[0..3]までの数字で表わされます。各数字の意味は：
   0 - 初期化時のみに表われる。PCPコマンドで表示されることはない。
   1 - ノード稼働中。接続無し
   2 - ノード稼働中。接続有り
   3 - ノードダウン

ロードバランスウェイトはNormalizeされたフォーマットで出力されます。

定義されていないノードIDを指定するとBackendErrorと表示され、終了コード12で終了します。

pcp_proc_count

   書式：
	pcp_proc_count  _timeout_  _host_  _port_  _userid_  _passwd_

pgpool-IIの子プロセスのプロセスIDを一覧表示します。複数ある場合は空白文字で区切られます。

pcp_proc_info

   書式：
	pcp_proc_info  _timeout_  _host_  _port_  _userid_  _passwd_  _processid_

pgpool-IIの子プロセス情報を表示します。出力結果は以下の例の通りです。

   ex)
   $ pcp_proc_info 10 localhost 9898 postgres hogehoge 3815
   postgres_db postgres 1150769932 1150767351 3 0 1

   結果は以下の順の通りです。
   1. 接続しているデータベース名
   2. 接続しているユーザ名
   3. プロセススタート時刻
   4. コネクション作成時刻
   5. プロトコルメジャーバージョン
   6. プロトコルマイナーバージョン
   7. コネクション使用回数

   コネクションがバックエンドに対して張られていない場合、データは表示されません。
   コネクション情報が複数ある場合、複数行に1行1コネクション情報で表示されます。
   時刻はEPOCHタイムからの秒数で表わされます。

   定義されていないプロセスIDを指定するとBackendErrorと表示され、終了コード12で
   終了します。

pcp_systemdb_info

   書式：
	pcp_systemdb_info  _timeout_  _host_  _port_  _userid_  _passwd_

   pgpool-IIのシステムDB情報を表示します。出力結果は以下の通りです。

   $ pcp_systemdb_info 10 localhost 9898 postgres hogehoge
   localhost 5432 yamaguti '' pgpool_catalog pgpool 3
   yamaguti public accounts aid 4 aid bid abalance filler integer integer integer character(84) dist_def_accounts
   yamaguti public branches bid 3 bid bbalance filler integer integer character(84) dist_def_branches
   yamaguti public tellers bid 4 tid bid tbalance filler integer integer integer character(84) dist_def_tellers

   まず一行目にシステムDBの情報が表示されます。結果は以下の順の通りです。

   1. ホスト名
   2. ポート番号
   3. ユーザ名
   4. パスワード。空の場合は''で表示されます。
   5. スキーマ名
   6. データベース名
   7. 分散定義関数の数

   二行目以降は分散定義が表示されます。複数の定義がある場合は、一つの定義につき
   一行表示されます。結果は以下の順の通りです。

   1. 分散対象のデータベース名
   2. 分散対象のスキーマ名
   3. 分散対象のテーブル名
   4. 分散キーカラム名
   5. 分散対象テーブル中のカラム数
   6. カラム名リスト(5.のカラム数分表示されます)
   7. カラム型リスト(5.のカラム数分表示されます)
   8. 分散定義関数名

   システムDBが定義されていない(pgpool-IIモードでない、かつクエリキャッシュがオ
   フの)場合に実行すると、BackendErrorと表示され、終了コード12で終了します。

pcp_detach_node

   書式：
	pcp_detach_node  _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_

   pgpool-IIのノードを切り離します。

pcp_attach_node

   書式：
	pcp_attach_node  _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_

   pgpool-IIのノードを復帰させます。

pcp_stop_pgpool

   書式：
	pcp_stop_pgpool  _timeout_  _host_  _port_  _userid_  _passwd_  _mode_

   pgpool-IIを指定されたモードでシャットダウンします。指定できるモードは以下の通
   りです。

   s	- smart モード
   f	- fast モード   
   i	- immediate モード

   pgpool-IIが起動していない場合はConnectionErrorと表示され、終了コード8で終了し
   ます。

   ※ 現在は fast モードと immediate シャットダウンの処理に区別はあり
      ません。命令を送った時点でクライアントがいる・いないに関わらず
      シャットダウン処理を即座に行います。

pcp_recovery_node

   書式：
	pcp_recovery_node  _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_

   pgpool-IIのノードをデータを再同期させた上で復帰させます。

終了ステータス

PCPコマンドは正常に処理を終了した場合、ステータス'0'で終了します。エラーが起きた場合は以下のステータスにより終了します。

   UNKNOWNERR	1	不明なエラー
   EOFERR	2	EOFエラー
   NOMEMERR	3	メモリ不足
   READERR	4	サーバからのデータ読み込みエラー
   WRITEERR	5	サーバへのデータ書き込みエラー
   TIMEOUTERR	6	タイムアウト
   INVALERR	7	PCPコマンドへの不正なオプション
   CONNERR	8	サーバ接続エラー
   NOCONNERR	9	接続が存在しない
   SOCKERR	10	ソケットエラー
   HOSTERR	11	ホスト名解決エラー
   BACKENDERR	12	サーバでのPCP処理エラー。存在しないプロセスIDの情報を取
			得しようとした場合など
   AUTHERR	13	認証エラー

内部情報

pgpool-IIバージョン 2.0 以降では、1.x バージョンと比べ大幅な改良が加えられています。 1.x バージョンの情報とは互換性がないので注意してください。

パラレル実行エンジン

pgpool-IIにはパラレル実行エンジンが組み込まれています。

このエンジンは、パラレルモードのときに、各ノードに同じクエリを問い合わせ、ノードの応答順に結果をフロントエンドに送信するエンジンのことを指します。

クエリ書き換え

パラレルモードでpgpool-IIが行うクエリ書き換えについて説明します。

パラレルモードでは、クライアントが送信した検索系(SELECT処理)の問い合わせは、大きく分けて以下の 2 つの処理を行います。

クエリの解析
クエリの書き換え

これら２つの処理について順に説明致します。

クエリの解析

はじめに

クライアントが送信した検索系の問い合わせは、SQLパーサを通してからシステムDBに登録されている情報をもとにクエリ解析を行います。クエリの解析には実行ステータスの遷移で評価しています。ここで実行ステータスというのは、あるデータの集合が何処で取得または処理できるのか判断するものです。例えば、pgpool_catalog.dist_defテーブルに登録されているテーブルのデータ集合全体は、データが分割されているのですべてのノードから取得する必要があります。逆に、pgpool_catalog.replicate_defテーブルに登録されているテーブルのデータ集合全体は、すべてのノードから取得するのではなく、いずれかのノードから取得すれば十分です。ここですべてのノードで処理する必要がある状態を P 状態、一つのノードで処理する必要がある状態を L 状態として定義します。もう一つ、特別な状態として S 状態があります。これは、すべてのノードから取得した全データに対して処理を行ったときの状態のことを示します。例えば、ソート処理です。pgpool_catalog.dist_defテーブルに登録されているテーブルのデータに対するソート処理は、すべてのノードからデータを取得した後に実行する必要があります。

検索系クエリは、以下の処理順に解析され、実行ステータスが遷移していきます。実行ステータスが遷移していく過程で S 状態となると、以降の処理は必ず S 状態となります。そして最後のSELECTの最終実行ステータスの状態により、何処のDBで処理されるかが決定します。

UNION、EXTRACT、INTERCECTが利用されているかどうか
FROM 句の実行ステータス
TARGETLIST による実行ステータスの変化
WHERE 句にる実行ステータスの変化
GROUP BY 句による実行ステータスの変化
HAVING 句による実行ステータスの変化
ORDER BY 句による実行ステータスの変化
LIMIT OFFSET 述語に実行ステータスの変化
SELECTの最終実行ステータスの取得

SELECTの最終実行ステータスと処理される場所との関係は、以下の通りです。

実行ステータス処理される場所

L いずれかのノードに問い合わせを行う

P すべてのノード同じ問い合わせを行い、パラレル実行エンジンを通してクライアントに返却

S システムDBで処理を行った後にクライアントに返却

またサブクエリに対しても上記のルールが適応されます。以下の単純なクエリでは、p1-tableがシステムDBのpgpool_catalog.dist_defテーブルに登録されている場合、つまりデータの分割が行われている場合には、サブクエリの最終実行ステータスが P となり、その結果サブクエリの呼び出し元である SELECT の実行ステータスも P となります。

	SELECT * FROM (SELECT * FROM P1-table) as P2-table;

次に具体的に実行ステータスがどのように遷移するのか説明します。まず2. From句の実行ステータスから説明します。

FROM 句の実行ステータス

検索系クエリ(SELECT)は FROM 句によりデータの集合を定義します。FROM句から構成せれるデータ集合は P 状態, L 状態、または S 状態を取ります。FROM句に指定しているテーブルが一つの場合には、単純にテーブルの実行ステータスが FROM句から構成されるデータ集合全体の実行ステータスとなります。FROM句に複数のテーブル、又はサブクエリがある場合には、結合方法によって以下のように実行ステータスが決定します。

結合方式 LEFT OUTER JOIN RIGHT OUTER JOIN FULL OUTER JOIN 　　　その他　　　

左＼右 P L S P L S P L S P L S

P S P S S S S S S S S P S

L S L S P L S S L S P L S

S S S S S S S S S S S S S

以下の例では、P1-tableが P 状態のテーブルでL1-table,L2-tableが L 状態のテーブルだとします。すると上記の表により、P1-table (左)とL1-table (右) が結合し P 状態となり、さらに P 状態と L 状態のL2-tableが結合してFROM句の実行ステータスは P 状態となります。

	SELECT * FROM P1-table,L1-table,L2-table;

TARGETLIST と WHERE句の実行ステータス

基本的なクエリでは、FROM 句と同じ実行ステータスを継承します。しかし、TARGETLIST と WHERE句の実行ステータスは、以下の場合に変化します。

サブクエリがある場合
FROM句が P 状態の場合、かつ、TARGETLISTに集約関数、DISTINCTがある場合
FROM句で定義したテーブル(データ集合)に存在しないカラムが使われている場合

サブクエリの最終実行ステータスが P 状態、または、S 状態の場合には、TARGETLIST、WHERE句の実行ステータスは、S 状態となります。下記の例では、サブクエリで使われているテーブルが、P 状態の場合には、サブクエリの最終実行ステータスは P 状態となります。そのため L1-tableの実行ステータスに依存せずに、WHERE句の実行ステータスは S状態となり、このクエリの実行場所はシステムDBとなります。

	SELECT * FROM L1-table where L1-table.column IN (SELECT * FROM P1-table);

FROM 句が P 状態の場合、かつ、TARGETLISTに集約関数がある場合は、データを取得後に集計する必要があるため、S状態に遷移します。また、特定の条件の下では、集約関数による最適化が行われます。

FROM句で定義したテーブル、サブクエリには存在しないカラムがWHERE句に使われている場合があります。これは以下のような相関サブクエリ内で発生します。

	SELECT * FROM L1-table FROM L1-table.col1 IN (SELECT * FROM P1-table WHERE P1-table.col = L1-table.col1);

上記のサブクエリに使われている L1-table.col1は、L1-tableを外部参照しています。この場合にサブクエリのWHERE句の実行ステータスは S 状態となります。

GROUP BY 句、HAVING 句、ORDER BY 句、LIMIT OFFSET 述語の実行ステータス

WHERE句の実行ステータスが P 状態の場合に、GROUP BY , HAVING 句、ORDER BY 句、LIMIT OFFSET 述語があるとS状態に遷移します。 GROUP BY句が存在しないクエリはWHERE句の実行ステータスを継承します。また、HAVING句が無い場合にはGROUP BY 句の実行ステータスを継承します。 ORDER BY 句、LIMIT OFFSET 述語も同様です。

UNION、EXTRACT、INTERSECTが使われている場合

UNION、EXTRAT、INTERSECTが使っているクエリは左側のSELECT文と右側のSELECT文の最終実行ステータスに依存します。左側と右側のSELECT文の最終実行ステータスが共に L 状態の時には、L 状態となります。また、左側と右側のSELECT文の最終実行ステータスが共に P 状態、かつUNION ALLの場合には P 状態となります。その他の組み合わせの場合には、S状態となります。

SELECTの最終実行ステータスの取得

実行ステータスがすべて L 状態の場合にはL状態、すべて P 状態の場合には、P 状態となります。それ以外は、S 状態となります。 L 状態の場合には、pgpool.confのloadbalance_modeがtrueの場合には負荷分散され、それ以外の場合にはMASTERに問い合わせを行います。また、P 状態の場合には、パラレル実行エンジンを使って並列処理が行われます。S 状態の場合には、次のフェーズであるクエリ書き換えを行います。

クエリ書き換え

クエリの解析フェーズで取得した実行ステータスを使ってクエリの書き換えを行います。例として P 状態の P1-table と L 状態の L1-table を使ったクエリで説明します

	SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col order by P1-table.col;

このクエリでは ORDER BY 句があるため S 状態となり、FROM句、WHERE句、TARGETLISTは P 状態となります。このようなクエリでは以下のように書き換えられます。

	SELECT P1-table.col, L1-table.col FROM
	　　　dblink(select pool_parallel(SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col)) 
  	order by P1-table.col;

ここでdblinkはpgpool-IIに問い合わせを送信します。また、pool_parallelは引数のクエリをパラレル実行エンジンをにわたす関数です。なお、上記はあくまでイメージであり実際に実行可能なクエリではありません。

上記の例のように、FROM句、WHERE句、TARGETLISTがすべて P 状態の場合には、FROM句、WHERE句、TARGETLISTをまとめて並列処理を行います。

次の例を見てみます。

	SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND L1-table.col IN (SELECT P1-table FROM P1-table) ;

この例では、FROM 句は L 状態、TARGETLISTも L 状態、WHERE句は P 状態のサブクエリを持っているため S 状態となります。これは以下のように書き換えが行われます。

	SELECT L1-table.col FROM dblink(SELECT loadbalance(SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND TRUE))
		WHERE
			L1-table.col %2 = 0 AND 
		  L1-table.col IN 
		  (
		  	SELECT P1-Table FROM 
		  	dblink(select pool_parallel(SELECT P1-table FROM P1-table))
		  ) ;

ここで、pool_loadbalanceはクエリをいずれかのノードに送信する関数です。

集約によるクエリ書き換え

集計を行うクエリ(集約関数、GROUP BY )は各ノードに計算させ、システムDBで再集計を行うことにより、システムDBの負荷を減らしパフォーマンスも向上します。

まず、最初にpgpool-IIが実際に行うクエリの書き換えを見てみます。

FROM 句が P 状態で count(*) を使ったクエリは、以下のように書き換えが行われます。

    select count(*) from P1-table;

    -> クエリ書き換え

    SELECT 
        sum(pool_c$1) as count 
    FROM 
        dblink(select pool_parallel('select count(*) from  P1-table'))
					AS pool_$1g (pool_c$1 bigint);

各ノードでcount(*) を計算した後に、システムDBで集計(sum)をすることにより、目的が達成できます。

上記のようなクエリ書き換えが行われる条件は以下の場合です。

FROM 句がP 状態
ターゲットリストに集約関数(count, sum, min, max,avgのみ対応),GROUP BYに指定したカラムが使われている
WHERE 句がP 状態
HAVING 句に使われている集約関数(count, sum, min, max,avgのみ対応),FROM句で定義されているカラム,GROUP BYに指定したカラムのみ使われている。

  例)
     select P1-table.col,L1-table.col,count(*),avg(P1-table.col) from P1-table,L1-table wehre P1-table.col %2 = 0 group by P1-table.col,L1-table.coli having count(*) < 100

パラレルモードの注意事項

パラレルモードでは、クエリの解析の際にカラム名とタイプが必要になります。そのため、サブクエリのTARGETLISTに式、関数を使っている場合には別名と型名をキャストでつける必要があります。式、関数に型のキャストがない場合には、text型として処理されますので注意してください。なお、集約関数の場合でかつ集約によるクエリ書き換えが行われる場合には、countはbigint型、sumはnumeric型となります。min,maxの場合には、引数が日付型の場合には日付型として計算され、それ以外はnumericとして計算されます。avgはsum/countとして処理されます。

パラレルモードのパフォーマンスについて

SELECTの最終実行ステータスとパフォーマンスのおおよその目安は以下のとおりです。

実行ステータスパフォーマンス

L パラレルクエリを利用しないのでpgpool-IIのオーバーヘッドを除き、単体ノードとの性能劣化はない

P 並列処理を行うので高速、特にシーケンシャルスキャンの場合には効果がでる。また、データを分割することでテーブルサイズ(/1台)が小さくなることによりキャッシュに乗りやすくなる

S 集約によるクエリ書き換えが行われると高速

チュートリアル

pgpool-IIのチュートリアルはここにあります。是非ご覧下さい。

リリースノート

2.3.3 (tomiteboshi) 2010/04/23

このバージョンでは、2.3.2.2 以前の色々なバグが修正されています。

互換性のない変更

このバージョンから、pgpool が以前より多くの共有メモリを使うようになったので注意してください。これによる問題が pgpool の起動時に発生した場合は、pgpool のログを見てください。 "could not create shared memory segment: Cannot allocate memory" といったメッセージがあれば、システムの共有メモリを増やしてください。
パラレルモードが、レプリケーションモードかロードバランスモードが有効でないと使えないようになりました。 pgpool-II ではずっと、レプリケーションモードかロードバランスモードが有効でないときパラレルモードは正しく動作していませんでした。(Kitagawa)
insert_lock のデフォルト値を false に変更しました。これは、マスタ・スレーブモードでは true にしても無意味なためです。 Fujii Masao さんの指摘により修正しました。(Tatsuo)

新しく追加したドキュメント

README.online-recovery を追加しました。このドキュメントには、オンラインリカバリの内部的なことが書いてあります。

バグ修正

子プロセスが segfault を起こす pgpool-II 1.0 から長い間存在したバグを修正しました。これは、親プロセスが shmem サイズの計算を間違えていたことに起因します。バグ解析(Kitagawa)、パッチ作成(Tatsuo)
ドキュメントにパラレルモード用の以下の制約を追記しました。(Kitagawa)
- - NATURAL JOIN は使えません。
- - USING 句が、クエリ書き換え処理によって ON 句に変換されます。
パラレルモードのとき、USING 句を含む JOIN 構文の書き換えで発生する可能性があったクラッシュを修正しました。(Kitagawa)
この修正により、以下のような JOIN 構文が使えるようになります。
例：
```
SELECT * FROM a JOIN b USING (aid) JOIN c USING (cid);
SELECT * FROM a JOIN b USING (aid) JOIN c USING (cid) JOIN d USING
```
パラレルクエリで、分散キー列の前に current_time を含む INSERT 文のパースができるように修正しました。
SimpleForwardToBackend() を修正しました。これにより、拡張プロトコルを使ったクライアントが bind エラーのようなエラーを発生させたときに、 pgpool がバックエンドの応答を待ち続けなくなります。このバグは、マスタ・スレーブモード、raw モード、コネクションプールモードで発生していました。これを修正したことによって、コマンドがエラーになったあと、エラーを回復させるために SYNC メッセージを送るようになります。(Kitagawa)
select() を実行中の pgpool 子プロセスが、SIGINT/SIGQUIT シグナルを無視するように修正しました。シグナルが送られても pgpool は select() を再実行しようとするので、結果的にシグナルが無視されます。(Tatsuo)
connect_inet_domain_socket_by_port/connect_unix_domain_socket_by_port が SIGTERM/SIGINT/SIGQUIT シグナルを受け取っていないかチェックするように修正しました。 Daniel Codina さんからのバグ報告に基づきます。(Tatsuo)
"kind mismatch" というエラーメッセージを生成する際にクラッシュする可能性があったので、これを修正しました。以前は問題なかったのですが、2.3.2でエンバグしました。(Tatsuo)
ヘルスチェックにおけるバグを修正しました。コードが抜けたなどでネットワーク障害が発生したときに、connect() を呼んでいる間はヘルスチェックが行なわれていませんでした。これは、connect() が ALARM シグナルによって割り込まれた際に、connect_unix_domain_socket()/connect_inet_domain_socket() が再試行していたためです。この修正では、上記の関数に対して再試行をコントロールするような引数を追加しています。これは、Daniel Codina さんのバグ報告と分析に基づく修正です。(Tatsuo)
2.3.2.2 で、SimpleForwardToBackend でのタイムスタンプの書き換えにおいてエンバグしていたので、これを修正しました。これは、バグトラック #1010771 にある Peter Pramberge さんらの報告に基づきます。(Tatsuo)
パラレルクエリにおける "*" の書き換えを修正しました。sho さんから提供いただいたパッチを取り込みました。(Kitagawa)
connect_inet_domain_socket_by_port() でエラーメッセージを出力する際に、 strerror() ではなく hstrerror() を使うように修正しました。 (Tatsuo)

2.3.2.2 (tomiteboshi) 2010/02/22

概要

このバージョンでは、2.3.xにおける様々なバグを修正しています。とくにタイムスタンプの書き換え時のクラッシュを含む致命的なバグが修正されているので、すべての2.3ユーザは早急にアップグレードすることをお勧めします。

バグ修正

タイムスタンプデータを含む拡張プロトコル問い合わせで、"message: invalid string in message"のエラーを出してトランザクションが終了してしまうバグを修正しました(Tatsuo)
タイムスタンプデータを含む拡張プロトコル問い合わせで、bind時にNULLを含むパラメータが存在するとpgpoolがクラッシュするバグを修正しました(Tatsuo)
pgpool_status上ですべてのノードがダウンのときにはこれを無効とし、「all node down症候群」が起きないようにしました(Tatsuo)

2.3.2.1 (tomiteboshi) 2010/02/11

概要

このバージョンでは、2.3.xにおいて、エラーとなるようなSQLを実行するとpgpoolへのセッションが切断されるバグを修正しています(Akio Ishida)。

2.3.2 (tomiteboshi) 2010/02/07

概要

このバージョンでは、2.3.1の色々なバグが修正されています。特に、タイムスタンプの書き換え機能のバグが修正されているので、2.3, 2.3.1ユーザはなるべく早く2.3.2にアップグレードすることをお勧めします。

また、2.3.2ではSSLサポート、ラージオブジェクトのレプリケーション機能が追加されています。

改良点

フロントエンドとpgpool-II、pgpool-IIとPostgreSQLの間のSSL通信がサポートされました(Sean Finney)
ラージオブジェクトのレプリケーションがサポートされました(Tatsuo)
ヘルスチェックとオンラインリカバリの際に可能であればpostgresデータベースを使うようにしました。 postgresデータベースが存在しない場合はtemplate1が使われます(以前の動作と同じ)。これにより、DROP DATABASEなどのコマンドがオンラインリカバリ中でも使えるようになりました(Tatsuo)
問い合わせのパース処理でエラーが起きたときに、SQL文をログに出力するようにしました。エンコーディングエラーなどが発生した際にはPostgreSQLのログにもSQL文が記録されないため、これは有効です(Tatsuo)
kind mismatchエラーが発生し、その原因がDEALLOCATEコマンドだった場合にDEALLOCATEが削除しようとしたPREPARED文の元になったSQL文をログに出力するようにしました(Tatsuo)

バグ修正

たまにタイムスタンプを書き換えた問い合わせがマスタ以外のDBノードに不正なパケットを送ってしまう問題を修正しました(Tatsuo)
V2プロトコルでタイムスタンプの書き換え処理がエラーになるのを修正しました(Toshihiro Kitagawa)
master/slaveモード、かつトランザクション内で発行されるBind、Describe、Closeメッセージはマスタだけに送るようにしました(Tatsuo)
2.3でsmart shutdownによりすぐに停止しなくなったバグを修正しました(Toshihiro Kitagawa)
フロントエンドからの不正なコマンドを受け付けないようにしました(Xavier Noguer)
移植性を高めるために、fprintfの引数に%dzを使用するようにしました(Tatsuo)
コンパイラワーニングを修正しました(Tatsuo)
master/slaveモードの際に、DEALLOCATEをすべてのノードに送らないようにして、kind mismatchエラーを防ぐようにしました(Tatsuo)

2.3.1 (tomiteboshi) 2009/12/18

概要

このバージョンでは、2.3の色々なバグが修正されています。特に、ある条件でDBに不正な数値が書き込まれるバグが修正されており、以下の示す条件に合致する使い方をしている2.3ユーザは至急バージョンアップすることをお勧めします。

バグ修正と改良点

以下のすべての条件に合致する場合、DBに不正な値が書き込まれるバグを修正しました(Tatsuo)
1. レプリケーションモードで動作
2. 64bit OS
3. INSERTまたはUPDATEにおいて、now(), CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIMEを直接含むか、テーブルのデフォルト値に含んでいる
4. 更にそのSQL内に32bit(10進で-2147483648から2147483647)の範囲を超える整数定数が含まれている
以上を満たすSQLの例:
```
	  INSERT INTO t1(id, regdate) VALUES(98887776655, NOW());
	  
```
この例では、98887776655が32bit値にカットされて書き込まれます。
18以上のDBノードを使用している場合に、show pool_statusでクラッシュするバグを修正しました。このバグはshow pool_statusが実装されてからずっと存在していたものです。
"kind mismatch"メッセージが出た際に、kindがERRORまたはNOTICEならば、そのメッセージを表示するようにしました。これにより、PostgreSQLのログを見なくてもkind mismatchエラーの原因を容易に調べることができるようになりました(Tatsuo)

2.3 (tomiteboshi) 2009/12/07

概要

このバージョンでは、レプリケーション機能に改良が加えられ、時刻データ(CURRENT_TIMESTAMP, CURRENT_DATE, now()など)を正しく扱うことができるようになりました。また、同時接続数が1(num_init_childrenが1)のときのレプリケーション性能向上しています。また、pgpool-II再起動時に前回のDBノードのダウン状態を記録し、不用意に復旧ノードにデータを書き込んでデータの不整合が起きることを防ぐことができるようになりました。そのほか、クエリログが改良されてDBノード単位の状況が把握しやすくなり、またファイルオーバの挙動が細かく制御できるようになりました。なお、pgpool-II 2.3には、pgpool-II 2.2.1から2.2.6までのすべてのバグ修正、改良が含まれています。

pgpool-II 2.2.からの非互換性

[logdir]の下にpgpool_statusというファイルが作られるので、pgpoolの実行ユーザが読み書きできる権限を与えておいてください。

改良点

レプリケーションにおいて、時刻データ(CURRENT_TIMESTAMP, CURRENT_DATE, now()など)を正しく扱うことができるようになりました。特にアプリケーションに変更を加えることなく、INSERT/UPDATE文、テーブルのデフォルト値にこれらの時刻関数を含むケースでも正しくレプリケーションできます(いくつか制限事項があります。詳細は制限事項を参照してください)。(Akio Ishida)
SQLパーサをPostgreSQL 8.4のものにバージョンアップしました(Akio Ishida)
同時接続数が1(num_init_childrenが1)のときのレプリケーション性能が20%から100%向上しました(Tatsuo)
新しいディレクティブlog_per_node_statementが追加されました(Tatsuo) log_statementと似ていますが、DBノード単位でログが出力されるので、レプリケーションや負荷分散の確認が容易です。また、バックエンドのプロセスIDも表示されるので、バックエンドのログと併せての解析が容易になっています。
新しいディレクティブfail_over_on_backend_errorが追加され、フェイルオーバの挙動がより細かく制御できるようになりました(Tatsuo)
pgpool-II停止時にダウンしたDBノードの情報をステータスファイルに記録し、pgpool-IIを起動したときにその情報をリストアできるようにしました(Tatsuo) ステータスファイルは [logdir]/pgpoo_status というファイルに書かれます。
EXPLAINと、問い合わせがSELECTのときのEXPLAIN ANALYZEが負荷分散されるようになりました。これによって、DBノードの間で大幅に問い合わせプランが異るために、kind mismatchエラーが起きるのを防ぐことができます(Tatsuo)
日本語ドキュメントの体裁を改良しました(Tatsuo)
レプリケーションモード、マスタースレーブモード用のデフォルトpgpoo.conf.sampleが別途追加されました(Tatsuo)
時刻データのテストが追加されました(Akio Ishida)

2.2.7 (urukiboshi) 2010/04/15

概要

このバージョンでは、kind mismatchエラーが起きた際のエラーメッセージが改善されています。また、2.2.6以前の色々なバグが修正されています。

バグ修正

マスター／スレーブモード、rawモード、またはコネクションプールモードにおいて、拡張プロトコルを使用している際に時々ハングアップするバグを修正しました。これは、2.3系からのバックパッチです(Kitagawa)
pgpool子プロセスがsegfaultを起こすpgpool-II 1.0から長い間存在したバグを修正しました。これは、親プロセスがshmemサイズの計算を間違えていたことに起因します。バグ解析(Kitagawa)、パッチ作成(Tatsuo)
マスター／スレーブモードにおいて、明示的なトランザクションで操作した場合は、Parse、Bind、Describe、そしてCloseメッセージをマスターノードのみに送るようにしました(Tatsuo)
postmasterが終了する際に、ログを出力するようにしました(Tatsuo)
make_persistent_db_connection関数のメモリリークを修正しました(Xavier Noguer)
マスター／スレーブモードでは、DEALLOCATEの強制的なレプリケーションをしないようにしました。 pgpoolはParseをすべてのノードで実行しないため、これは無意味で問題(DEALLOCATE実行時のkind mismatch)を引き起こしていました(Tatsuo)
18より多いDBノードでshow pool_statusを実行したときにクラッシュするバグを修正しました(Tatsuo)
kind mismatchメッセージを改善しました。kindがERROR、またはNOTICEの場合は、何が起きているかユーザーがわかりやすいようにERROR/NOTICEメッセージを出力します(Tatsuo)

2.2.6 (urukiboshi) 2009/12/01

概要

このバージョンでは、ロードバランスの重みパラメータweightの扱いが改善され、また一時テーブルがマスター／スレーブモードで利用できるようになりました。もちろんいつものように2.2.5以前の色々なバグが修正されています。

バグ修正

DECLARE, CLOSE, FETCH, MOVEがロードバランスの対象にならなくなりました。もしデータが更新され、トランザクションがコミットされた後にCLOSEが発行されるとデータの一貫性がなくなるからです (つまり、holdできるカーソルの場合のことを言っています)(Tatsuo)
マスター／スレーブモードにおいて、拡張プロトコルのParseをマスター上でのみ実行するようにしました。以前はすべてのノードでParseが実行されていたのですが、これだと不必要なロックがスレーブでも取られてしまいます(Tatsuo)
uninstallの前にすべてのランレベルからinitスクリプトを削除するようにしました(Devrim)
認証に失敗したときに適切なエラーメッセージを出すようにしました(Glyn Astill)
ソケットへの書き込みに失敗したときにフロントエンド用なのかバックエンド用なのかわかるようにしました(Tatsuo)
フロントエンド用のソケットに書き込み失敗したときにいちいちエラーを出さないようにしました(Tatsuo)
マスター／スレーブモードで一時テーブルが使えるようになりました。 INSERT/UPDATE/DELETEは自動的にマスタのみに送られます。SELECTに関しては明示的にクエリの前に /*NO LOAD BALANCE*/というコメントを付けなければなりません(Tatsuo)

2.2.5 (urukiboshi) 2009/10/4

概要

このバージョンでは、2.2.4以前の色々なバグが修正されています。

バグ修正

コネクション数のカウントのミスにより、オンラインリカバリが終わらなくなるバグを修正しました(Tatsuo)
内部的にロックを発行する際にもフロントエンドが異常終了したことを検出してSQLコマンドをキャンセルするようにしました(Tatsuo)
接続の終了処理で無限ループに陥ることがあるバグを修正しました(Xavier Noguer, Tatsuo)
拡張プロトコルのパース処理でkind mismatch errorが起きた際に正しいSQL文を表示するようにしました(Tatsuo)
ドキュメントを改善しました(Tatsuo)

2.2.4 (urukiboshi) 2009/8/24

概要

このバージョンでは、2.2.3以前の色々なバグが修正されています。

バグ修正

pgpool-II 2.2.2で入ってしまったバグを修正しました。フロントエンドがアボートするタイミングによっては、以後内部状態がリセットされず、次のセッションでDMLやDDLがマスターノードのみ送られ、ノード間でデータの不一致が生じることがありました(Tatsuo)
pgpool-II 2.2.3でバージョン2プロトコルのクライアントが動かなくなってしまっていたのを修正しました。また、時間のかかるクエリを待っている間にフロントエンドが異常終了したことを検知する間隔を1秒から30秒に変更しました。このチェックは、2.2.4ではプロトコルバージョンが3のときのみ有効です(Tatsuo)
子プロセスを起動する前にシグナルのブロックやハンドラの設定を行なうようにしました。これは、pgpool-IIを起動した直後にファイルオーバなどの事象が発生して子プロセスから親プロセスにシグナルが送られると、pgpool-IIの親プロセスが死んでしまうことがあるからです(Tatsuo)

2.2.3 (urukiboshi) 2009/8/11

概要

このバージョンでは、2.2.2以前の色々なバグが修正されています。

バグ修正

バックエンドに新しいコネクションを張る際に、バックエンドの一つが障害を起しているケースで、後処理の中でpgpool-IIの子プロセスが落ちることがあるバグを修正しました(Tatsuo)
パラレルクエリのバグを修正しました(Yoshiharu Mori)
拡張プロトコルの場合にもエラーメッセージの中で最後に使用したクエリが表示できるようになりました(Akio Ishida)
kind mismatch errorメッセージの作成で、メッセージ内容が壊れることがあるバグを修正しました(Tatsuo, Akio Ishida)
バックエンドへの接続記述子の参照タイミングによってはpgpool-IIの子プロセスが落ちることがあるバグを修正しました(Tatsuo)。
pool_errorやpool_logの引数が間違っていた個所を修正しました(Akio Ishida)。
statement_timeoutのタイムアウトによるエラー処理を改良しました。実際にはタイムアウトまでにstatement_timeoutで設定した時間の倍かかっていたのを直しました。また、masterだけがstatement_timeoutを返した場合にも対応できるようにしました。以前はkind mismatchエラーになっていました(Tatsuo)。 (master以外がstatement_timeoutを返さないケースではkind mismatchエラーになります)。
health checkをより強化し、postmasterがSIGSTOPで止ってしまっている場合も障害検知できるようにしました。
バックエンドにSQLを投げ、その応答を待っている間にクライアントがpgpoolに対するコネクションを切断したことが検出できるようになりました。たとえば、WebアプリケーションではDBに対してリクエストを投げて、応答がないとキャンセルするようなことが頻繁に起ります。この場合、今まではpgpoolやPostgreSQLのプロセスが残ってしまい、同時接続数が枯渇したり、ロックを取ったままのトランザクションが残るなどしてシステム全体に影響を与えることがありました。今回の修正により、こうした状況が検出できるようになっただけでなく、SQLの応答待ちの間にクライアントがコネクションを切断した際には、SQLコマンドのキャンセルをpgpoolが行なって、ロック待ちなどのバックエンドプロセスが残るのを防ぐことができるようになりました(Tatsuo)。
引数なしのCLUSTERコマンドはトランザクションの中では実行できないので、自動トランザクションをスタートしないようにしました(Tatsuo)。
複数のプリペアドステートメントを使っている際に、セッションの終りでその一部だけが解放されるバグを修正しました(Akio Ishida) 。
sql/pgpool-recovery/pgpool-recovery.cがPostgreSQL 8.4でコンパイルできるようにしました(Tatsuo)。
拡張プロトコルを使っている場合に、クライアントとpgpoolの間でお互いに待ち状態になってしまうことがあるバグを修正しました(Gavin Sherry)。
COPY FROMを実行中にクライアントが処理を中断した場合に、バックエンドプロセスが残ってしまうバグを修正しました(Tatsuo)。

2.2.2 (urukiboshi) 2009/5/5

概要

このバージョンでは、2.2.1以前の色々なバグが修正されています。とりわけ、pgpoolがクライアントとの間でデータのやり取りをしている最中に、pgpoolのクライアントが終了(X)パケットをpgpoolに送信せずに終了した場合に起る可能性があります。このバグは過去のすべてのpgpoolに存在しています。

バグ修正

フロントエンドにpgpoolがデータを送信する際のエラーを無視するようにしました。これによって、バックエンドとの間で必要な処理が中断されないようになり、バックエンドの間でデータの一貫性がなくなる問題が回避されるようになりました(Tatsuo)。
マスタースレーブモードに関する2.2.1の修正の際に生じたバグを修正しました。プリペアドステートメントを使い回すとハングアップする可能性がありました(Toshihiro)。
SQLコマンドのPREPAREとプロトコルレベルのEXECUTEが混在するとバックエンドがクラッシュするバグを修正しました。このバグが、2.2で持ち込まれたものです(Tatsuo)。
コネクションのリセット用の問合わせを実行中にエラーが起きた場合に、PostgreSQLのログに"unexpected EOF on client connection"が記録される問題を修正しました(Tatsuo)。

2.2.1 (urukiboshi) 2009/4/25

概要

このバージョンでは、2.2の色々なバグが修正されています。

バグ修正

master/slaveモードで、DEALLOCATEが失敗することがある問題を修正しました。これは、最初のPREPAREがslaveで実行されないことによるものです(Toshihiro)
pgpool.specなどを2.2対応にしました(Devrim)
Version 2プロトコルではinsert_lockが無視されるようにしました(Tatsuo)
パラメータ変更メッセージがバックエンドから届く度にログが出力されるのを止めました(Tatsuo)
ドキュメントで追加し忘れたファイルを登録しました(Tatsuo)

2.2 (urukiboshi) 2009/2/28

概要

このバージョンでは、SERIALデータの扱いとオンラインリカバリに改良が行なわれています。また、トランザクション分離レベルがシリアライザブルの場合に、DBノード間でデータの一貫性がなくなる可能性がある問題、クエリのキャンセルができない問題が修正されました。

新機能

insert_lockが有効な場合、SERIAL型を持つテーブルだけがロックされるようになりました(Tatsuo)。
設定項目client_idle_limit_in_recoveryが追加されました。オンラインリカバリの第2ステージでクライアントがアイドルのまま居座ることによって、オンラインリカバリが進行しなくなることを防ぐことができます(Tatsuo)。
設定項目pid_file_nameが追加されました。これは、pgpool-IIのpidファイルを指定します。これにより、logdirは使用されなくなりました(Tatsuo)。
DECLARE, FETCH, CLOSEで負荷分散されるようになりました(Tatsuo)。
pcpコマンドにデバッグオプション(-d)が追加されました(Jun Kuriyama)。
"kind mismatch"エラーの際に、原因となったクエリを表示するようにしました(Tatsuo)。

互換性

フェイルオーバ時に必ずpgpoolの子プロセスを再起動するようにしました。この結果、フェイルオーバ時には必ずpgpoolへのセッションが一端切れることになります。こうしないと、ネットワークケーブル抜けなどの際に、 TCP/IPのレイヤで再送が行なわれ、長い時間そのままになってしまうことがあるからです(Tatsuo)。
設定項目logdirは使われなくなりました。代りに、pid_file_nameを使ってください(Tatsuo)。
insert_lockのデフォルト値がtrueになりました(Tatsuo)。

バグ修正

pgpoolがデーモンモードで起動される際に、すべてのファイルディスクリプタを閉じるようにしました。こうしないと、pgpoolAdminから起動された際に apacheのソケットファイルを引き継いでしまい、80番ポートが専有されてしまいます(Akio Ishida)。

トランザクションをシリアライズできないエラーが発生したときに、すべてのDBノードのトランザクションをアボートするようにしました。こうしないと、DBノードの間でデータの不整合が起きることがあります(Tatsuo)。例を示します(Mはマスタ、Sはスレーブを示します)。

	   M:S1:BEGIN;
	   M:S2:BEGIN;
	   S:S1:BEGIN;
	   S:S2:BEGIN;
	   M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
	   M:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
	   S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
	   S:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
	   M:S1:UPDATE t1 SET i = i + 1;
	   S:S1:UPDATE t1 SET i = i + 1;
	   M:S2:UPDATE t1 SET i = i + 1; <-- blocked
	   S:S1:COMMIT;
	   M:S1:COMMIT;
	   M:S2:ERROR:  could not serialize access due to concurrent update
	   S:S2:UPDATE t1 SET i = i + 1; <-- success in UPDATE and data becomes inconsistent!

rawモードでMD5認証が使えるようにしました。ドキュメント上では使えるはずでした(Tatsuo)。

"SET TRANSACTION ISOLATION LEVEL must be called before any query"のエラーが発生した場合に"kind mimatch"エラーになることを防ぐようにしました(Tatsuo)。以下のシナリオで問題が発生します。

	   M:S1:BEGIN;
	   S:S1:BEGIN;
	   M:S1:SELECT 1; <-- only sent to MASTER
	   M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
	   S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
	   M: <-- error
	   S: <-- ok since no previous SELECT is sent. kind mismatch error occurs!

FreeBSDにおいて、psでのprocess statusの表示で余計なスペースが含まれてしまうのを修正しました(Jun Kuriyama)
BEGIN;を2度続けるとkind mismatch errorが発生するのを修正しました(Tatsuo)
PostgreSQLがたくさんのDEBUGメッセージを出力する場合に、誤ってエラーと見なすバグを修正しました(Tatsuo)
クエリのキャンセルが動くようになりました(Tatsuo)
オンラインリカバリの後クライアントからの接続を受け付けるタイミングが早すぎるバグを修正しました。このバグにより、ノードデータの貫性が保たれない可能性がありました(Tatsuo)
SELECT, INSERT, UPDATE, DELETE以外のコマンドでも必要ならばトランザクションブロックの内側で実行するようにしました。これにより、エラー発生の際にロールバックしてノードの整合性を保つことができます(Tatsuo)
オンラインリカバリ後、pgpool-IIの子プロセスがクラッシュすることがあるバグを修正しました。これは、オンラインリカバリの後、新しくアタッチされたノードに接続がないのに、そのノードに子プロセスが終了時に終了メッセージをバックエンドに送信しようとして起っていました(Tatsuo)
PostgreSQLがpostgresql.confを再読み込みした際にpgpoolがエラーを検出してしまうバグを修正しました。これは、PostgreSQLが（たぶん）ドキュメントに書かれていないタイミングで「パラメータ変更」パケットを送信してくるために起り、修正はそのことに対応したものです(Tatsuo)

2.1 (inamiboshi) 2008/7/25

新機能

failover_command と failback_command に、新しいマスタノード ID を表す '%m' をサポートしました。(Yoshiyuki)
failover_command と failback_command に、古いマスタノード ID を表す '%M' をサポートしました。(Yoshiyuki)
リカバリのタイムアウト時間を指定する recovery_timeout パラメータを追加しました。(Taiki)
pg_md5 コマンドに -p オプションを追加しました。(Volkan Yazici, Taiki)
pgpool -v を実行するとバージョン番号を表示し、終了するようにしました。(Yoshiyuki)

互換性

pgpool_recovery と pgpool_remote_start 関数はスーパーユーザのみ実行できるように権限チェックを強化しました。(Yoshiyuki)
raw モードでスタンバイノードにはコネクションプールを作成しないようにしました。(Yoshiyuki)
replication_timeout パラメータを削除しました。(Yoshiyuki)
PCP クライアントコマンドのタイムアウトを無効にしました。(Taiki)
replicate_select = false の場合に、COPY TO STDOUT をレプリケーションさせないようにしました。(Yoshiyuki)

修正

全般

CloseComplete メッセージを受けとるとクラッシュする不具合を修正しました。(Yoshiyuki)
メッセージ転送処理を効率よくしました。(Yoshiyuki)
Solaris 10 でコンパイルできるようにしました。(Yoshiyuki)
ヘルスチェックとリカバリのログ出力を改良しました。(Tatsuo)
様々なメモリリークを修正しました。(Yoshiyuki)
"failed to read kind from frontend" というエラーメッセージを ERRORレベルから LOG レベルに下げました。(Yoshiyuki)
raw モードでフェイルオーバに失敗する不具合を修正しました。 (Taiki)
不正なノードを追加・切り離しを行うとゾンビプロセスが発生する不具合を修正しました。(Yoshiyuki)
health_check_timeout が正しく動作しない不具合を修正しました。 (Kenichi Sawada)
FreeBSD で ps コマンドの出力が正しくない不具合を修正しました。 (ISHIDA Akio)
Unix domain ソケットが残っている場合のエラーメッセージを強化しました。(Jun Kuriyama)
認証に失敗した場合のエラーメッセージを強化しました。(Tatsuo)

レプリケーション

replicate_select を設定しても、常に false の挙動になる不具合を修正しました。(Tatsuo)
拡張問い合わせプロトコルを使っていると、トランザクションを誤ってロールバックしてしまう不具合を修正しました。(Yoshiyuki)
非同期クエリを使っていると pgpool が不安定になる不具合を修正しました。(Yoshiyuki)
拡張問合せプロトコルを使うと /* REPLICATION */などのヒント句が消えてしまう不具合を修正しました。(Yoshiyuki)
DEALLOCATE ALL を実行するとクラッシュする不具合を修正しました。 (Yoshiyuki)
immediate shutdown するとハングアップする不具合を修正しました。 (Yoshiyuki)
高負荷時にオンラインリカバリを実施すると、リカバリプロセスがハングアップする可能性のある不具合を修正しました。(Yoshiyuki)
拡張問合せプロトコルを使って SELECT を実行した際に、トランザクションブロック内でクエリがエラーになると、pgpool がハングアップする可能性のある不具合を修正しました。(Yoshiyuki)

マスタースレーブ

トランザクションブロック内で、SET, PREPARE, DEALLOCATE を実行すると、プロセスがダウンする不具合を修正しました。(Yoshiyuki)
マスタースレーブモードでロードバランスが正しく動作していない不具合を修正しました。(Yoshiyuki)

パラレルクエリ

INSERT に失敗する不具合を修正しました。(Yoshiharu)
FROM 句に AS が含まれると構文エラーになる不具合を修正しました。(sho)
クエリを複数回実行するとハングアップする不具合を修正しました。(Yoshiharu)
JOIN に失敗する不具合を修正しました。(Yoshiharu)
DISTINCT構文の解析に失敗する不具合を修正しました。(Yoshiharu)

2.0.1 (hikitsuboshi) 2007/11/21

UPDATE もしくは DELETE を実行するとプロセスがダウンする不具合を修正しました。(Yoshiyuki)
master_slave を true に設定している場合に、SQL 構文エラーを検知した時にマスタにのみそのクエリを送信するようにしました。(Yoshiyuki)

2.0 (hikitsuboshi) 2007/11/16

互換性

ignore_leading_white_space のデフォルト値を true にしました。 (Yoshiyuki)
replicate_strict を廃止しました。常に replicate_strict が true の挙動になります。(Yoshiyuki)

全般

pgpool.conf をリロードできるようにしました。リロード時に分散ルールも同時にリロードします。(Yoshiyuki)
SQL パーサを PostgreSQL 8.3 に対応しました。(Yoshiyuki)
ノードを切り離した際にユーザが設定したコマンドを実行できるように、pgpool.conf に failover_command というパラメータを追加しました。 (Yoshiyuki)
ノードを復帰した際にユーザが設定したコマンドを実行できるように、 pgpool.conf に failback_command というパラメータを追加しました。 (Yoshiyuki)
pgpool.conf に client_idle_limit というパラメータを追加しました。このパラメータではクライアントからのクエリの最大待ち時間を設定することができます。(Tatsuo)

レプリケーション

トランザクションブロックに囲まれていないクエリをレプリケーションさせる場合、内部的にトランザクションを開始させるようにしました。 (Yoshiyuki)
レプリケーションを高速化させるようにしました。(Yoshiyuki)
ノードを再同期させて復帰させる、オンラインリカバリ機能を実装しました。(Yoshiyuki)

INSERT, UPDATE, DELETE した行数がすべて一致しなかった場合に、トランザクションをアボートさせるようにしました。(Yoshiyuki)

   x=# update t set a = a + 1;
   ERROR:  pgpool detected difference of the number of update tuples
   HINT:  check data consistency between master and other db node

複数のバックエンドから異なる結果が返ってきた場合に、同じ結果が多数返ってきた結果を信頼する多数決方式を実装しました。(Yoshiyuki)
V2 問合せプロトコルでロードバランスできるようにしました。(Yoshiyuki)

パラレルクエリ

パラレルモードで部分レプリケーションをサポートしました。(Yoshiharu)

1.3 (sohiboshi) 2007/10/23

新しく authentication_timeout というパラメータを追加しました。(Yoshiyuki)
- このパラメータでは認証時間のタイムアウトを設定します。
- デフォルト値は 60 (1 分)です。
スタートアップパケットの長さが 10000 バイト越えている場合には、接続を切断するようにしました。(Yoshiyuki)
DEALLOCATE を実行するとまれに不正なメモリアクセスが発生する不具合を修正しました。(Yoshiyuki)
トランザクション内で SELECT を実行した後に SELECT を正しくロードバランスできない不具合を修正しました。(Yoshiyuki)
- この不具合は 1.2 で混入した不具合です。
64bit 環境でクエリキャッシュ機能を有効にすると、クラッシュする可能性のある不具合を修正しました(Yoshiyuki)

1.2.1 (tomoboshi) 2007/09/28

拡張問合せプロトコルの Parse メッセージの処理でデッドロックが発生する可能性がある不具合を修正しました。(Yoshiyuki)
Prepared statement を管理する領域がメモリリークしている不具合を修正しました。(Yoshiyuki)
一部の OS でコンパイルエラーになる不具合を修正しました。(Yoshiyuki)
master/slave モード内で SET, PREPARE, DEALLOCATE 文をレプリケーションさせるようにしました。(Yoshiyuki)

1.2 (tomoboshi) 2007/08/01

pgpool.conf に replicate_select という新規パラメータを追加しました。デフォルト値は false です。(Yoshiyuki)
- true に設定した場合は、ロードバランスされない SELECT 文をレプリケーションします(pgpool-II 1.0 の挙動)。false の場合はマスタにのみ SELECT を送信します。
シグナル処理を安全に行うようにしました。(Yoshiyuki)
- まれにゾンビプロセスが残ってしまったり、不安定になることがありました。
トランザクション中に SELECT 文がエラーになると、ハングアップしてしまう不具合を修正しました。(Yoshiyuki)
- この不具合は 1.1 に入った不具合です。
PREPARE/EXECUTE が master/slave モードで正しく動作しない不具合を修正しました。(Yoshiyuki)
デッドロックを検知すると、kind mismatch error が発生する不具合を修正しました。(Yoshiyuki)
拡張問い合わせプロトコルを使ったドライバを使用した場合に、構文解析時に警告が発生する SQL 文を実行するとハングアップもしくはプロセスがクラッシュする不具合を修正しました。(Yoshiyuki)
コネクションキャッシュが一杯になるとメモリリークが発生する不具合を修正しました。(Yoshiyuki)
セッションが残った状態で PostgreSQL を fast shutdown もしくは immediate shutdown すると、残ったセッションがハングアップする不具合を修正しました。(Yoshiyuki)
ロードバランス先を接続開始時に決定し、同じセッション内ではすべて同じノードにクエリを送信するようにしました。(Yoshiyuki)
connection_life_time を設定している場合にバッファオーバランが発生する可能性がある不具合を修正しました。(Yoshiyuki)

1.1.1 (amiboshi) 2007/06/15

load_balance_mode を有効にしていると、"kind mismatch" エラーが発生してしまう不具合を修正しました。これは 1.1 で入った不具合です。 (Yoshiyuki)
プロトコルバージョン 2 を使ったドライバでレプリケーション使用すると、pgpool がハングアップする不具合を修正しました(Yoshiyuki)
拡張問合せプロトコルを使用すると、まれにデッドロックが発生する不具合を修正しました(Yoshiyuki)

1.1 (amiboshi) 2007/05/25

HBA 認証をサポートしました(Taiki)
log_connections をサポートしました(Taiki)
log_hostname をサポートしました(Taiki)
ps コマンドで pgpool の状態がわかるようにしました(Taiki)
MacOS X でコンパイルエラーになる不具合を修正しました(Yoshiyuki)
拡張問い合わせプロトコルを使ったクエリをロードバランスできるようにしました(Yoshiyuki)
レプリケーション設定時、SELECT は master にのみ送信するようにしました(Yoshiyuki)
- もし SELECT をレプリケーションさせる場合は /*REPLICATION*/ のように SELECT の前にコメントを付ける必要があります
レプリケーション設定時、SELECT nextval() および SELECT setval() を自動的にレプリケーションさせるようにしました(Yoshiyuki)
バックエンドへ接続中にシグナルに割り込まれると、フェイルオーバしてしまう不具合を修正しました(Yoshiyuki)
PAM 認証のサンプルファイル pgpool.pam を $PREFIX/share/pgpool-II/ にインストールするようにしました(Taiki)
巨大な SQL を実行しようとした場合に pgpool が無限ループに入る不具合を修正しました(Yoshiyuki)

1.0.2 (suboshi) 2007/02/13

巨大な SQL を実行しようとした場合に pgpool が無限ループに入る不具合を修正しました(Yoshiyuki)
拡張問合せプロトコルを使った場合にまれに pgpool が止まってしまう不具合を修正しました(Yoshiyuki)
フェイルオーバ、フェイルバック時のログ出力を改善しました (Tatsuo)
SHOW pool_status の結果にバックエンドステータス情報を追加しました(Tatsuo)
レプリケーション時に UPDATE/DELETE の件数が実際の件数とは異なった結果を返す不具合を修正しました(Tatsuo)
古い gcc を使うと libpq のリンクに失敗する不具合を修正しました (Yoshiyuki)
PHP:PDO や DBD-Pg を使った場合に、自動 DEALLOCATE が失敗してしまう不具合を修正しました(Yoshiyuki)
SELECT FOR UPDATE, SELECT INTO をロードバランスさせないようにしました。また、SELECT の前にコメントがある場合もロードバランスさせないようにしました。これは pgpool-I との互換性のためです。(Yoshiyuki)
configure 時の libpq のデフォルトパスを pg_config コマンドを使って取得するようにしました。なお、--with-pgsql 関連のオプションは次のバージョンでは廃止予定です(Yoshiyuki)
コネクションプール再利用時に、ソケットが壊れている場合は再接続するようにしました(Yoshiyuki)
PostgreSQL 7.4.x の libpq を使ってビルドしようとすると、 configure スクリプトでエラーとなってしまう不具合を修正しました (Yoshiyuki)