Last modified: Mon Aug 24 18:18:48 JST 2015
Welcome to pgpool -II page

pgpool-IIとは

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

pgpool-IIはPostgreSQLバックエンドとフロントエンドの通信プロトコルを理解してその間を中継します。 すなわち、PostgreSQLのデータベースアプリケーションからはPostgreSQLサーバに、 PostgreSQLからはデータベースアプリケーションに見えるように設計されています。

そのため、PostgreSQLそのものはもちろん、アプリケーションの開発言語によらず、 PostgreSQLのデータベースアプリケーションにほとんど手を加えることなく、 pgpool-IIの機能が利用できます。

一部のSQLには制限事項があります。

License

Copyright (c) 2003-2016 PgPool Global Development Group


Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. The author makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.

pgpool-II の稼働環境

pgpool-II は、Linux をはじめ、Solaris や FreeBSD などのほとんどの UNIX 環境で動作します。 Windows では動きません。

対応する PostgreSQL のバージョンは、PostgreSQL の 6.4 以降です。 また、PostgreSQL 7.4 より前のバージョンでは、使用できる機能に制限事項があります。 もっとも、そのような古いバージョンの PostgreSQL はそもそも使うべきではありません。

pgpool-II 配下で利用する PostgreSQL サーバのメジャーバージョン、 OS やハードウェアアーキテクチャを同じものにしなければなりません。 また、バージョンが同じであっても、PostgreSQL のビルド方法が違うものを混ぜている場合の動作は保証できません。 たとえば、SSL サポートの有無、日付型の実装方法 (--disable-integer-datetimes)、 ブロックサイズの違いなどは、pgpool-II の一部の機能に影響を与えるでしょう。 PostgreSQL のマイナーバージョンが違う場合は大抵の場合問題になりませんが、 すべての PostgreSQL のマイナーバージョンを検証したわけではないので、 できればマイナーバージョンを合わせておくことをお勧めします。

pgpool-II のインストール

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

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

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

また、OpenSSL サポートを有効にする場合は、OpenSSL ライブラリと開発用のヘッダーファイルが必要です。

pgpool-II のインストール

configureの実行

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

./configure

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

--prefix=path pgpool-II 本体や関連ファイルをインストールするトップディレクトリを指定します。 デフォルトは /usr/local です。
--with-pgsql=path PostgreSQL のクライアントライブラリなどがインストールされているトップディレクトリを指定します。 デフォルトはpg_configコマンドで取得できるパスです。
--with-openssl pgpool-II を OpenSSL サポート付で作成します。 デフォルトでは OpenSSL サポートは無効です。 V2.3 〜
--enable-sequence-lock pgpool-II 3.0シリーズ (3.0.4まで) 互換の insert_lock を使用します。 pgpool-II は、シーケンステーブルの行に対してロックを行います。 これは、2011 年 06 月より後にリリースされた PostgreSQL 8.2 以降では使用できません。 V3.1 〜
--enable-table-lock pgpool-II 2.2 と 2.3 シリーズ互換の insert_lock を使用します。 pgpool-II は、挿入対象のテーブルに対してロックを行ないます。 これは、ロックが VACUUM と競合するため非推奨です。 V3.1 〜
--with-memcached=path キャッシュストレージに memcached を利用し、 インメモリクエリキャッシュ機能を 利用したい場合に指定します。 libMemcachedのインストールが必要です。 V3.2 〜
makeの実行
make
make install

関数の登録

pgpool_regclass のインストール(オプション) V3.0 〜

PostgreSQL 8.0 以降、PostgreSQL 9.3までを使用している場合は、pgpool-II が内部で使用する C 関数 pgpool_regclass をインストールします。

PostgreSQL 9.4以降を使用している場合は、pgpool_regclassのインストールは必要ありません。 PostgreSQLに同等の関数(to_regclass)が含まれているからです。

pgpool_regclass とは?

この関数がインストールされていなくても pgpool-II は動作しますが、違うスキーマで同じテーブル名を定義していて、 SQL 文の中でスキーマ名を省略している場合に、不具合が生じることがあります(一時テーブルを除く)。 したがって、可能ならば pgpool_regclass をインストールすることをお勧めします。

関数のインストール

このインストールは、pgpool-II がアクセスする予定のすべての PostgreSQL サーバで実施してください。

$ cd pgpool-II-x.x.x/sql/pgpool-regclass
$ make
$ make install

この後に以下か、

$ psql -f pgpool-regclass.sql template1

または

$ psql template1
=# CREATE EXTENSION pgpool_regclass;

を実行します。

備考

pgpool-regclass.sql または CREATE EXTENSION の実行は、 pgpool-II 経由で利用するデータベース毎に必要になります。 ただし、template1 データベースに対して "psql -f pgpool-regclass.sql template1" または CREATE EXTENSION を実行後に作成されたデータベースでは、 新たに pgpool-regclass.sql または CREATE EXTENSION を実行する必要はありません。

insert_lock テーブルの作成 V3.0 〜

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

レプリケーションモードで insert_lock を利用したい場合は、排他制御用のテーブル pgpool_catalog.insert_lock を作成します。

insert_lock テーブルが存在しなくても今のところ insert_lock は動作しますが、 その場合は、挿入対象のテーブルに対してロックが行われます。 これは pgpool-II 2.2 と 2.3 シリーズの動作と同じです。挿入対象のテーブルに対するロックは、 VACUUM と競合して INSERT 処理が長時間が待たされる可能性があります。

したがって、insert_lock テーブルを作成することをお勧めします。 テーブルの作成は、pgpool-II がアクセスする予定のすべての PostgreSQL サーバで実施してください。

テーブルの作成

$ cd pgpool-II-x.x.x/sql
$ psql -f insert_lock.sql template1

備考

insert_lock.sqlの実行は、pgpool-II経由で利用するデータベース毎に必要になります。 ただし、"psql -f insert_lock.sql template1" を実行後に作成されたデータベースでは 自動的に insert_lock.sql の内容が反映されているので、新たに insert_lock.sql を実行する必要はありません。

pgpool_recovery のインストール

後述の オンラインリカバリ の機能を使う場合には、 pgpool_recovery, pgpool_remote_start, pgpool_switch_xlog という関数が必要です。

また管理ツールである pgpoolAdmin の画面上から、バックエンドノードの PostgreSQL を停止・再起動・ 設定再読み込みを行なうことができますが、これには pgpool_pgctl という関数が使われます。

これらの機能を使いたい場合には、上記の pgpool_regclass と同様の手順でこれらの C 関数を登録します。 なお、この 4 つの関数は、すべてのデータベースにインストールされている必要はなく、template1 にだけで 構いません。

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

この後に以下か、

$ psql -f pgpool-recovery.sql template1

または

$ psql template1
=# CREATE EXTENSION pgpool_recovery;

を実行します。

pgpool.pg_ctl の設定 V3.3 〜

pgpool_pgctl 関数は、バックエンドノードの PostgreSQL の 「pgpool.pg_ctl」という カスタムパラメータに書かれたコマンドを実行します。 この関数を使うには、このパラメータに pg_ctl コマンドのパスを指定します。

ex)
$ cat >> /usr/local/pgsql/postgresql.conf
pgpool.pg_ctl = '/usr/local/pgsql/bin/pg_ctl'

$ pg_ctl reload -D /usr/local/pgsql/data

pgpool-IIの設定

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

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

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の設定

サンプルファイル V2.3 〜

pgpool-IIをインストールすると、インストール先ディレクトリ(デフォルトでは/usr/local) /etc/pgpool.conf.sampleができるので、それを インストール先ディレクトリ/etc/pgpool.confという名前でコピーします。

cp インストール先ディレクトリ/etc/pgpool.conf.sample $prefix/etc/pgpool.conf

また、各動作モード用のサンプルpgpool.confが用意されています。 こちらもご利用下さい。

動作モードサンプルファイル名
レプリケーションモードpgpool.conf.sample-replication
マスタースレーブモード(Slony-I)pgpool.conf.sample-master-slave
マスタースレーブモード(Streaming replication)pgpool.conf.sample-stream

コメントの扱い

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

共通設定項目

各動作モードで共通する設定項目を説明します。

Connections

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'です。 このソケットは、cronによって削除されることがあるので注意してください。 '/var/run'などのディレクトリに変更することをお勧めします。

このパラメータを変更した時には pgpool-II を再起動してください。

pcp_listen_addresses

pcpがTCP/IPコネクションを受け付けるアドレスをホスト名またはIPアドレスで指定します。 「*」を指定するとすべてのIPインタフェースからのコネクションを受け付けます。 「''」を指定するとTCP/IPコネクションを受け付けません。デフォルト値は「*」です。 UNIXドメインソケット経由のコネクションは常に受け付けます。

このパラメータを変更した時には pgpool-II を再起動してください。

pcp_port

pcpが使用するポート番号です。

このパラメータを変更した時には pgpool-II を再起動してください。

pcp_socket_dir

pcpがコネクションを受け付けるUNIXドメインソケットを置くディレクトリです。 デフォルト値は'/tmp'です。 このソケットは、cronによって削除されることがあるので注意してください。 '/var/run'などのディレクトリに変更することをお勧めします。

このパラメータを変更した時には pgpool-II を再起動してください。

Pools

num_init_children

preforkするpgpool-IIのサーバプロセスの数です。デフォルト値は32になっています。 これが、pgpool-IIに対してクライアントが同時に接続できる上限の数になります。 これを超えた場合は、そのクライアントは、pgpool-IIのどれからのプロセスへのフロントエンドの接続が終了するまで 待たされます(PostgreSQLと違ってエラーになりません)。

待たされる数の上限は、listen_backlog_multiplier * num_init_children です。 待ち行列は、OS内部に作られ、「listenキュー」と呼ばれます。listenキューの長さは「バックログ」と呼ばれます。 システムによってはバックログの上限が設定されており、listen_backlog_multiplier * num_init_children が これを越える場合はシステム側の設定変更が必要になります。

さもないと高負荷時にlistenキューが溢れ、pgpool-IIへの接続が失敗したり、 システム内で行われるリトライにより著しく性能が低下することがあります。

listenキューが溢れているかどうかは、"netstat -s"で確認できます。"TcpExt"のパートで、

535 times the listen queue of a socket overflowed

のようなメッセージが出ていればlistenキューが溢れています。 listenキュー溢れを防ぐためにバックログを大きくするには、Linuxでは以下のようにします(root権限が必要です)。

# sysctl net.core.somaxconn
net.core.somaxconn = 128
# sysctl -w net.core.somaxconn = 256

もちろん、/etc/sysctl.confに以下のように書いても構いません。

net.core.somaxconn = 256

基本的に後述のmax_pool * num_init_children分だけPostgreSQLへのコネクションが張られますが、 他に以下の考慮が必要です。

  • 問い合わせのキャンセルを行うと通常のコネクションとは別に新たなコネクションが張られます。 したがって、すべてのコネクションが使用中の場合は問い合わせのキャンセルができなくなってしまうので、 ご注意下さい。 問い合わせのキャンセルを必ず保証したい場合は、想定されるコネクション数の倍の値を 設定することをおすすめします。
  • 一般ユーザでPostgreSQLに接続できるのは、 max_connections - superuser_reserved_connections 分だけです。

以上をまとめると、

クエリのキャンセルを考慮しない場合 max_pool * num_init_children <=
(max_connections - superuser_reserved_connections)
クエリのキャンセルを考慮する場合 max_pool * num_init_children * 2 <=
(max_connections - superuser_reserved_connections)

のどちらかを満たすように設定してください。

このパラメータを変更した時には pgpool-II を再起動してください。

listen_backlog_multiplier V3.4 -

フロントエンドからpgpool-IIへの接続待ち行列の長さを制御します。デフォルト値は2です。 接続待ち行列(listenシステムコールのbacklogパラメータ)の長さは、 listen_backlog_multiplier * num_init_children で決まります。 もし待ち行列の長さが不足する場合にはこのパラメータを増やしてください。 その際、OSの設定値によっては待ち行列を長く出来ないことがあります。 詳細はnum_init_childrenの項を参照してください。

このパラメータを変更した時には pgpool-II を再起動してください。

serialize_accept V3.5 -

クライアントからの接続を受け付ける際に accept() の呼び出しをシリアライズするかどうかを指定します。 デフォルトはoffです(シリアライズしません)で、これは pgpool-II 3.4 以前と同じ挙動です。

このパラメータがoffの場合、カーネルはすべてのpgpool-II子プロセスを起こして accept() を実行させます。 そして子プロセスのうちひとつだけが実際に接続を受け付けます。 問題は、ここで多くの子プロセスが一度に起こされるため、重いコンテキストスイッチングが起こり、性能に影響がでることです。 この現象は「thundering herd problem」と呼ばれる古典的な問題です。 serialize_accept を有効にすることにより、pgpool-II子プロセスのうちひとつだけが起こされて accept() を実行するようになり、 この問題は回避されます。

ではどんなときに serialize_accept を有効にすべきでしょう? num_init_children が大きい時はserialize_accept 有効にすることをおすすめします。 num_init_children が小さい時はserialize_accept 有効にしても効果がないかもしれません。 むしろシリアライズのオーバヘッドのために性能が低下するかもしれません。 どの位の数が「大きい」と言えるかは環境によります。 どうするか決める前に、ベンチマークテストを行ってみることをおすすめします。

例として以下のような方法でpgbenchを実行します。

pgbench -n -S -p 9999 -c 32 -C -S -T 300 test

ここで、 -C は pgbench にトランザクションの実行の度に毎回データベースに接続することを指示します。 -c 32 は、pgpool-II への同時接続数です。これはあなたのシステム環境にあわせて変更しましょう。 pgbenchが終了すると、"including connections establishing" のところに数字が出てくるのでそれをチェックします。

なお、child_life_time が有効だと、serialize_accept は効果がありません。 serialize_accept を有効にしたい場合は、child_life_timeが 0 であることを確認してください。 pgpool-IIプロセスのメモリーリークなどの潜在的な問題を気にする場合は、 代わりにchild_max_connections を使ってください。 この制限は純粋に実装上の問題であり、将来はなくなるかもしれません。

このパラメータを変更した時には pgpool-II を再起動してください。

child_life_time

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

注意: このパラメータが0以外の場合、serialize_accept の効果はなくなります。

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

child_max_connections

各pgpool-II子プロセスへの接続回数がこの設定値を超えると、その子プロセスを終了します。 child_life_timeconnection_life_timeが 効かないくらい忙しいサーバで、 PostgreSQLバックエンドが肥大化するのを防ぐのに有効です。

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

client_idle_limit

前回クライアントから来たクエリから、client_idle_limit 秒越えても次の クエリが届かない場合は、クライアントへの接続を強制的に切断し、 クライアントからの次のコネクションを待つようにします。 この設定は、だらしないクライアントプログラムや、クライアントとpgpoolの間の TCP/IPコネクションが不調なことによって、 pgpoolの子プロセスが占有されてしまう問題を回避するのに役立ちます。 デフォルト値は 0(無効)です。このパラメータは、オンラインリカバリのセカンドステージでは無視されます。

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

enable_pool_hba

trueならば、pool_hba.confに従ってクライアント認証を行います。 詳細はクライアント認証(HBA)のためのpool_hba.conf設定方法を参照してください。

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

pool_passwd

md5 認証で用いる認証ファイルのファイル名を指定します。 デフォルト値は "pool_passwd" です。 空文字列("")を指定すると 認証ファイルの読込は無効になります。 詳細は認証・アクセス制御方式を参照してください。

このパラメータを変更した時には pgpool-II を再起動してください。

authentication_timeout

認証処理のタイムアウト時間を秒単位で指定します。0 を指定するとタイムアウトを無効にします。 authentication_timeout のデフォルト値は60です。

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

Logs

log_destination V3.1 〜

pgpool-IIは、stderrかsyslogのどちらかにログを書くことができます。デフォルトはstderrです。

注意:syslogを使う場合は、syslogデーモンの設定を変更する必要があります。

pgpool-IIは、syslog ファシリティ LOCAL0 から LOCAL7 までにログを書くことができます (syslog_facilityをご覧ください)。 しかし、ほとんどのデフォルトのsyslog設定は、そのようなメッセージを廃棄してしまいます。 そこで、syslogデーモンの以下のような設定が必要になります。

local0.*    /var/log/pgpool.log
print_timestamp

trueならばpgpool-IIのログにタイムスタンプを追加します。デフォルトはtrueです。

このパラメータを変更した時には pgpool-II を再起動してください。

print_user

trueならばpgpool-IIのログにセッションユーザ名を追加します。デフォルトはfalseです。

このパラメータを変更した時には pgpool-II を再起動してください。

log_line_prefix

ログの先頭に付加する文字列をprintfのようなスタイルで指定します。 「%」はエスケープ文字で、この後の文字は以下のように置換えをされて出力されます。 認識できないエスケープ指定は無視されます。それ以外の文字はそのままログに出力されます。 log_line_prefixのデフォルトは '%t: pid %p: 'で、タイムスタンプとプロセスIDを印字します。 これは、3.4より前のバージョンとの互換性を保つためです。

エスケープ文字効果
%aクライアントのアプリケーション名
%pプロセスID (PID)
%Pプロセス名
%tタイムスタンプ
%dデータベース名
%uユーザ名
%lプロセスごとのログ行番号
%%'%' 文字自身

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

log_error_verbosity

ログメッセージの詳細度を指定します。 TERSE, DEFAULT, VERBOSEの順に詳細になります。 TERSE では、DETAIL, HINT, CONTEXTの各メッセージが含まれなくなります。

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

log_connections

trueならば、全てのクライアント接続をログへ出力します。

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

client_min_messages

クライアントに送る最低メッセージレベルを設定します。 DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR が指定でき、左に行くほど冗長です。 デフォルトは NOTICE です。

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

log_min_messages

ログに書き出す最低メッセージレベルを設定します。 DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, PANIC が指定でき、左に行くほど冗長です。 デフォルトは WARNING です。

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

log_hostname

trueならば、psコマンドでの状態表示時にIPアドレスではなく、ホスト名を表示します。 また、log_connectionsが有効な場合にはログにホスト名を出力します。

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

log_statement

trueならばSQL文をログ出力します。この役目はPostgreSQLのlog_statementオプションと似ていて、 デバッグオプションがないときでも問い合わせをログ出力して調べることができるので便利です。

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

log_per_node_statement V2.3 〜

log_statementと似ていますが、DBノード単位でログが出力されるので、 レプリケーションや負荷分散の確認が容易です。

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

syslog_facility V3.1 〜

syslogが有効な場合、このパラメータによってsyslogの「ファシリティ」を設定します。 LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7から選択します。 デフォルトは LOCAL0 です。 併せてsyslogデーモンのドキュメントもご覧ください。

syslog_ident V3.1 〜

syslogが有効な場合、このパラメータによってsyslogのメッセージにあらわれるプログラム名を設定します。 デフォルトは"pgpool"です。

debug_level V3.0 〜

デバッグメッセージの詳細レベル。0でデバッグメッセージの出力なし。 1以上でデバッグメッセージを出力します。 数字が大きければより詳細なメッセージが出力されるようになります (3.0では今のところメッセージの詳細度は変りません)。 デフォルト値は0です。

File locations

pid_file_name V2.2 〜

pgpool-IIのpid file(プロセスIDを格納したファイル)のフルパス名です。 デフォルト値は'/var/run/pgpool/pgpool.pid'です。

このパラメータを変更した時には pgpool-II を再起動してください。

logdir

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

Connction pooling

connection_cache

trueならPostgreSQLへのコネクションをキャッシュします。デフォルトはtrueです。

このパラメータを変更した時には pgpool-II を再起動してください。

Health check

health_check_timeout

pgpool-IIはサーバ障害やネットワーク障害を検知するために、定期的にバックエンドに接続を試みます。 これを「ヘルスチェック」と言います。障害が検知されると、フェイルオーバや縮退運転を試みます。

この パラメータは、ネットワークケーブルが抜けた際などにヘルスチェックが長時間待たされるのを防ぐための タイムアウト値を秒単位で指定します。 デフォルトは20秒です。0を指定するとタイムアウト処理をしません (すなわち TCP/IP のタイムアウトまで待つことになります)。

なお、ヘルスチェックを有効にすると、ヘルスチェックのための余分の接続が1つ必要になりますので、 PostgreSQLのpostgresql.confの設定項目のmax_connectionsを少くとも1増やすようにしてください。

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

health_check_period

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

health_check_user

ヘルスチェックを行うためのPostgreSQLユーザ名です。 このユーザ名はPostgreSQLに登録済みでなければなりません。 さもないと、ヘルスチェックがエラーとなります。

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

health_check_password V3.1 〜

ヘルスチェックを行うためのPostgreSQLパスワードです。

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

health_check_database V3.5 -

ヘルスチェックを行う対象のデータベース名を指定します。 デフォルトは '' で、この場合最初に「postgres」データベースを試し、 それに接続できない場合は「template1」データベースを試します。これはpgpool-II 3.4以前の挙動と同じです。

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

health_check_max_retries V3.2 〜

ヘルスチェックに失敗した後(したがってフェイルオーバする前に)リトライする回数を指定します。 この設定は動作にむらのあるネットワーク環境において、マスタが正常であるにも関わらず たまにヘルスチェックが失敗することが予想される場合に有用です。 デフォルト値は0で、この場合はリトライをしません。 この設定を有効にする場合は、併せてfail_over_on_backend_errorを offにすることをお勧めします。

health_check_max_retriesを変更した場合は、pgpool.confの再読込が必要です。

health_check_retry_delay V3.2 〜

ヘルスチェックのリトライの間の秒数を指定します(health_check_max_retries > 0でなければ有効になりません)。 0を指定すると、待ちなしに直ちにリトライします。

health_check_retry_delayを変更した場合は、pgpool.confの再読込が必要です。

connect_timeout V3.4 -

connect()システムコールを使ってバックエンドに接続する際のタイムアウト値をミリ秒単位で指定します。 デフォルトは10000ミリ秒(10秒)です。不安定なネットワークを使わなければならない場合は、この値を大きくすると良いでしょう。 0を指定すると、タイムアウトしません。

connect_timeoutを変更した場合は、pgpool.confの再読込が必要です。

search_primary_node_timeout V3.3 -

このパラメータはフェイルオーバが起きた時にプライマリノードを検索する際のタイムアウト時間を秒単位で指定します。 デフォルト値は10です。 pgpool-IIは、フェイルオーバの際にここで指定した時間プライマリノードを検索し続けます。 0を指定すると、永久に検索し続けます。 このパラメータはストリーミングレプリケーションモードで運用している場合以外は無視されます。

search_primary_node_timeoutを変更した場合は、pgpool.confの再読込が必要です。

Failover and failback

failover_command

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

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

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

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

failback_command

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

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

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

follow_master_command V3.1 〜

マスターノードのフェイルオーバー後に実行するコマンドを指定します。 これは、マスタースレーブモードでストリーミングレプリケーション構成の場合のみ有効です。 特殊文字を指定すると、pgpool が必要な情報に置き換えてコマンドを実行します。

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

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

空文字列以外を指定すると、マスターノードのフェイルオーバー後に新しいマスター以外のすべてのノードは切り離され、 クライアントから再び接続を受け付けるために子プロセスの再起動が行われます。 その後、切り離されたそれぞれのノードに対してfollow_master_commandに指定したコマンドが実行されます。 通常は、ここに pcp_recovery_node コマンドを組み込んだシェルスクリプトなどを 指定し、新しいマスターからスレーブをリカバリするために使用します。

fail_over_on_backend_error V2.3 〜

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

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

Load balancing mode

ignore_leading_white_space

trueならば、load balanceの際にSQL文行頭の空白を無視します(全角スペースは無視されません)。 これは、DBI/DBD:Pgのように、勝手に行頭にホワイトスペースを追加するようなAPIを使い、 ロードバランスしたいときに有効です。

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

allow_sql_comments V3.4 〜

onならば、負荷分散やクエリキャッシュができるかどうかの判定の際にSQLコメントを無視します。 offならば、その判定に影響を与えます(3.4より前のバージョンの動作です)。

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

Backends

backend_hostname

使用するPostgreSQLサーバのホスト名を指定します。 pgpool-IIは、このホスト名を使ってPostgreSQLと通信します。

TCP/IPを使用する場合、ホスト名またはIPアドレスを指定できます。 "/"で始まる文字列を指定すると、TCP/IPではなく、UNIXドメインソケットを使用され、 ディレクトリ名とみなしてそこにソケットファイルが作成されることになります。 空文字('')を指定すると、/tmp下に作成したUNIXドメインソケットで接続します。

実際には、"backend_hostname"の後に0, 1, 2...と数字を付加して使用する複数 のPostgreSQLを区別します(たとえばbackend_hostname0)。 この数字のことを「DBノードID」と呼び、0から開始します。 DBノードID == 0のPostgreSQLは、特別に「マスターDB」と呼ばれます。 複数のDBノードを運用している場合、条件によってはマスターDBがダウンしても運用を続けることができます。 この場合は、稼働中かつDBノードIDがもっとも若いものが新しいマスターDBになります。

ただし、ストリーミングレプリケーションモードで運用している場合は、 DBノードIDが0のノードには特別な意味はなく、プライマリノードかどうかが問題になります。 詳細はStreaming Replicationへの対応をご覧ください。

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 を再起動してください。

backend_flag V3.1 〜

バックエンド単位での様々な挙動を制御するフラグです。 実際には、"backend_flag"の後に数字を付けて、どのバックエンドのフラグか指定します。

例: backend_flag0

複数のフラグを"|"で連結して指定することができます。 現在以下のものがあります。

ALLOW_TO_FAILOVER フェイルオーバやデタッチが可能になります。これがデフォルトの動作です。 DISALLOW_TO_FAILOVERと同時には指定できません。
DISALLOW_TO_FAILOVER フェイルオーバやデタッチが行われません。 HeartbeatやPacemakerなどのHA(High Availability)ソフトでバックエンドを二重化しているなどの事情で、 pgpool-II側でフェイルオーバの制御をして欲しくないときなどに指定します。 ALLOW_TO_FAILOVERと同時には指定できません。

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

SSL

ssl V2.3 〜

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

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

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

ssl_key V2.3 〜

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

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

ssl_cert V2.3 〜

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

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

ssl_ca_cert

1 つ以上の CA ルート証明書を格納している PEM 形式ファイルのパスを指定します。 このファイルはバックエンドサーバ証明書の検証に用いられます。 このオプションは OpenSSL の verify(1) コマンドにおける -CAfile オプションと同様の機能を提供します。

デフォルトでは値が設定されておらず検証は行われません。 このオプションが設定されていない場合においても、ssl_ca_cert_dir オプション が設定されている場合には検証が行われます。

ssl_ca_cert_dir

PEM 形式の CA 証明書ファイルを格納しているディレクトリのパスを指定します。 これらのファイルはバックエンドサーバ認証の検証に用いられます。 このオプションは OpenSSL の verify(1) コマンドにおける -CApath オプションと同様の機能を提供します。

デフォルトでは値が設定されておらず検証は行われません。 このオプションが設定されていない場合においても、ssl_ca_cert オプション が設定されている場合には検証が行われます。

Other

relcache_expire V3.1 〜

リレーションキャッシュの寿命を秒単位で指定します。 0を指定すると、キャッシュの寿命の管理は行わず、プロセスが生きているか、 キャッシュが溢れるまでは有効になります(デフォルトの動作)。

リレーションキャッシュは、PostgreSQLのシステムカタログに対する問い合わせを保存しておくものです。 問い合わせる内容は、テーブルの構造、テーブルが一時テーブルかどうかなどがあります。 キャッシュはpgpoolの子プロセスのローカルメモりに保管されています。

もしALTER TABLEが発行されると、テーブルの構造が変わる場合があり、 リレーションキャッシュの内容と一致しなくなる恐れがあります。 relcache_expireにより、その危険性をコントロールできるようになります。

relcache_size V3.2 〜

リレーションキャッシュのサイズを指定します。 デフォルトは256です。

"pool_search_relcache: cache replacement happend"

のようなメッセージがログに頻繁に出る場合は、この数字を大きくしてください。

check_temp_table V3.2 〜

もしonなら、SELECTに含まれるテーブルが一時テーブルかどうかのチェックを行います。 このチェックは、primary/masterのシステムカタログへのアクセスを発生させ、それなりに負荷を上げます。 もし一時テーブルを使っていないということが確かで、primary/masterの負荷を少しでも下げたいのであれば、 offにすることができます。デフォルトはonです。

check_unlogged_table V3.4 〜

もしonなら、SELECTに含まれるテーブルがunloggedテーブルかどうかのチェックを行います。 このチェックは、primary/masterのシステムカタログへのアクセスを発生させ、それなりに負荷を上げます。 もしunloggedテーブルを使っていないということが確かで(たとえばPostgreSQLのバージョンが9.0かそれより前)、 primary/masterの負荷を少しでも下げたいのであれば、 offにすることができます。デフォルトはonです。

SSL証明書の生成

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

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

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

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

rawモードに加え、コネクションプーリングが利用できるようになります。 コネクションプールモードを有効にするには、 connection_cache をonにします。 以下の設定項目がコネクションプールの動作に影響を与えます。

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.2ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT
8.3以降ABORT; DISCARD ALL
  • 「ABORT」は、PostgreSQL 7.4以上ではトランザクションブロックの中にいない場合には発行されません。

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

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

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

レプリケーションモード

レプリケーションを有効にするモードです(設定ファイルの雛形はpgpool.conf-replication)。 rawモード、コネクションプールモードに加え、以下を設定します。

replication_mode

レプリケーションモードで動作させる場合はtrueを指定してください。デフォルト値はfalseです。

このパラメータを変更した時には pgpool-II を再起動してください。

load_balance_mode

trueを指定するとレプリケーションモードまたはマスタースレーブモードの際に、 SELECT文をロードバランスして検索性能を向上させることができます。デフォルト値はfalseです。

このパラメータを変更した時には pgpool-II を再起動してください。

replication_stop_on_mismatch

各DBノードから送られてくるパケットの種類が不一致になった場合に、DBノードを切り放して縮退運転に入ります。

良くあるケースとしては、replicate_select が指定されていて SELECTが各DBノードで実行されているときに、 検索結果行数が一致しないなど、があります(これに限定されるものではありません。 たとえばあるDBノードでUPDATEが成功したのに、他のDBノードでは失敗した場合が一例です)。 ただし、pgpoolはパケットの中身まではチェックしていないので、SELECT結果のデータ内容が異なっていても、 縮退は起きないことに注意してください。

縮退対象のDBノードは「多数決」で少数派になったものが対象になります。 もし多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、 それ以外のグループに所属するDBノードが切り放しの対象になります。

このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。 デフォルト値はfalseです。

failover_if_affected_tuples_mismatch V3.0 〜

各DBノードで実行されたINSERT/UPDATE/DELETEの結果行数が不一致になった場合に、 DBノードを切り放して縮退運転に入ります。

縮退対象のDBノードは「多数決」で少数派になったものが対象になります。 もし多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、 それ以外のグループに所属するDBノードが切り放しの対象になります。

このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。 デフォルト値はfalseです。

white_function_list V3.0 〜

データベースに対して更新を行なわない関数名をコンマ区切りで指定します。 このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象とはならず、 レプリケーションモードにおいてはすべてのDBノードで実行されます。 (マスタースレーブモードにおいては、マスター(primary)DBノードにのみ送信されます)。

関数名には正規表現を使うことができます。指定した各表現に ^ と $ をつけた形で使われます。 たとえば、読み出しのみの関数が"get_"あるいは"select_"で始まるならば、以下のような指定が可能です。

white_function_list = 'get_.*,select_.*'
black_function_list V3.0 〜

データベースに対して更新を行なう関数名をコンマ区切りで指定します。 このリストに含まれる関数呼び出しを含むSELECTは、負荷分散の対象とはならず、 レプリケーションモードにおいてはすべてのDBノードで実行されます。 このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象となります。

関数名には正規表現を使うことができます。指定した各表現に ^ と $ をつけた形で使われます。 たとえば、読み出しのみの関数が"set_"、"update_"、"delete_"あるいは"insert_"で始まるならば、 以下のような指定が可能です。

black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'

white_function_listとblack_function_listの両方を空以外にすることはできません。 どちらか一方のみに関数名を指定します。

pgpool-II 3.0より前のバージョンでは、固定でnextvalとsetvalが書き込みを行なう関数として認識されていました。 それと同じ動作を行なわせるには、以下のようにwhite_function_listとblack_function_listを指定します。

white_function_list = ''
black_function_list = 'nextval,setval,lastval,currval'

上の例では、nextvalとsetvalに加え、lastvalとcurrvalが追加されていることに注意してください。 lastvalとcurrvalは書き込みを行う関数ではありませんが、これらの関数が負荷分散されることによって、 エラーが発生するのを未然に防ぐことができます。 black_function_listに含まれる関数は負荷分散されないからです。

replicate_select

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

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

replicate_selectがtrue YN
load_balance_modeがtrue anyYN
SELECTが明示的なトランザクションブロックの内側にある anyYNany
「トランザクション分離レベルがSERIALIZABLE」または
「トランザクション内で更新を伴うクエリが実行されている」
anyYNanyany
insert_lock

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

INSERT INTO ...

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

に書き換えなければなりません。 insert_lockをtrueにすると自動的にトランザクションの開始、テーブルロック、トランザクションの終了を 行ってくれるので、こうした手間を省くことができます (すでにトランザクションが開始されている場合はLOCK TABLE...だけが実行されます)。

pgpool-II 2.2以降

テーブルがSERIAL列を持つかどうか自動判別するため、 SERIAL列がなければ決してテーブルをロックしません。

pgpool-II 3.0.4までの3.0シリーズ

対応するシーケンステーブルに対して行ロックをかけることで排他制御を行ないます。 それ以前のバージョンと比べると、VACUUM(autovacuumを含む)とのロック競合がなくなるメリットがあります。

しかし、これは他の問題を引き起こします。 トランザクション周回が起きた後、シーケンステーブルに対する行ロックはPostgreSQLの内部エラー (詳細には、トランザクション状態を保持するpg_clogへのアクセスエラー)を起こします。 これを防ぐため、PostgreSQLのコア開発者はシーケンステーブルに対する行ロックを許可しないことを決定しました。 これはもちろんpgpool-IIを動作不能にします(修正されたPostgreSQLはバージョン 9.0.5, 8.4.9, 8.3.16そして8.2.22としてリリースされるでしょう)。

pgpool-II 3.0.5以降

新しいPostgreSQLがシーケンステーブルに対するロックを許可しなくなったため、 pgpool_catalog.insert_lockテーブルに対して行ロックをかけることで排他制御を行ないます。 したがって、pgpool-II経由でアクセスするすべてのデータベースにinsert_lockテーブルを あらかじめ作成しておく必要があります。 詳細はinsert_lockテーブルの作成の項目をご覧ください。

もし、insert_lockテーブルが存在しない場合は、挿入対象のテーブルに対してロックを行います。 これは、pgpool-II 2.2と2.3シリーズのinsert_lockと同じ動作です。 また、過去のバージョンと互換性のあるinsert_lockを使用したい場合は、configureスクリプトで設定できます。 詳細はconfigureの実行の項目をご覧下さい。

なお、あまり必要ないかも知れませんが、コメントを利用して、この挙動を細かく制御することもできます。

  1. insert_lockをtrueにして、INSERT文の先頭に/*NO INSERT LOCK*/コメントを追加する。 このコメントがあると、テーブルロックは行われません(pgpool-II 3.0以降でも同様)。
  2. insert_lockをfalseにして、INSERT文の先頭に/*INSERT LOCK*/コメントを追加する。 このコメントがあると、このINSERT文に対してのみテーブルロックが行われます(pgpool-II 3.0以降でも同様)。

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

オンラインリカバリ中に起動するコマンド名を指定します。 このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。 コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にある コマンドやスクリプトのみを呼び出します。 例えば、recovery_1st_stage_command = 'sync-command' と設定してある場合、 $PGDATA/sync-command を起動しようとします。

recovery_1st_stage_command は次の4つの引数を受けとります。

  1. マスタ(プライマリ)データベースクラスタへのパス
  2. リカバリ対象のPostgreSQLのホスト名
  3. リカバリ対象のデータベースクラスタへのパス
  4. マスタデータベースクラスタのポート番号

recovery_1st_stage_command を実行している間は pgpool ではクライアン トからの接続を制限しません。参照や更新を行うことができます。

注意: recovery_1st_stage_command は、PostgreSQLから見ると、一つのSQLとして実行されます。PostgreSQLの statement_timeout を無効にするか、statement_timeout が recovery_1st_stage_command の実行時間よりも十分長くないと、コマンドの実行がPostgreSQLにより途中でキャンセルされてしまいます。 この場合の典型的な症状は、recovery_1st_stage_command の中で呼び出されるコマンド(たとえば rsync)がシグナル2を受け取って中断する、というものです。

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

recovery_2nd_stage_command

2 回目のオンラインリカバリ中に起動するコマンド名を指定します。 このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。 コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にある コマンドやスクリプトのみを呼び出します。 例えば、recovery_2nd_stage_command = 'sync-command' と設定してある場合、 $PGDATA/sync-command を起動しようとします。

recovery_2nd_stage_command は次の3つの引数を受けとります。

  1. マスタ(プライマリ)データベースクラスタへのパス
  2. リカバリ対象のPostgreSQLのホスト名
  3. リカバリ対象のデータベースクラスタへのパス

recovery_2nd_stage_command を実行している間は pgpool ではクライアントから 接続、参照、更新処理を一切受け付けません。 また、バッチ処理などによって接続しているクライアントが長時間存在している場合にはコマンドを起動しません。 新たな接続を制限し、現在の接続数が 0 になった時点 でコマンドを起動します。

注意: recovery_2nd_stage_command は、PostgreSQLから見ると、一つのSQLとして実行されます。 PostgreSQLの statement_timeout を無効にするか、statement_timeout が recovery_2nd_stage_command の実行時間よりも十分長くないと、コマンドの実行が PostgreSQLにより途中でキャンセルされてしまいます。 この場合の典型的な症状は、recovery_2nd_stage_command の中で呼び出されるコマンド(たとえば rsync)が シグナル2を受け取って中断する、というものです。

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

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 V2.2 〜

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

クライアントが忙しく、アイドル状態にならない場合はclient_idle_limit_in_recoveryを設定しても セカンドステージに移行できません。 この場合、client_idle_limit_in_recoveryに-1を設定すると、クライアントがビジーであっても ただちにクライアントへの接続を切断し、セカンドステージに移行することができます。

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

lobj_lock_table V2.3 〜

ラージオブジェクトのレプリケーションを行いたいときにロック管理に使うためのテーブル名を指定します。

このテーブルが指定されていて、ラージオブジェクトの作成要求がクライアントから送信され、 かつその要求の中にラージオブジェクトの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などの問い合わせがロードバランスされます。

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

なお、

/*REPLICATION*/ SELECT ...

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

SQLコメントの記述が負荷分散に影響を与えないようにするには、 allow_sql_commentsをonにします。

注意: JDBC ドライバなどのように、ドライバ内で autocommit の有効・無効のオプションがある場合、 autocommit を無効にすると、ドライバが内部で BEGIN コマンドを実行し、明示的なトランザクションが開始されます。 この場合、トランザクション内における上記のロードバランスの制限事項が適用されます。

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

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

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

レプリケーションモードにおいて、pgpoolはレプリケーション時に INSERT、UPDATE、DELETE の更新件数が すべてのノードが同じでない場合、 failover_if_affected_tuples_mismatch が falseならば、 意図的に構文エラーを起すSQLを送信することによって、トランザクションをアボートさせます。 trueならば、フェイルオーバが起きます。その際、以下のようなエラーメッセージが表示されます。

=# UPDATE t SET a = a + 1;
ERROR: pgpool detected difference of the number of update tuples Possible last query was: "update t1 set i = 1;"
HINT: check data consistency between master and other db node

ログには更に以下のように、更新行数が記録されます(この場合はDBノード0が0行、DBノード1が1行)。

2010-07-22 13:23:25 LOG:   pid 5490: SimpleForwardToFrontend: Number of affected tuples are: 0 1
2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Degenerate backends: 1
2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Number of affected tuples are: 0 1

マスタースレーブモード

master/slaveモードは、Slony-IやStreaming Replicationのような、 master/slave式のレプリケーションソフトにレプリケーションをまかせるモードです。

なお、スレーブの数は1である必要はありません。 実際には127個までのスレーブを持つことができます(スレーブの数は0でも構いません)。

このモードで使うためには、レプリケーションモードと同じように、 DBノードのホスト情報(backend_hostname, backend_port, backend_weight, backend_flag それにオンラインリカバリが必要ならば backend_data_directory)をセットし、 master_slave_modeload_balance_modeをtrueにします。

pgpool-IIは、レプリケーションされる必要のある問い合わせはマスターに送り、 その他の問い合わせを可能ならば負荷分散します。問い合わせによってマスターDBだけに問い合わせが送られる場合と、 DBノードの間でロードバランスされて問い合わせが送られる場合があります。

マスタスレーブモードでは、一時テーブルの作成、更新、検索はマスタノードでのみ実行されます。 SELECTをマスタだけで実行するように強制することができます。 このためには、/*NO LOAD BALANCE*/ コメントをSELECTに前に挿入しなければなりません。

マスタースレーブモードでは、pgpool.confのreplication_modeをfalseに、 master_slave_mode をtrueにします(同時にtrueにはできません)。 また、'master_slave_sub_mode'を指定します。 これは、'slony'(デフォルト)か、'stream'です。

'slony'はSlony-Iを利用する時に指定します。 'stream'は、PostgreSQL組み込みのStreaming Replicationを利用するときに指定します。

Slony-Iを使う場合の設定ファイルの雛形はpgpool.conf.sample-master-slaveです。 Streaming Replicationを使う場合の雛形はpgpool.conf.sample-streamです。

このパラメータを変更した時には pgpool-II を再起動してください。

マスタースレーブモードでも、DB書き込みを行なう関数の呼び出しを含むSELECTを負荷分散の対象から外す指定を white_function_listblack_function_listで行なうことができます。 詳細はwhite_function_listの項をご覧下さい。

Streaming Replicationへの対応 V3.1 〜

前述のように、マスタスレーブモードで、'master_slave_sub mode'に 'stream'を指定すると、PostgreSQL 9.0から利用可能になったStreaming Replicationに対応します (pgpool-IIでは、今のところ、Streaming ReplicationとHot Standbyを併用することを前提にしています)。 このモードでは、以下の設定項目も利用できます。

delay_threshold V3.0 〜

スタンバイサーバへのレプリケーションの遅延許容度をバイト単位で指定します。 pgpool-IIは、スタンバイサーバの遅延がこの値を超えた場合には、 負荷分散が有効であってもそのDBノードにSELECTを送信せず、プライマリサーバに送るようにします。 delay_thresholdが0の場合は、遅延のチェックを行ないません。 また、delay_thresholdが指定されていても、sr_check_periodが無効(=0)ならば、 やはりこの機能は働きません。 デフォルト値は0です。

このパラメータは設定ファイルの再読込によって変更できます。

sr_check_period V3.1 〜

ストリーミングレプリケーションの遅延チェックの間隔を秒単位で指定します。 デフォルト値は0で、これはチェックを行わないことを意味します。

このパラメータは設定ファイルの再読込によって変更できます。

sr_check_user V3.1 〜

ストリーミングレプリケーションの遅延チェックを行うユーザ名を指定します。 このユーザは、すべてのバックエンドに存在しなければなりません。 さもなければエラーになります。 sr_check_userとsr_check_passwordは、sr_check_periodが0であっても 指定が必要です。pgpool-IIは、どのサーバがprimaryサーバであるのかを調べるために、 PostgreSQLバックエンドに関数呼び出しのリクエストを送ります。 そのセッションでsr_check_userとsr_check_passwordが使われるからです。

このパラメータは設定ファイルの再読込によって変更できます。

sr_check_password V3.1 〜

ストリーミングレプリケーションの遅延チェックを行うユーザに対するパスワードをを指定します。 パスワードが必要なければ空文字('')を指定します。

このパラメータは設定ファイルの再読込によって変更できます。

sr_check_database V3.5 -

ストリーミングレプリケーションの遅延チェックを行う対象のデータベース名を指定します。 デフォルトは「postgres」です(これは3.4以前のpgpool-IIが固定の値として使っていたデータベース名です)。

このパラメータは設定ファイルの再読込によって変更できます。

log_standby_delay V3.0 〜

レプリケーションの遅延状況をログする条件を指定します。 'none'を指定すると、ログを出力しません。 'always'ならレプリケーションの遅延チェックを実行するたびに必ず出力します。 'if_over_threshold'を指定すると、delay_thresholdを超えたときだけ ログが出力されます。 デフォルト値は'none'です。

このパラメータは設定ファイルの再読込によって変更できます。

なお、レプリケーションの遅延状況は show pool_status コマンドでも確認できます。 項目名は"standby_delay#"です(#はDBノードIDです)。

Streaming Replicationでのフェイルオーバ

Streaming replicationを利用したマスタスレーブモードでは、PrimaryやStandbyノードが停止した場合に、 レプリケーションモードと同じように自動フェイルオーバを行なわせることができます。 特に何も設定しなくても、停止したノードを自動的に切り放すことができますが、Streaming replicationでは、 「トリガファイル」を作成することにより、Standbyノードを、リカバリモードから更新問い合わせを受け付ける 通常のPostgreSQLの動作モードに自動変更することができます。 これを利用して、フェイルオーバコマンドを併用して、Primaryノードがダウンしたときに、 Standbyノードが自動的にとって代るような設定を行なうことができます。

注意: 複数のStandbyノードを利用している場合、この設定を行なうときは、 delay_thresholdを設定して、 他のStandbyに振り分けられたSELECTが古いデータを取得しないようにしておくことをお勧めします。 また、1台目のStandbyノードがPrimaryにとって代ったのちにダウンしてしまったケースで、 2台目のStandbyが更に取って代わるとデータに不整合がおきるので、そのような設定は行なわないようにしてください。

フェイルオーバの設定手順を示します。

  1. フェイルオーバ用のスクリプトを適当な場所(ここでは/usr/local/pgsql/bin)に配置して、実行権限を与えておきます。
    $ cd /usr/loca/pgsql/bin
    $ cat failover_stream.sh
    #! /bin/sh
    # Failover command for streming replication.
    # This script assumes that DB node 0 is primary, and 1 is standby.
    #
    # If standby goes down, does nothing. If primary goes down, create a
    # trigger file so that standby take over primary node.
    #
    # Arguments: $1: failed node id. $2: new master hostname. $3: path to
    # trigger file.
    
    failed_node=$1
    new_master=$2
    trigger_file=$3
    
    # Do nothing if standby goes down.
    if [ $failed_node = 1 ]; then
        exit 0;
    fi
    
    # Create trigger file.
    /usr/bin/ssh -T $new_master /bin/touch $trigger_file
    
    exit 0;
    
    chmod 755 failover_stream.sh
    
  2. pgpool.confの、failover_commmandを設定します。
    failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
    
  3. standbyノードのrecovery.confを設定します。 recovery.confのサンプルは PostgreSQLのインストールディレクトリ下の "share/recovery.conf.sample"にあります。 これをstanndbyノードのデータベースクラスタ下に"recovery.conf"としてコピーしておきます。 そして、以下の項目を設定します。
    standby_mode = 'on'
    primary_conninfo = 'host=primary_hostのホスト名 user=postgres'
    trigger_file = '/tmp/trigger_file0'
    
  4. primaryノードのpostgresql.confを設定します。 以下は例ですので、必ず実際に合わせて調整してください。
    wal_level = hot_standby
    max_wal_senders = 1
    
  5. primaryノードのpg_hba.confを設定します。 以下は例ですので、必ず実際に合わせて調整してください。
    host    replication    postgres        192.168.0.10/32        trust
    

primaryとstandbyのPostgreSQLを起動すれば、Streaming replicationが開始されます。 そして、primaryノードがダウンしたときに、自動的にstandbyノードが通常のPostgreSQLとして立ち上がり、 更新問い合わせを受け付けるようになります。

Streaming Replicationでのクエリ振り分け

Streaming replicationとHot Standbyを利用している環境では、primaryノードに送ってよい問い合わせ、 standbyに送ってもよい問い合わせ、両方に送らなければならない問い合わせを厳密に管理する必要があります。 pgpool-IIのStreaming Replicationモードは、こうした振り分けを自動的に行ないます。 ここでは、そのロジックについて説明します。

まず、問い合わせの種類によって以下のように分けられます。

明示的なトランザクションでは、以下のようになります。

問い合わせが、拡張問い合わせモードで実行される場合は、問い合わせのparse段階で、 問い合わせが負荷分散可能かどうかで送信先が決まります。 その際の判断ルールは、通常のSQLと同じです。 たとえば問い合わせがINSERTならば、Primaryサーバで実行される、という具合です。 parseに続くbind, describe, executeも同じDBノードで実行されます。

[注: SELECTが負荷分散されて Standby ノードで parseが実行されてから更新クエリが来た場合は、 そのSELECTはPrimaryノードで実行されなければなりません。 そのため、同じSELECTが再度Primaryノードでパースされることになります。]

最後に、pgpool-IIのパーサが構文エラーと判断した問い合わせはPrimaryノードだけに送られます。

データベース名とアプリケーション名によって細かく検索問い合わせの負荷分散を指定することもできます。

database_redirect_preference_list V3.4 〜

データベース名によって負荷分散をしたいノード番号を、"データベース名:ノード番号"で指定します。 たとえば、"test:1"と書くと、"test"という名称のデータベースに接続すると、 常にノード番号1に検索問い合わせを送信するようになります。"データベース名:ノード番号"のペアを カンマ(,)で区切って複数指定することもできます。データベース名には、正規表現を指定することできます。 ノード番号に"primary"と書くと、常にプライマリノードを指定したことになります。 ノード番号に"standby"と書くと、スタンバイノードのうちどれかをバックエンドウェイトに応じてランダムに選択します。

例を示します。

database_redirect_preference_list = 'postgres:primary,mydb[01]:1,mydb2:standby'

この例では、検索問い合わせが、postgresデータベースはプライマリノード、mydb0とmydb1はノード1、mydb2はスタンバイノードに負荷分散します。

このパラメータは設定ファイルの再読込によって変更できます。

app_name_redirect_preference_list V3.4 〜

アプリケーション名によって負荷分散をしたいノード番号を、"アプリケーション名:ノード番号"で指定します。 アプリケーション名とは、クライアントが接続時に指定する名称で、PostgreSQL 9.0以降で使用できます。

注意: JDBCドライバのpostgresql-9.3以前のバージョンでは、JDBCドライバの"ApplicationName" と "assumeMinServerVersion=9.0"オプションを指定してもスタートアップパケットの中にapplication_nameを含まないため、 この機能を利用できません。 postgresql-9.4 以降のJDBCドライバをお使いください。

たとえばpsqlコマンドのアプリケーション名は"psql"です。 pgpool-IIは、クライアントが接続に送信するスタートアップパケットに含まれるアプリケーション名だけを認識します。 接続後に変更されたアプリケーション名は認識されません。

アプリケーション名の指定はdatabase_redirect_preference_listと同様です。 正規表現も使用できます。

例を示します。

app_name_redirect_preference_list = 'psql:primary,myapp1:1,myapp2:standby'

この例では、検索問い合わせが、psqlではプライマリノード、myapp1はノード1、myapp2はスタンバイノードに負荷分散します。

app_name_redirect_preference_listは、database_redirect_preference_listよりも優先されます。 以下の例を見てください。

database_redirect_preference_list = 'bigdb:primary'
app_name_redirect_preference_list = 'myapp:2'

通常、bigdbというデータベースに接続するアプリケーションはプライマリノードに検索問い合わせを送信します。 しかし、myappというアプリケーションは、同じbigdbに接続しても常にノード2に検索問い合わせするようになります。 たとえば、myapp2が非常に重いSELECTを実行する分析アプリケーションで、ノード2を分析処理専用にしたい場合に有効です。

このパラメータは設定ファイルの再読込によって変更できます。

Streaming Replicationでのオンラインリカバリ

Streaming replicationを利用したマスタスレーブモードでは、 レプリケーションモードと同じようにオンラインリカバリが利用できます。 primaryサーバをマスタとし、standbyサーバをリカバリします。 primaryサーバが動作しているのがこの方法の前提条件ですので、 primaryサーバが停止している状態ではオンラインリカバリはできません。 primaryサーガ停止している状態からの復旧は、すべてのDBノードとpgpool-IIを停止させて手動で実施しなければなりません。

  1. リカバリ処理を実行するユーザ recovery_user を設定します。 通常、postgresユーザとなります。
    recovery_user = 'postgres'
    
  2. recovery_password を設定します。 これは、recovery_user がDBにログインするときに使うパスワードです。
    recovery_password = 't-ishii'
    
  3. recovery_1st_stage_command を設定します。

    ここで指定するファイルは、primaryサーバからベースバックアップを取得し、 standbyサーバにリストアするものでなければなりません。 recovery_1st_stage_command は、primaryのPostgreSQLから、recovery_userの権限で起動され、 その時に引数を受けとります。 詳細は、recovery_1st_stage_commandの設定項目をご覧ください。

    このスクリプトファイルは、primaryのデータベースクラスタ下に配置し、実行権限を与えておきます。 サンプルとして、primary/standbyそれぞれ一台構成の場合のスクリプト (basebackup.sh)を示します。 このスクリプトでは、recovery_user がパスワードなしでリカバリ対象の standbyノードにログインできることを前提にしているので、 あらかじめsshの設定を行なっておく必要があります。

    recovery_1st_stage_command = 'basebackup.sh'
    
  4. recovery_2nd_stage_command は、空のままで構いません。
    recovery_2nd_stage_command = ''
    
  5. オンラインリカバリを実施するための PostgreSQL の C 言語関数やSQL関数を各DBノードにインストールします。
    # cd pgpool-II-x.x.x/sql/pgpool-recovery
    # make
    # make install
    # psql -f pgpool-recovery.sql template1
    
  6. オンラインリカバリが終了したあと、pgpool-IIは、停止していたDBノードのPostgreSQLを起動します。 そのためのスクリプトを、各DBノードのDBクラスタにインストールします。

    スクリプトのサンプルがソースコードの"sample"ディレクトリに含まれているので、 それを利用してください。 このサンプルの中では、PostgreSQLの起動をpg_ctlコマンドで行っており、pg_ctlコマンドへのパスが記述されています。 デフォルトでは/usr/local/pgsql/bin/pg_ctlとなっているので、お使いの環境に合わせて修正してください。

    なお、このスクリプトはsshを使用しますので、少くとも、primaryのDBノードから、standbyのDBノードに対して、 recovery_userでパスワードなしでsshが利用できることが必要です。 必要ならばあらかじめ設定しておいてください。

以上でオンラインリカバリの設定が終了しました。 standbyノードを停止した状態で、pcp_recovery_node を利用するか、 pgpoolAdminの「リカバリ」ボタンでオンラインリカバリが出来るようになったはずです。 うまくいかない場合は、pgpool-IIのログ、primaryサーバ、standbyサーバのログを確認してください。

参考までに、ストリーミングレプリケーションでのオンラインリカバリの内部処理の流れを説明します。

  1. pgpool-IIは、primaryサーバにユーザ: recovery_user, パスワード: recovery_password で template1データベースに接続します。
  2. primaryサーバで、pgpool_recovery関数を実行します。
  3. pgpool_recovery関数は、recovery_1st_stage_command で 指定されたスクリプトを実行します。

    なお、PostgreSQLは、データベースクラスタディレクトリ中で関数を実行します。 よって、pgpool_recovery関数もprimaryサーバのデータベースクラスタディレクトリ中で 関数を実行されることに注意してください。

  4. primaryサーバで、pgpool_remote_start関数を実行します。

    この関数は、primaryサーバのデータベースクラスタディレクトリ中にある pgpool_remote_startという名前のスクリプトを起動し、 ここからssh経由でリカバリ対象のstandbyサーバのPostgreSQLをpg_ctlコマンドを使って起動します。 起動はバックグラウンドで行われ、起動できたかどうかは次のステップで確認されます。

  5. pgpool-IIから、standbyサーバのPostgreSQLのpostgresデータベース (postgresデータベースがない場合はtemplate1データベース)に、 ユーザ: recovery_user, パスワード: recovery_password でtemplate1データベースに接続を試みます。

    リトライは、recovery_timeout秒間行われます。 PostgreSQLの起動に成功したら、次のステップに移ります。

  6. failback_commandが空でない場合は、 pgpool-IIの親プロセスは指定されたスクリプトを起動します。
  7. failback_commandが終了したら、pgpool-IIの子プロセスをすべて再起動します。

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

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

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

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

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

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

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

ここで説明された機能、制限はクライアントと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"を参考にしてく ださい。

インメモリクエリキャッシュの設定方法 V3.2 〜

pgpool-IIでは、すべてのモードでインメモリクエリキャッシュを利用することができます。 上記のクエリキャッシュと違い、メモリ上にキャッシュが置かれるので高速であるばかりでなく、 データが更新されると自動的にキャッシュが無効になり、pgpool-IIの再起動の必要がありません。

インメモリクエリキャッシュは、問い合わせのSELECT文(拡張問い合わせの場合は更にバインドパラメータ)と 検索結果をペアで記録し、2回目以降に同じSELECT文が発行された場合に、キャッシュから結果を返します。 通常のSELECT文処理と違って、PostgreSQLにアクセスしないだけでなく、 pgpool内部のSQLパース処理などを経由しないため、非常に高速です。

反面、キャッシュにヒットしない場合は通常のSELECT文の処理に加えてキャッシュ処理のオーバヘッドが生じるので、 かえって遅くなります。 また、あるテーブルが更新された場合、そのテーブルを参照している すべてのキャッシュが自動削除されるため(自動削除しない設定も可能)、 更新処理が多いシステムではインメモリクエリキャッシュを有効にしていることでかえって遅くなります。 キャッシュのヒット率が70%以下の場合は、インメモリクエリキャッシュの設定を有効にしないほうが良いでしょう。

インメモリクエリキャッシュの制限事項

インメモリクエリキャッシュの有効化

インメモリクエリキャッシュを有効にするには、pgpool.confの"memory_cache_enabled"を有効にします。

memory_cache_enabled = true

キャッシュストレージの選択

メモリキャッシュのストレージには、共有メモリとmemcachedのどちらかを 選択することができます(併用はできません)。

共有メモリを使用するクエリキャッシュは高速で、memcachedの立ち上げも必要なく、手軽に利用できます。 ただし、共有メモリサイズの上限によって保存できるキャッシュの量に制限があります。 memcachedをキャッシュストレージに使用する場合は、ネットワークアクセスのオーバヘッドがあるものの、 比較的自由にキャッシュメモリの大きさを設定できます。

共有メモリを利用する場合は"memqcache_method"に 'shmem'、Memcachedを利用する場合は'memcached'と設定します。 デフォルトは、'shmem'です。

キャッシュが作成される場合と作成されない場合

すべてのSELECT(もしくはWITH)がインメモリクエリキャッシュの対象になるわけではありません。 キャッシュとDBの一貫性を極力保つために、キャッシュされないケースがあります。以下それを列挙します。

キャッシュがあっても参照されない場合

インメモリクエリキャッシュが存在しても、そのキャッシュが利用されないケースがあります。 以下それを列挙します。

共通設定項目

キャッシュストレージを共有メモリにする場合でも、memcachedにする場合でも、共通で設定する項目を説明します。

memqcache_expire V3.2 〜

クエリキャッシュの寿命を秒単位で設定します。デフォルト0です。 0を指定すると寿命が無限大になり、関連テーブルが更新されるまではキャッシュが有効になります。 なお、この設定は、memqcache_auto_cache_invalidationとは 独立です。

memqcache_auto_cache_invalidation V3.2 〜

trueならば関連するテーブルが更新されるとキャッシュを無効化します。 falseならばテーブルが更新されてもキャッシュを無効化しません。 デフォルト値はonです。 なお、この設定はmemqcache_expireの設定とは独立です。

white_memqcache_table_list V3.2 〜

VIEW やunloggedテーブルを使っているSELECTは通常キャッシュの対象になりませんが、 white_memqcache_table_list に記述しておくことで、キャッシュされるようになります。 テーブル名はカンマ区切りで指定します。正規表現も利用できます (指定した各表現に ^ と $ をつけた形で使われます)。

なお、同じテーブル・VIEW が black_memqcache_table_list と両方に 指定されている場合は、white_memqcache_table_list が優先され、キャッシュを利用します。

スキーマ名を付けないテーブル名とスキーマ名を付けた形の両方をクエリの中で使う場合は、 両方共リストに登録してください。たとえば、"table1"と"public.table1"の両方がクエリに現れる場合は、 単に"table1"ではなく、"table1,public.table1"を追加する必要があります。

black_memqcache_table_list V3.2 〜

SELECT結果をキャッシュしたくないテーブル名をカンマ区切りで指定します。正規表現も利用できます (指定した各表現に ^ と $ をつけた形で使われます)。

スキーマ名を付けないテーブル名とスキーマ名を付けた形の両方をクエリの中で使う場合は、 両方共リストに登録してください。たとえば、"table1"と"public.table1"の両方がクエリに現れる場合は、 単に"table1"ではなく、"table1,public.table1"を追加する必要があります。

memqcache_maxcache V3.2 〜

SELECT文の実行結果がmemqcache_maxcacheバイトを超えると、キャッシュされません。 この場合、以下のようなメッセージが表示されます。

2012-05-02 15:08:17 LOG:   pid 13756: pool_add_temp_query_cache: data size exceeds memqcache_maxcache. current:4095 requested:111 memq_maxcache:4096

この問題を回避するためには、memqcache_maxcacheを大きくすれば良いのですが、 キャッシュストレージとして共有メモリを使用する場合は、 memqcache_cache_block_sizeを超えないようにしてください。 キャッシュストレージとしてmemcachedを使用する場合は、 memcachedのスラブサイズ(デフォルトで1MB)を超えないようにしてください。

memqcache_oiddir V3.2 〜

SELECT文が使用するテーブルにOIDを格納する一時ファイル領域のトップディレクトリをフルパスで指定します。 memqcache_oiddir以下には、データベースOID名のディレクトリが作成され、 更にその下にはテーブルOID名のファイルが作成されます。 テーブルOID名ファイルの中には、クエリキャッシュへのポインタが格納されており、 テーブルの更新があった際にキャッシュを削除するキーとなります。

この領域はデフォルトでは、pgpool を再起動しても再利用されます。 再利用せずに削除して起動したい場合は、pgpool コマンド に -C オプションをつけて起動します。

キャッシュのモニタリング

インメモリクエリキャッシュをモニタする方法を説明します。 キャッシュから検索結果が取得されたかどうかは、log_per_node_statement を 有効にすることで確認できます。

2012-05-01 15:42:09 LOG:   pid 20181: query result fetched from cache. statement: select * from t1;

クエリキャッシュのヒット率は、show pool_status コマンド で確認できます。

memqcache_stats_start_time           | Tue May  1 15:41:59 2012 | Start time of query cache stats
memqcache_no_cache_hits              | 80471                    | Number of SELECTs not hitting query cache
memqcache_cache_hits                 | 36717                    | Number of SELECTs hitting query cache

この例では、

(memqcache_cache_hits) / (memqcache_no_cache_hits+memqcache_cache_hits) = 36717 / (36717 + 80471) = 31.3%

がキャッシュヒット率ということになります。

show pool_cacheコマンドでも同様の内容が確認できます。

共有メモリ設定項目

キャッシュストレージとして共有メモリを使用する場合の設定項目を説明します。

memqcache_total_size V3.2 〜

キャッシュストレージに使用する共有メモリ領域のサイズを指定します。単位はバイトです。

memqcache_max_num_cache V3.2 〜

キャッシュの数を指定します。 この設定項目は、キャッシュの管理領域の大きさを決めるために使用します (memqcache_total_sizeとは別に取られます)。 管理領域の大きさは、memqcache_max_num_cache * 48(バイト)になります。 この数は少なすぎるとキャッシュを登録することができずにエラーになります。 逆に多すぎると無駄になります。

memqcache_cache_block_size V3.2 〜

キャッシュストレージとして共有メモリを使用する場合は、メモリを memqcache_cache_block_size のブロックに分けて利用します。検索結果 のキャッシュはこのブロックに入るだけ詰め込まれます。 ただし、キャッシュは複数のブロックにまたがって格納されないので、 memqcache_cache_block_sizeを検索結果が超えると、キャッシュに格納できなくなります。 memqcache_cache_block_sizeは、512以上の値でなければなりません。

memcached設定項目

キャッシュストレージとしてmemcachedを使用する場合の設定項目を説明します。

memqcache_memcached_host V3.2 〜

memcachedが動いているホスト名またはIPアドレスを指定します。 pgpool-IIと同じマシンでmemcachedを動かす場合は、'localhost'とします。

memqcache_memcached_port V3.2 〜

memcachedのポート番号を指定します。デフォルト値は 11211 です。

memcachedのインストール

pgpool-IIのクエリキャッシュストレージとしてmemcachedを使用する場合は、動作しているmemcachedと、 libmemcachedというクライアントライブラリのインストールが必要です。 rpmなどからインストールするのがおすすめですが、ここではソースコードからインストールする方法を説明します。

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

configureの実行

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

./configure
makeの実行
make
make install

libmemcachedのインストール

memcachedのクライアントライブラリは、libmemcachedを使用しています。
memcachedのインストール後に、libmemcachedをインストールする必要があります。

libmemcachedのソースコードは、libMemcached開発ページから ダウンロードできます。

configureの実行

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

./configure

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

  • --with-memcached=path
    Memcachedがインストールされているトップディレクトリを指定します。
makeの実行
make
make install

pgpool-IIの起動と停止

pgpool-II の起動

以上で設定が終わったので、各DBノードを起動してからpgpool-IIを起動します。

pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d]
-c--clear-cache クエリキャッシュを消去します
-f config_file--config-file config-file pgpool-IIの設定ファイルを指定します
-a hba_file--hba-file hba_file HBA認証設定ファイルを指定します
-F pcp_config_file--pcp-password-file pcpの設定ファイルを指定します
-n--no-daemon デーモンモードで起動しません(制御端末を切り離しません)
-D--discard-status pgpool_statusを削除し、以前の状態を復元しません V3.0 〜
-C--clear-oidmaps インメモリクエリキャッシュの memqcache_oiddir の ディレクトリの中身を消去します (memqcache_method が 'memcached' のときのみ。 'shmem' のときは指定しなくても、必ず消去されます)。 V3.2 〜
-d--debug デバッグモードで起動します

pgpool-II の停止

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

pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
-m s[mart]--mode s[mart] 接続中のクライアントが接続を終わるのを待ってから停止します(デフォルト)
-m f[ast]--mode f[ast] 接続中のクライアントが接続を終わるのを待たずに直ちに停止します
-m i[mmediate]--mode i[mmediate] -m fと同じ動作です

pgpoolが停止すると、[logdir]/pgpool_statusというファイルにバックエンドの状態を書き込みます。 pgpool-II 3.4.0から、ファイルフォーマットが変更され、ASCIIファイルになりました。 ですから普通のエディタでこのファイルを参照したり編集ができます。 たとえば、pgpool.confを編集して新しいバックエンドを追加、再起動した際に pgpool-IIが新しいバックエンドの死活を判定するまで待ちたくない場合、 あらかじめそのバックエンドを"down"状態に編集しておくことができます。 pgpool_statusの各行はそれぞれのバックエンドの状態に対応します。 1行目は最初のバックエンド、2行目は2番目のバックエンドというような具合です。 バックエンドの状態は"up", "down", "unused"のどれかです(大文字小文字は無視されます)。 例を示します。

up
down
up

なお、pgpool-II 3.4.0より前のpgpool-IIはバイナリ形式のpgpool_status使用します。 pgpool-II 3.4.0以降では、バイナリ形式のファイルも読むことができます。 しかしpgpool-II 3.4.0より前のpgpool-IIはASCII形式のpgpool_statusを読むことはできません。

次回pgpoolが起動したときにこのファイルが存在すると、バックエンドの状態をそこから復元します。 これによって、

  1. バックエンドが停止してフェイルオーバ
  2. pgpool経由で正常なDBを更新
  3. pgpoolを停止
  4. 停止していたDBを再起動
  5. 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_filepgpool-IIの設定ファイルを指定します
-a hba_fileHBA認証設定ファイルを指定します
-F pcp_config_filepcpの設定ファイルを指定します

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

SHOWコマンド

概要

pgpool-IIでは、SHOWコマンドを使って情報を参照することができます。 SHOWはSQLコマンドですが、pgpool-IIは一部のSHOWコマンドを独自に解釈して、pgpool-IIが管理する情報を返却します。 以下のようなものがあります。

pool_status構成情報
pool_nodes DBノード情報 V3.0 〜
pool_processes pgpool-IIプロセスの内部情報 V3.0 〜
pool_pools コネクションプール情報 V3.0 〜
pool_version pgpool-IIのバージョン V3.0 〜

"pool_status" SQL は以前からありますが、他のSQLはpgpool-II 3.0から追加されました。

注意: "pool"という用語は、pgpoolプロセスによって所有されるPostgreSQLセッションを指します。 pgpoolによって所有されるセッション全体ではありません。

pool_status

"SHOW pool_status" は設定パラメータの名前と値、説明を表示します。出力の一部を示します。

benchs2=# show pool_status;
                 item                 |             value              |                           description
--------------------------------------+--------------------------------+------------------------------------------------------------------
 listen_addresses                     | localhost                      | host name(s) or IP address(es) to listen to
 port                                 | 9999                           | pgpool accepting port number
 socket_dir                           | /tmp                           | pgpool socket directory
 pcp_port                             | 9898                           | PCP port # to bind
 pcp_socket_dir                       | /tmp                           | PCP socket directory

pool_nodes V3.0 〜

"SHOW pool_nodes"は、DBノードのリストを表示します。 ホスト名、ポート番号、状態、重み(ロードバランスモードで運用しているときにのみ意味があります)、 ノードの役割、発行されたSELECTの数が表示されます。 状態(status)の意味については、pcp_node_infoリファレンスで説明されています。ホスト名が"/tmp"のように表示される場合、UNIXドメインソケットを使用してpgpool-IIがPosgreSQLに接続していることを意味します。SELECTの数には、pgpool-II内部で発行されるクエリの数は含まれません。また、このカウンタはpgpool-IIがスタートした時に0にリセットされます。

benchs2=# show pool_nodes;
 node_id | hostname | port  | status | lb_weight |  role   | select_cnt 
---------+----------+-------+--------+-----------+---------+------------
 0       | /tmp     | 11002 | 2      | 0.500000  | primary | 9231
 1       | /tmp     | 11003 | 2      | 0.500000  | standby | 9469
(2 rows)

pool_processes V3.0 〜

"SHOW pool_processes"は、接続待ち、あるいは接続中pgpool-IIの子プロセスの状態を表示します。

6つのカラムがあります。

返却行数は常にnum_init_childrenになります。 また、データベース名などが表示されるのは、そのプロセスにフロントエンドからの接続がある場合に限ります。

benchs2=# show pool_processes;
 pool_pid |     start_time      | database | username  |     create_time     | pool_counter
----------+---------------------+----------+-----------+---------------------+--------------
 8465     | 2010-08-14 08:35:40 |          |           |                     |
 8466     | 2010-08-14 08:35:40 | benchs   | guillaume | 2010-08-14 08:35:43 | 1
 8467     | 2010-08-14 08:35:40 |          |           |                     |
 8468     | 2010-08-14 08:35:40 |          |           |                     |
 8469     | 2010-08-14 08:35:40 |          |           |                     |
(5 lines)

pool_pools V3.0 〜

"SHOW pool_pools"は、pgpool-IIのコネクションプールの状態を表示します。

11のカラムがあります。

返却行数は常にnum_init_children * max_pool * 「バックエンドの数」になります。

benchs2=# show pool_pools;
  pool_pid |     start_time      | pool_id | backend_id | database | username  |     create_time     | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected
----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
 8465     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
 8465     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
 8465     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
 8465     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
 8466     | 2010-08-14 08:35:40 | 0       | 0          | benchs   | guillaume | 2010-08-14 08:35:43 | 3            | 0            | 1            | 8473            | 1
 8466     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
 8466     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
 8466     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
 8467     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
 8467     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
 8467     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
 8467     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
 8468     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
 8468     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
 8468     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
 8468     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
 8469     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
 8469     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
 8469     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
 8469     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
(20 lines)

pool_version V3.0 〜

"SHOW pool_version" はpgpool-IIのバージョン情報を表示します。 例を示します。

benchs2=# show pool_version;
      pool_version
------------------------
 3.0-dev (umiyameboshi)
(1 line)

pool_cache V3.1 〜

"SHOW pool_cache" はインメモリクエリキャッシュが有効である場合に、クエリキャッシュのヒット率や、キャッシュストレージの状況を表示します。 例を示します。

test=# \x
\x
Expanded display is on.
test=# show pool_cache;
show pool_cache;
-[ RECORD 1 ]---------------+---------
num_cache_hits              | 891703
num_selects                 | 99995
cache_hit_ratio             | 0.90
num_hash_entries            | 131072
used_hash_entries           | 99992
num_cache_entries           | 99992
used_cache_enrties_size     | 12482600
free_cache_entries_size     | 54626264
fragment_cache_entries_size | 0

オンラインリカバリ

オンラインリカバリ概要

この章では、レプリケーションモードで利用する場合のオンラインリカバリ機能 について説明します。 マスタ/スレーブモード(Streaming Replication)でのオンラインリカバリの利用方法については、 Streaming Replicationへの対応をご覧下さい。 レプリケーションモードで pgpool が動作している場合、ダウンしたノードのデータを再同期させた上で、 ノードを復帰させることができます。この機能を「オンラインリカバリ」と呼びます。

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

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

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

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

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

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

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

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

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

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

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

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

pgpool の設定

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

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 8.2 以降で PITR 機能を使ってリカバリをする設定例を説明します。 PITR によるリカバリをする場合にはあらかじめ PostgreSQL の設定で ログをアーカイブさせるようにしておいてください。

1st stage

まずファーストステージでベースバックアップを取得し、リカバリ先へコピーするスクリプト (ここではファイル名を 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'

2nd stage

セカンドステージでは最新の状態まで PITR によるリカバリを実施できるようにするために、 pgpool_recovery_pitr スクリプトを$PGDATA にコピーします。 このスクリプトではトランザクションログを強制的に切り替えるようにします。

通常、トランザクションログを切り替えるには、pg_switch_xlog 関数を利用しますが、 この関数は、アーカイブログファイルが生成される前に終了してしまう可能性があります。

V3.1 〜 そこで、より安全にオンラインリカバリを行うために pgpool_switch_xlog 関数が用意されています。 pgpool_switch_xlog 関数の基本動作は pg_switch_xlog 関数と同じですが、 トランザクションログの切り替えによるアーカイブログファイルの生成を 待ってから終了します。 この関数は、前述の「C言語関数のインストール」を実施するとインストールされ、 引数にはアーカイブログの出力先ディレクトリを指定します。

#! /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
archdir=/data/archive_log    # archive log directory

# 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 pgpool_switch_xlog('$archdir')" template1

スクリプト中の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 機能がありません。また、8.0 と 8.1 の場合は トランザクションログを強制的に切り替える関数が用意されていません。 そこで PITR を使わずにrsync を使ったリカバリ方法を説明します。

sample ディレクトリに pgpool_recovery というファイルがあります。 マスタから復帰させるノードへのデータの物理コピーを行うスクリプトです。 pgpool からは以下の形式でスクリプトを実行します。

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

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

rsyncに関する注記:

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 を大きくしてください。

オンラインリカバリを利用したPostgreSQLのマイナーバージョンアップ

レプリケーションモードの場合

レプリケーションモードでpgpool-IIが動作している場合は、 オンラインで各ノードのPostgreSQLをバージョンアップできます。 ただし、ノードの切り離し時と追加時に、pgpool-IIに接続しているすべての すべてのセッションが切断されるので注意してください。 また、オンラインリカバリが利用できるバージョンアップはマイナーバージョンアップのみで、 ダンプ/リストアが不要なリリースに限ります。

はじめに、上記の「オンラインリカバリの概要」を参考に各ノードでオンラインリカバリが利用できるように準備します。

PostgreSQLのバージョンアップは、マスタ以外のノードから行い、最後にマスタノードをバージョンアップします。 そこで、まずバージョンアップを行うマスタ以外の1つのノードのPostgreSQLを停止します。 pgpool-IIがPostgreSQLの停止を検知すると、以下のようなログを出力して縮退運転に移行します。 その際、pgpool-IIに接続しているすべてのセッションは一旦切断されます。

2010-07-27 16:32:29 LOG:   pid 10215: set 1 th backend down status
2010-07-27 16:32:29 LOG:   pid 10215: starting degeneration. shutdown host localhost(5433)
2010-07-27 16:32:29 LOG:   pid 10215: failover_handler: set new master node: 0
2010-07-27 16:32:29 LOG:   pid 10215: failover done. shutdown host localhost(5433)

停止したノードのPostgreSQLをバージョンアップします。 バージョンアップは、新しいバージョンのPostgreSQLを古いバージョンのインストール先に上書きしても構いませんが、 問題が起きた時に元のバージョンに戻せるようにインストール先を変えておくことをお勧めします。

新しいバージョンのPostgreSQLを古いバージョンと別の場所にインストールした場合、 リカバリスクリプトを編集することなくそのまま使用するには、シンボリックリンクなどを使用して インストール先のパスを以前と合わせる必要があります。 上書きインストールした場合は以下のC言語関数をインストールするまでの操作は不要です。 すぐにオンラインリカバリが実行できます。

古いバージョンのPostgreSQLのインストール先ディレクトリ名を変更します。 以下は、PostgreSQLが/usr/local/pgsqlにインストールされていたと仮定した一例です。

$ mv /usr/local/pgsql /usr/local/pgsql-old

新しいバージョンのPostgreSQLのインストール先にシンボリックリンクを作成します。 これにより、今までどおりのパスで新しいバージョンのPostgreSQLが使用できるようになります。 以下は、新しいバージョンのPostgreSQLが/usr/local/pgsql-newにインストールされていると仮定した一例です。

$ ln -s /usr/local/pgsql-new /usr/local/pgsql

データベースクラスタディレクトリがPostgreSQLのインストール先ディレクトリの下位にある場合は、 同じパスでデータベースクラスタにアクセスできるようにシンボリックリンクを作成するかコピーします。 以下は、シンボリックリンクを作成する例です。

$ ln -s /usr/local/pgsql-old/data /usr/local/pgsql/data

新しいバージョンのPostgreSQLに、オンラインリカバリ用の関数を 「C言語関数のインストール」を参考にインストールします。 オンラインリカバリは、データベースクラスタをコピーしますので、最後のpsqlを使用した関数の作成は不要です。 make installを実行してください。

最後にオンラインリカバリを実行して、1つのノードのバージョンアップが完了します。 オンラインリカバリは、pcp_recovery_nodeコマンドを実行するかpgpoolAdminで行います。

以上の手順をマスタ以外のノードで繰り返し、最後にマスタノードで行えば、 全体のPostgreSQLのマイナーバージョンアップは完了です。

Streaming Replicationを利用している場合

マスタースレーブモードでStreaming Replicationを利用している場合は、 オンラインでスタンバイのPostgreSQLをマイナーバージョンアップできます。

スタンバイのPostgreSQLをマイナーバージョンアップする手順は、上記のレプリケーションモードの手順と同じです。 ただし、recovery_1st_stage_commandとrecovery_2nd_stage_commandの設定などは、 「Streaming Replicationでのオンラインリカバリ」を参考にしてください。

プライマリのPostgreSQLのマイナーバージョンアップは、オンラインではできません。 pgpool-IIの停止が必要になります。 プライマリのPostgreSQLもバージョンアップの方法自体は、スタンバイと同様です。 プライマリのPostgreSQLのバージョンアップは以下の手順で行います。

  1. pgpool-IIを停止
  2. プライマリのPostgreSQLを停止
  3. プライマリのPostgreSQLをバージョンアップ
  4. プライマリのPostgreSQLを起動
  5. pgpool-IIを起動

バックアップ

バックエンドのPostgreSQLのバックアップは、単体のPostgreSQLと同様に、 物理バックアップ、論理バックアップ(pg_dump, pg_dumpall)、PITRが使用できます。 ただし、論理バックアップとPITRの操作は、pgpool-IIを経由せずにPostgreSQLに対して直接行ってください。 これは、load_balance_modereplicate_selectなどの 設定によるバックアップの失敗を避けるためです。

レプリケーションモード、マスタースレーブモード

レプリケーションモードとマスタースレーブモードでpgpool-IIが動作している場合は、 クラスタを構成しているいずれかのノードでバックアップを行います。

マスタースレーブモードで非同期のレプリケーションを行っている場合で、かつ、 最新のバックアップを取得したい場合は、マスタノードでバックアップしてください。

バックアップ時の注意点として、PostgreSQLに対してpg_dumpコマンドなどを実行すると、 ACCESS SHAREモードのロックがかかります。 そのため、ACCESS SHAREモードと競合するACCESS EXCLUSIVEロックが必要になるコマンド (ALTER TABLE、DROP TABLE、TRUNCATE、REINDEX、CLUSTERおよびVACUUM FULLなど)は、ロック待ちが発生します。 これは、非同期のレプリケーションで、スレーブノードに対してバックアップを行っている場合も、 マスタが影響を受けることがありますので注意してください。

pgpool-IIの配置について

pgpool-IIは、独立したサーバに配置することもできますし、アプリケーションサーバと同居させることもできますし、 その他の配置も考えられます。 ここではそれぞれの配置方法を紹介し、それぞれの特徴、メリット、デメリットを検討します。

専用のサーバに配置

pgpool-IIを物理的に独立した専用のサーバに配置する方法です。 分かりやすい方法ですし、他のサーバソフトウェアの影響を受けないのでpgpool-IIをもっとも安全に運営できますが、 サーバ装置を1台余計に増やす必要があるのが欠点です。 また、そのサーバが単一障害点になります(pgpool-IIが単一障害点になることを回避するには、 後述のwatchdogかpgpool-HAを併用します)。

Webサーバやアプリケーションサーバと同居

Apache、JBoss、TomcatなどのWebサーバやアプリケーションサーバが稼働しているサーバに pgpool-IIを同居させる方法です。 この方法では、Webサーバやアプリケーションサーバとpgpool-IIの通信がローカルマシン内になるので、 ソケット通信がマシン間で通信するよりも高速になるメリットがあります。 また、複数のWebサーバ/アプリケーションサーバがあれば、自然と単一障害点を回避できるようになります。 (この場合、複数のpgpool-IIの設定はwatchdog用の設定を除き同じにしてください)。 なお、複数のpgpool-IIが動作しているケースでは以下のような問題が考えられますが、 watchdogを有効にすることによって回避できます。 したがって、このような構成ではwatchdogを有効にすることを強くおすすめします。

  • pgpool-IIとDBサーバの間のネットワークが不安定だと、pgpool-IIから見てDBノード#1がダウン、 他のpgpool-IIから見て正常、というような状態になってしまうことがあります。 ネットワークを二重化するなどして、ネットワーク障害が起きないようにしてください。
  • レプリケーションモードで、オンラインリカバリ実行中は、一つのpgpool-IIだけ残して 他のpgpool-IIを落してください。 さもないと、リカバリ後の結果に整合性がなくなる可能性があります。 マスター/スレーブモード+Streaming Replicationモードでは、同時に複数のpgpool-IIで オンラインリカバリを実行しない限り、問題ありません。
DBサーバと同居

PostgreSQLの稼働しているDBサーバと同居させる方法です。 この方法では、pgpool-IIが単一障害点になることがなく、余計なサーバを追加する必要もない点が優れていますが、 アプリケーションがどのDBサーバに接続するのかを自ら判断する必要があるのが欠点です。 この問題を解決するには、watchdogを有効にするか、pgpool-HAと組み合わせて仮想IPを利用します。

pgpool-HAについて

pgpool-HAは、heartbeatなどを利用してpgpool-IIを二重化し、pgpool-II自体の可用性を上げるソフトウェアです。 pgpool-IIと同様、pgpoolプロジェクトのサブプロジェクトであり、pgpoolの開発サイトでOSSとして公開されています。

Watchdog V3.2 ~

watchdog とは

watchdog プロセスは pgpool-II から起動される、高可用性を目的としたプロセスです。 複数の pgpool-II を連携させることで単一障害点を回避します。 pgpool-II V3.5 - で watchdog は大幅に改善され、常にクォーラム(定足数)が確立されているようになりました。 この新機能により watchdog はスプリットブレイン現象やネットワーク分断の対処や防止に関して、対障害性が向上し、よりロバストになりました。 ただし、スプリットブレイン現象やネットワーク分断の対処や防止機能が正しく動くためには、pgpool-IIノードの数は3以上で、かつ奇数でなけれななりません。 watchdog は以下の機能をから構成されます。

pgpool-II の死活監視

watchdog の lifecheck は watchdog 高可用性クラスタに参加している pgpool-II ノードの死活監視を行うサブコンポーネントです。 従来の pgpool-II watchdog ではリモートノードの監視方法として "heartbeat" と "query" の2つのモードが提供されていました。 pgpool-II V3.5 - の watchdog では新しいモードとして "external" が追加されました。 これにより、外部のサードパーティツールによる死活監視システムを pgpool-II watchdog で使用することが可能になります。 サードパーティツールを watchdog で使用する方法について詳しくは 外部死活監視ツールとの連携 を参照してください。 リモートノードの死活監視とは別に、lifecheck は上位サーバへの接続を監視することでローカルノードの状態もチェックすることも可能です。

また watchdog は、pgpool-II から上位のサーバ(アプリケーションサーバなど)への接続も監視し、 上位サーバへ pgpool-II のサービスを提供できるかチェックしています。 この監視に失敗した場合には、watchdog は pgpool-II に障害が発生しているとみなしダウンステータスに移行します。

pgpool-II 間の協調動作

watchdog は互いに情報交換を行うことで複数の pgpool-II を協調動作させます。

障害発生検知時のアクティブ、スタンバイ切り替え

pgpool-II の障害を検知した場合、watchdog は他の watchdog に障害検知を通知します。 故障した pgpool-II がアクティブの場合、他の watchdog は新しいアクティブを投票で決め、 アクティブ・スタンバイの切り替えを行います。

全ノードの重要な設定パラメータの整合性検証 V3.5 -

watchdog の起動時にローカルノードの pgpool-II の設定がマスター watchdog ノードの設定と整合がとれているか検証します。 これにより pgpool-II ノード間の設定の不一致によって発生する予期しない挙動の可能性が軽減されます。

サーバ切り替えと連動した仮想 IP アドレスの自動付け替え

スタンバイが新しいアクティブに昇格する際、新アクティブ機の watchdog は アクティブ用の仮想IPインターフェースを起動します。

一方、旧アクティブ機の watchdog はアクティブ用仮想 IP インターフェースを停止します。 これにより、サーバが切り替わった後もアクティブは同じ IP アドレスでサービスを継続することができます。

サーバ復旧時、スタンバイ機としての自動登録

障害機の復旧や新規サーバを追加する場合、watchdog はサーバの情報を他の watchdog に通知し、 他の watchdog からはアクティブや他のサーバの情報を受け取ります。 これにより追加したサーバはスタンバイ機として自動的に追加されます。

サーバ構成

watchdogプロセスを含むpgpool-IIサーバは以下の図のようなシステム構成をとります。

watchdog server composition

watchdog の起動と停止

watchdog プロセスは pgpool-II の子プロセスとして自動的に起動・停止されますので、固有の起動・停止コマンドはありません。

watchdog は仮想 IP インターフェースの起動・停止を行うため、 root 権限を要求します。 pgpool-II を起動する際に root 権限で実行するのが1つの方法です。 しかし、セキュリティ上の理由からは、sudo や setuid を利用したコマンドを if_up_cmdif_up_cmdif_up_cmd に設定するのがより良い方法です。

watchdog 組み込みの死活監視は他の全ての pgpool-II が起動した後に開始されます。 全ての pgpool-II が起動していない状態では監視は行われず、仮想 IP の切り替えも行われません。

pgpool.conf の設定

watchdog プロセスの設定項目は pgpool.conf に記述します。 pgpool.conf.sample ファイルの WATCHDOG セクションにサンプルを記述していますので、参照してください。

watchdog プロセスは以下の項目すべてを指定する必要があります。

有効化

use_watchdog V3.2 ~

watchdog を有効にするには on にします。デフォルトは off です。

このパラメータを変更した時には pgpool-II を再起動してください。

watchdog 間通信

watchdog 間の情報交換に関する設定です。

wd_hostname V3.2 ~

pgpool-II サーバのホスト名または IP アドレスです。 クエリやパケットの送受信の他、watchdog の識別子としても用います。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_port V3.2 ~

wachdog 間の情報交換のためのパケットを受信するポート番号を指定します。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_authkey V3.3 ~

wachdog 間通信で用いられる認証キーです。 全ての pgpool-II で同じキーを指定する必要があります。 認証キーが異なる watchdog からの通信は拒絶されます。 死活監視をハートビートモードで行う場合には、この認証はハートビート信号にも適用されます。 指定が無い場合には認証は行われず、これがデフォルトです。

このパラメータを変更した時には pgpool-II を再起動してください。

上位サーバへの接続

pgpool-II あるいは PostgreSQL のサービス提供先(DB クライアント)のサーバを、上位サーバと呼びます。 pgpool-II が生きていて PostgreSQL と繋がっている場合でも、 上位サーバとのリンクが切れていればサービスを継続できません。 そのため、watchdog は上位サーバとのリンクが繋がっているかどうかも監視します。

trusted_servers V3.2 ~

上位接続を確認するための信頼できるサーバリストです。 ping の応答が得られる必要があります。 "hostA,hostB,hostC ..." のようにカンマで区切って複数のサーバを指定できます。 全てのサーバへの ping が失敗した場合、watchdog は pgpool-II に障害が発生したと判断します。 そのため、複数のサーバを指定することを推奨します。

指定がない場合は上位サーバへの接続監視は行いません。

このパラメータを変更した時には pgpool-II を再起動してください。

ping_path V3.2 ~

上位サーバへの接続監視に利用する ping コマンドのパスです。 "/bin" のようにパスだけを指定します。

このパラメータを変更した時には pgpool-II を再起動してください。

仮想 IP

仮想 IP の制御に関する設定です。

delegate_IP V3.2 ~

(アプリケーションサーバなど)外部からの接続される pgpool-II の仮想 IP アドレスです。 スタンバイからアクティブに切り替わる際、pgpool-II はこの仮想 IP を引き継ぎます。 このオプションが空の場合には、仮想 IP は起動されません。

このパラメータを変更した時には pgpool-II を再起動してください。

if_cmd_path V3.5 ~

IP アドレス切り替えに利用するコマンドのパスです。 "/sbin" のようにパスだけを指定します。

このパラメータを変更した時には pgpool-II を再起動してください。

if_up_cmd V3.2 ~

仮想 IP を起動するために実行するコマンドです。 "ip addr add $_IP_$/24 dev eth0 label eth0:0" のようにコマンドとパラメータを指定します。 $_IP_$ は delegate_IP で指定された IP アドレスに置換されます。

このパラメータを変更した時には pgpool-II を再起動してください。

if_down_cmd V3.2 ~

仮想IPを停止するために実行するコマンドです。 "ip addr del $_IP_$/24 dev eth0" のようにコマンドとパラメータを指定します。

このパラメータを変更した時には pgpool-II を再起動してください。

arping_path V3.2 ~

IP アドレス切り替え後に ARP リクエストを送信するコマンドのパスです。 "/usr/sbin" のようにパスだけを指定します。

このパラメータを変更した時には pgpool-II を再起動してください。

arping_cmd V3.2 ~

IPアドレス切り替え後にARPリクエストを送信するコマンドです。 "arping -U $_IP_$ -w 1" のようにコマンドとパラメータを指定します。 $_IP_$ は delegate_IP で指定された IP アドレスに置換されます。

このパラメータを変更した時には pgpool-II を再起動してください。

昇格および降格時の振る舞い

pgpool-II がアクティブ(仮想 IP を保持しているステータス)に昇格した時の振る舞いの設定です。

clear_memqcache_on_escalation V3.3 ~

このオプションが on の場合、pgpool-II がアクティブに昇格した時に、共有メモリ上のクエリキャッシュを全て削除します。 これにより、旧アクティブと非整合な古いクエリキャッシュが使われることを防止します。 memqcache_method が 'shmem' の場合のみ有効です。 デフォルトは on です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_escalation_command V3.3 ~

pgpool-II ノードがマスター watchdog に昇格した時に、ここで指定したコマンドが実行されます。

コマンドは、仮想 IP が設定されていた場合、それが立ち上がる直前のタイミングで実行されます。

wd_de_escalation_command V3.5 ~

pgpool-II watchdog のマスターノードがマスターの責務を辞退し降格するときに、ここで指定したコマンドが実行されます。 マスターノードは、そのマスターノードが停止したとき、および、 ネットワーク切断やクォーラムが失われたことを検出した時に、マスターから辞任します。

コマンドは、仮想 IP が設定されていた場合、それが停止される直前のタイミングで実行されます。

pgpool-II の死活監視

watchdog は一定時間間隔で pgpool-II の状態のチェック、すなわち死活監視を行います。

共通設定

wd_lifecheck_method V3.3 ~

死活監視の方法を指定します。指定できる値は 'heartbeat' (デフォルト)、'query'、または 'external' です。

'heartbeat' を指定した場合には、監視は「ハートビートモード」で行われます。 watchdog は一定間隔でハートビート信号(UDP パケット)を他の pgpool-II へ送信します。 また watchdog は他の pgpool-II から送られてくる信号を受信し、これが一定時間以上途絶えた場合には その pgpool-II に障害が発生したと判断します。

'query' を指定した場合には、監視は「クエリモード」で行われます。 watchdog は監視用のクエリを pgpool-II に発行し、それが成功するかどうかで pgpool-II が生きているかどうかを判断します。

注意: クエリモードを使用する場合は、num_init_childrenに 十分大きな値を設定して下さい。watchdog 自身も pgpool-II にクライアントとして接続するためです。

'external' を指定した場合には、監視は「外部ツールモード」で行われます(V3.5 -)。 watchdog は組み込みの死活監視機能を無効にし、ローカルおよびリモートの watchdog ノードの死活監視を外部のシステムに頼ります。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_monitoring_interfaces_list V3.5 -

watchdog プロセスがネットワークリンクの状態を監視するネットワークデバイス名をカンマ区切りのリストで指定します。 リスト中の全てのネットワークインタフェースが(無効化あるいはケーブルを抜かれることで)非アクティブになると、 watchdog はネットワークが完全に故障したと見なし自らを停止させませす。 空のリスト '' を指定するとネットワークインタフェースの監視が無効になります。 'any' を指定すると、ループバック以外の存在する全てのネットワークインタフェースを監視します。 デフォルトの値は空リスト '' (監視は無効)です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_interval V3.2 ~

死活監視を行う間隔(秒)です。 (1 以上の数値) デフォルトの値は 10 です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_priority V3.5 ~

このパラメータによってローカルの watchdog ノードがマスターに選ばれる優先度を上げることができます。 クラスタの初期起動時や古いマスターノードが故障した状況でクラスタがマスターノードの選択を行う際に、wd_priority が高いノードがマスターwatchdog ノードに選ばれます。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_ipc_socket_dir V3.5 ~

pgpool-II watchdog の IPC(プロセス間通信)で受け付ける UNIX ドメインソケットが作成されるディレクトリを指定します。 デフォルトは '/tmp' です。 このソケットが cron ジョブで削除されることのないよう気をつけてください。この値は '/var/run' などのディレクトリに設定することを推奨します。

このパラメータを変更した時には pgpool-II を再起動してください。

ハートビートモードの設定

wd_heartbeat_port V3.3 ~

ハートビート信号を受信するポート番号を指定します。 デフォルトは 9694 です。 ハートビートモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_heartbeat_keepalive V3.3 ~

ハートビート信号を送信する間隔(秒)を指定します。 デフォルトは 2 です。 ハートビートモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_heartbeat_deadtime V3.3 ~

このオプションで指定された間隔(秒)の間ハートビート信号が途絶えた場合、その pgpool-II に障害が発生したとみなされます。 デフォルトは 30 です。 ハートビートモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

heartbeat_destination0 V3.3 ~

ハートビート信号の送り先を、ホスト名か IP で指定します。 複数の送り先が指定可能です。 数値の部分は送り先の番号です。0 からの連番にします。 ハートビートモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

heartbeat_destination_port0 V3.3 ~

heartbeat_destinationXに指定したハートビート信号の送り先のポート番号を指定します。 通常は wd_heartbeat_port と同じ値を指定します。 そのポート番号が使用できないホストや、同じホストで複数の pgpool-II を動作させる場合には、異なる値を指定する必要があります。 数値の部分は送り先の番号です。0 からの連番にします。 ハートビートモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

heartbeat_device0 V3.3 ~

heartbeat_destinationXに指定した送り先とのハートビートの送受信に用いる ネットワークデバイス名を指定します。 数値の部分は送り先の番号です。デバイス毎に 0 からの連番にします。 複数の異なる送り先に同じデバイスを設定することが可能です。 ハートビートモードの場合のみ有効です。空文字列が指定された場合には無視されます。 また、SO_BINDTODEVICE ソケットオプションを使用しているため、pgpool-II が Linux で root 権限で起動している場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

クエリモードの設定

wd_life_point V3.2 ~

監視クエリの応答が得られなかった場合のリトライ回数です。 (1 以上の数値) デフォルトの値は 3 です。 クエリモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_lifecheck_query V3.2 ~

pgpool-II の死活監視のために発行されるクエリです。 デフォルトは "SELECT 1" です。 クエリモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_lifecheck_dbname V3.3 ~

監視クエリを送る際の接続先のデータベース名です。 デフォルトは 'template1' です。 クエリモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_lifecheck_user V3.3 ~

監視クエリを送る際にデータベースに接続するユーザ名です。 デフォルトは 'nobody' です。 クエリモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

wd_lifecheck_password V3.3 ~

監視クエリを送る際にデータベースに接続するパスワードです。 デフォルトでは設定されていません。 クエリモードの場合のみ有効です。

このパラメータを変更した時には pgpool-II を再起動してください。

監視対象サーバ

other_pgpool_hostname0 V3.2 ~

監視対象の pgpool-II サーバのホスト名を指定します。 クエリやパケットの送受信の他、watchdog の識別子としても用います。 数値の部分は監視対象サーバの通し番号です。 監視対象のサーバ毎に 0 からの連番にします。

このパラメータを変更した時には pgpool-II を再起動してください。

other_pgpool_port0 V3.2 ~

監視対象の pgpool-II サーバの pgpool ポート番号を指定します。 クエリモード使用時に、wd_lifecheck_query に指定したクエリがこのポートへ送られます。 数値の部分は監視対象サーバの通し番号です。 監視対象のサーバ毎に 0 からの連番にします。

このパラメータを変更した時には pgpool-II を再起動してください。

other_wd_port0 V3.2 ~

監視対象の pgpool-II サーバの watchdog パケット受信ポート番号を指定します。 数値の部分は監視対象サーバの番号です。 監視対象のサーバ毎に 0 からの連番にします。

このパラメータを変更した時には pgpool-II を再起動してください。

外部死活監視ツールとの連携 V3.5 -

pgpool-II watchdog プロセスは他の pgpool-II プロセスとの通信に BSD ソケットを使用しており、 このソケットはサードパーティシステムでローカルおよびリモートの pgpool-II watchdog ノードの死活監視をするために使用することが可能です。 IPC(プロセス間通信)のための BSD ソケットの名前は、"s.PGPOOLWD_CMD" の後ろの pgpool-II の wd_port を続けた文字列となります。ソケットファイルは wd_ipc_socket_dir で指定されたディレクトリに置かれます。

Watchdog IPC コマンドパケットの書式

watchdog IPC コマンドパケットは 3 つのフィールドから構成されます。メッセージフィールドの詳細を以下の表に示します。

フィールド 説明
TYPE BYTE1 コマンドのタイプ
LENGTH INT32(ネットワークバイトオーダ) 続くデータの長さ
DATA JSON 形式データ JSON 形式のコマンドデータ

Watchdog IPC コマンド結果パケットの書式

watchdog IPC コマンド結果パケットは 3 つのフィールドから構成されます。メッセージフィールドの詳細を以下の表に示します。
フィールド 説明
TYPE BYTE1 コマンドのタイプ
LENGTH INT32(ネットワークバイトオーダ) 続くデータの長さ
DATA JSON 形式データ JSON 形式のコマンド結果データ

Watchdog IPC コマンドパケットのタイプ

watchdog プロセスに送られる、または watchdog プロセスから返される IPC コマンドパケットの最初のバイトはコマンド、またはコマンド結果のタイプとみなされます。 有効なタイプとその意味の一覧を以下の表に示します。

名前 バイト値 タイプ説明
Register for notifications '0' コマンド watachdog の通知を受信するための接続を登録するコマンド
Node status change '2' コマンド watchdog に watchdog ノードの状態変化を通知するコマンド
Get nodes list '3' コマンド 設定された全ての watchdog ノードのリストを取得するコマンド
Nodes list data '4' 結果 設定された全ての watchdog ノードのリストを含む JSON データのパケット
Cluster in transition '7' 結果 クラスタ状態が遷移中のためコマンドを処理できない
Result BAD '8' 結果 IPC コマンドが失敗した
Result OK '9' 結果 IPC コマンドが成功した

外部死活監視のための IPC パケットおよびデータ

外部の死活監視システムと連携に、IPC メッセージ "Get nodes list('3')", "Nodes list data('4')" および "Node status change('2')" が使用できます。 内部の pgpool の死活監視もまた、同じチャネルとテクニックを使用していることに注意してください。

設定された watchdog ノードのリストの取得

サードパーティの死活監視システムはデータの長さが 0 の "Get nodes list('3')" タイプのパケットを watchdog IPC ソケットに送り、 "Node list data('4')" タイプの結果パケットを取得することができます。このパケットは死活監視の対象となる全ての設定された watchdog ノードのリストが JSON 形式で含まれています。 watchdog ノード全体を表す json は全ての watchdog ノードの配列 "WatchdogNodes" を格納しています。 各 watchdog json ノードには、各ノードの "ID", "NodeName", "HostName", "DelegateIP", "WdPort" および "PgpoolPort" が格納されます。

-- "Nodes list data('4')" に格納される JSON データの例

  {
    "NodeCount":3,
    "WatchdogNodes":
        [
            {
                "ID":0,
                "State":1,
                "NodeName":"Linux_ubuntu_9999",
                "HostName":"watchdog-host1",
                "DelegateIP":"172.16.5.133",
                "WdPort":9000,
                "PgpoolPort":9999
            },
            {
                "ID":1,
                "State":1,
                "NodeName":"Linux_ubuntu_9991",
                "HostName":"watchdog-host2",
                "DelegateIP":"172.16.5.133",
                "WdPort":9000,
                "PgpoolPort":9991
            },
            {
                "ID":2,
                "State":1,
                "NodeName":"Linux_ubuntu_9992",
                "HostName":"watchdog-host3",
                "DelegateIP":"172.16.5.133",
                "WdPort":9000,
                "PgpoolPort":9992
            }
        ]
  }

-- ID 0 のノードは常にローカルの watchdog ノードのために使用されることに注意

設定された watchdog ノードの情報を取得した後は、外部の死活監視システムは watchdog ノードの死活監視を続けることが可能であり、 いずれかのノードでなんらかの状態変化を検出した場合には、"Node status change('2')" IPC メッセージを使ってそのことを watchdog に通知することができます。 そのメッセージ中のデータは、状態が変化したノードの ID(watchdog から WatchdogNodes リストで返されたものと同じであること)と、その新しい状態の JSON を含んでなければなりません。

-- pgpool-II watchdog に ID 1 のノードの死活監視が失敗したことを通知する JSON の例

  {
    "NodeID":1,
    "NodeStatus":1,
    "Message":"optional message string to log by watchdog for this event"
  }

-- NodeStatus の値の意味は以下の通り
NODE STATUS DEAD  =  1
NODE STATUS ALIVE =  2

watchdog の制限事項

PCP コマンド

PCP コマンド一覧

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

注意:pgpool-II 3.5 より、全ての PCP コマンドのパラメータ書式が変更されています。

pcp_node_count ノード数を取得する
pcp_node_info ノード情報を取得する
pcp_watchdog_info watchdog 情報を取得する V3.3 ~
pcp_proc_count プロセス一覧を取得する
pcp_proc_info プロセス情報を取得する
pcp_pool_status pgpool.conf のパラメータ設定値を取得する V3.1 〜
pcp_detach_node ノードを切り離す
pcp_attach_node ノードを復帰させる
pcp_promote_node ノードをマスターに昇格させる V3.1 〜
pcp_stop_pgpool pgpool-IIを停止させる
pcp_recovery_node マスタノードを使ってノードのデータを再同期、ノード起動させる

PCP 接続認証

PCP ユーザ名とパスワードが $prefix/etc ディレクトリ内の pcp.conf で宣言されている必要があります。pcp.conf が他の場所にある場合には、pgpool-II の起動時に -F オプションで指定することができます。

パスワードファイル

PCP 接続時にパスワードが指定されなかった場合、ユーザのホームディレクトリに配置された .pcppass ファイルか、環境変数 PCPPASSFILE で参照されるファイルに格納されたパスワードが使用可能です。

このファイルの各行の書式は以下のとおりです:

hostname:port:username:password

(この文字列の行頭に # を付けてからファイルにコピーしておけば備忘録のコメントになります。) 最初の3つのフィールドはそれぞれリテラル値か、任意のものにマッチする * を指定します。 現在の接続パラメータにマッチした最初の行のpassword フィールドが使用されます。 (したがって、ワイルドーカードを使用する場合には、具体的なエントリーの方を先に書きます。) エントリーの中に : か \ を含む必要がある場合には、その文字を \ をつかってエスケープしてください。 ホスト名 localhost はローカルマシンからの TCP と Unix ドメインソケットの両方の接続にマッチします。

.pcppass のパーミッションはグループおよび全ユーザからのアクセスを許してはいけません。 chmod 0600 ~/.pcppass を実行してください。これよりパーミッションの制限が弱い場合には、 このファイルは無視されます。

共通引数

全てのコマンドには共通する引数があります。そのほとんどは認証情報を指定するもので、 他は冗長出力モードやデバッグなどに関するものです。

-ex)
$ pcp_node_count [-d] 10 localhost 9898 postgres hogehoge
-h hostname, --host=hostname

pgpool-II が稼働しているホスト名を指定します。 スラッシュから始まる場合は、Unix ドメインソケットのディレクトリと解釈されます。

-p port, --port=port

PCP ポート番号を指定します。(デフォルト: 9898)

-u username, --username=username

PCP 認証のユーザ名を指定します。(デフォルト: OS のユーザ)

-w, --no-password

パスワード入力プロンプトを表示しません。 もしパスワードが .pcppass ファイルから取得できない場合には接続は失敗します。 このオプションはバッチジョブやスクリプトなど、パスワード入力が行うユーザいない場合に有用です。

-W, --password

パスワード入力プロンプトを表示します。(自動的に選択される動作です)

-d, --debug

デバッグメッセージを表示します。

-v, --verbose

冗長出力を有効にします。

-V, --version

バージョンを表示して終了します。

-?, --help

コマンドラインのヘルプを表示して終了します。

情報を取得するコマンド群

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

pcp_node_count

書式
pcp_node_count [options...] 
説明

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

オプション

common options を参照してください。

pcp_node_info

書式
pcp_node_info [options...] [node_id] 
説明

指定されたノードの情報を表示します。

オプション
-n node_id, --node-id=node_id

情報を表示するバックエンドノードのインデックスを指定します。

その他

common options を参照してください。

出力例
$ pcp_node_info -h localhost -U postgres 0
host1 5432 1 1073741823.500000

結果は以下の順のとおりです。

  1. ノードのホスト名
  2. ノードのポート番号
  3. ステータス
  4. ロードバランスウェイト

ステータスは [0..3] までの数字で表わされます。各数字の意味は以下のとおりです。

  • 0 - 初期化時のみに表われる。PCP コマンドで表示されることはない。
  • 1 - ノード稼働中。接続無し
  • 2 - ノード稼働中。接続有り
  • 3 - ノードダウン

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

--verbose オプションは出力内容を理解するのに役に立ちます。例:

$ pcp_node_info --verbose -h localhost -U postgres 0
Hostname: host1
Port    : 5432
Status  : 1
Weight  : 0.5

pcp_watchdog_info

書式
pcp_watchdog_info [options...] [watchdog_id]
説明

pgpool-II の pgpool.conf の watchdog セクションで定義された pgpool-II の watchdog ステータスを表示します。

watchdog_id は情報を取得する watchdog ノードのインデックです。 省略された場合には、クラスタ中の全ての pgpool-II の watchdog ノードのステータスが表示されます。

watchdog_id = 0 はローカルの pgpool-II ノードのために予約されています。 そのため、リモートの watchdog ノードのインデックスは 1 から始まります。pgpool.conf ではリモート watchdog ノードのインデックスは 0 をベースにしていますが、pcp_watchdog_info ではそれが 1 から始まることに注意してください。 pcp_watchdog_info コマンドで情報を取得する際には、他の watchdog のインデックスに 1 を足す必要があります。

例えば、other_pgpool_hostname0 パラメータで定義されている、添字 0 である最初のリモート watchdog ノードの情報を取得するには、pcp_watchdog_info で watchdog_id = 1 を指定します。

オプション
-n watchdog_id, --node-id=watchdog_id

情報を取得する他の pgpool-II のインデックスを指定します。

0 の場合ははローカルの watchdog の情報を取得します。

省略された場合は、全ての watchdog ノードの情報を取得します。

その他

common options を参照してください。

出力例
$ pcp_watchdog_info -h localhost -u postgres

3 NO Linux_host1.localdomain_9991 host1

Linux_host1.localdomain_9991 host1 9991 9001 7 STANDBY
Linux_host2.localdomain_9992 host2 9992 9002 4 MASTER
Linux_host3.localdomain_9993 host3 9993 9003 7 STANDBY

結果は以下の順のとおりです。

最初に出力される行は、watchdog クラスタの情報を示しています:

  1. クラスタ内の全 watchdog ノード数
  2. 仮想 IP がこのノードで起動しているか?
  3. マスターノード名
  4. マスターノードホスト

それ以降は watchdog ノードのリストが出力されます:

  1. ノード名
  2. ホスト名
  3. pgpool ポート番号
  4. watchdog ポート番号
  5. 現在のノードステータス
  6. 現在のノードステータス名
verbose モード:
$ pcp_watchdog_info -h localhost -v -u postgres

Watchdog Cluster Information
Total Nodes          : 3
Remote Nodes         : 2
Quorum state         : QUORUM EXIST
Alive Remote Nodes   : 2
VIP up on local node : NO
Master Node Name     : Linux_host2.localdomain_9992
Master Host Name     : localhost

Watchdog Node Information
Node Name      : Linux_host1.localdomain_9991
Host Name      : host1
Delegate IP    : 192.168.1.10
Pgpool port    : 9991
Watchdog port  : 9001
Node priority  : 1
Status         : 7
Status Name    : STANDBY

Node Name      : Linux_host2.localdomain_9992
Host Name      : host2
Delegate IP    : 192.168.1.10
Pgpool port    : 9992
Watchdog port  : 9002
Node priority  : 1
Status         : 4
Status Name    : MASTER

Node Name      : Linux_host3.localdomain_9993
Host Name      : host3
Delegate IP    : 192.168.1.10
Pgpool port    : 9993
Watchdog port  : 9003
Node priority  : 1
Status         : 7
Status Name    : STANDBY

pcp_proc_count

書式
pcp_proc_count [options...] 
説明

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

オプション

common options を参照してください。

pcp_proc_info

書式
pcp_proc_info [options...] [processid] 
説明

pgpool-II の子プロセス情報を表示します。

オプション
-P PID, --process-id=PID

pgpool-II 子プロセスの PID を指定します。

その他

common options を参照してください。

出力例
$ pcp_proc_info 10 localhost 9898 postgres hogehoge 3815
postgres_db postgres 1150769932 1150767351 3 0 1 14067 1
postgres_db postgres 1150769932 1150767351 3 0 1 14068 1

結果は以下の順のとおりです。

  1. 接続しているデータベース名
  2. 接続しているユーザ名
  3. プロセススタート時刻
  4. コネクション作成時刻
  5. プロトコルメジャーバージョン
  6. プロトコルマイナーバージョン
  7. コネクション使用回数
  8. PostgreSQL バックエンドプロセスID
  9. フロントエンドから接続がある場合は 1、そうでなければ 0

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

--verbose オプションは出力内容を理解するのに役に立ちます。例:

$ pcp_proc_info --verbose -U postgres 3815
Database     : postgres_db
Username     : postgres
Start time   : 1150769932
Creation time: 1150767351
Major        : 3
Minor        : 0
Counter      : 1
PID          : 1467
Connected    : 1
Database     : postgres_db
Username     : postgres
Start time   : 1150769932
Creation time: 1150767351
Major        : 3
Minor        : 0
Counter      : 1
PID          : 1468
Connected    : 1

pcp_pool_status V3.1 〜

書式
pcp_pool_status [options...]
説明

pgpool.conf のパラメータ設定値を取得します。

オプション

common options を参照してください。

出力例
$ pcp_pool_status 10 localhost 9898 postgres hogehoge
name : listen_addresses
value: localhost
desc : host name(s) or IP address(es) to listen to

name : port
value: 9999
desc : pgpool accepting port number

name : socket_dir
value: /tmp
desc : pgpool socket directory

name : pcp_port
value: 9898
desc : PCP port # to bind

ノード等を操作するコマンド群

pcp_detach_node

書式
pcp_detach_node [options...] [node_id] [grecefully]
説明

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

すでにpgpool-IIに接続しているセッションは強制的に切断されます。

オプション
-n node_id, --node-id=node_id

切り離すバックエンドノードのインデックスを指定します。

-g, --gracefully

すべてのクライアントが接続を終了するまでノードを復帰しません。 (ただし、client_idle_limit_in_recovery が -1 あるいは、recovery_timeout が設定されている場合を除く)

その他

common options を参照してください。

pcp_attach_node

書式
pcp_attach_node [options...] [node_id]
説明

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

オプション
-n node_id, --node-id=node_id

復帰させるバックエンドノードのインデックスを指定します。

その他

common options を参照してください。

pcp_promote_node V3.1 〜

書式
pcp_promote_node [options...] [node_id] [gracefully]
説明

pgpool-II のノードをマスターに昇格させます。これは、マスタースレーブモードで ストリーミングレプリケーション構成の場合のみ使用できます。 このコマンドは実際にPostgreSQLのスタンバイサーバを昇格するわけではないことに注意してください。 単にpgpool-IIの内部ステータスを変更し、フェイルオーバするだけです。 ですので、ユーザはこのコマンドを使う際には自分でPostgreSQLのスタンバイを昇格させるようにしてください。

オプション
-n node_id, --node-id=node_id

マスターに昇格させるバックエンドノードのインデックスを指定します。

-g, --gracefully

すべてのクライアントが接続を終了するまでノードを復帰しません。 (ただし、client_idle_limit_in_recovery が -1 あるいは、recovery_timeout が設定されている場合を除く)

その他

common options を参照してください。

pcp_stop_pgpool

書式
pcp_stop_pgpool [options...] [mode]
説明

pgpool-IIを指定されたモードでシャットダウンします。

オプション
-m mode, --mode=mode

シャットダウンモードを指定します。指定できるモードは以下のとおりです。

  • s, smart : smart モード
  • f, fast : fast モード
  • i, immediate : immediate モード

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

その他

common options を参照してください。

pcp_recovery_node

書式
pcp_recovery_node [options...] [node_id] 
説明

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

オプション
-n node_id, --node-id=node_id

バックエンドノードのインデックスを指定します。

その他

common options を参照してください。

pool_adm

pgpoo_adm はSQLからPCPコマンド(実際にはpcpライブラリ)にアクセスすることを可能にするextensionです。 pgpool_admは、下の図に示すように、foreign data wrapper を使っています。

Data flow in pgpool_adm

関数は、pgpool-II経由で呼び出すことも(1)、PostgreSQL直接で呼び出すこともできます(2)。 (1)の場合では、pgpool-IIはユーザからのクエリを受け付け(1)、PostgreSQLに転送します(3)。 PostgreSQLはpgpool-IIに接続し(5)、pgpool-IIはPostgreSQLに結果の値を返します(3)。 PostgreSQLは結果をpgpool-IIに返却し(5)、pgpool-IIはデータをユーザに転送します(6)。

(2)のケースでは、PostgreSQLはクエリをユーザから受け付けます(2)。 PostgreSQLはpgpool-IIに接続し(5)、pgpool-IIはPostgreSQLに結果の値を返します(3)。 PostgreSQLははユーザに結果を返します(6)。

pgpool_admの呼び出し方法は2つあります。最初の形式は、pgpool-IIのホスト名(またはIPアドレス)、PCPポート番号、PCPユーザ名、パスワード、そして他のパラメータを渡します。

後者の形式では、pgpool-IIのサーバ名が必要です。 サーバ名は「CREATE FOREIGN SERVER」コマンドであらかじめ登録しておかなければなりません。 PCPポート番号は9898にハードコードされています。 PCPユーザ名はPostgreSQLのユーザ名と同じと見なされます。 パスワードは、$HOME/.pcppassから取得されます。

Installing pgpool_adm

pgpool_admはextensionなので、すべてのPostgreSQLサーバにインストールしておかなければなりません。

$ cd src/sql/pgpool_adm
$ make
$ make install

次に下のSQLコマンドをアクセスしたいデータベース全てで実行します。

$ psql ...
$ CREATE EXTENSION pgpool_adm

pgpool_adm functions list

pcp_node_info ノード情報を取得します
pcp_pool_status pgpool.confのパラメータを取得します
pcp_node_count ノード数を取得します
pcp_attach_node pgpool-IIにノードをアタッチします
pcp_detach_node pgpool-IIからノードをデタッチします

pcp_node_info

形式:
pcp_node_info(integer node_id, text host, integer port, text username, text password, OUT status text, OUT weight float4) returns record
pcp_node_info(integer node_id, text pcp_server, OUT status text, OUT weight float4) returns record
説明:

ノード情報を取得します。 詳細はpcp_node_infoコマンドを参照してください。

実行例を示します。

test=# SELECT * FROM pcp_node_info(0,'',11001,'t-ishii','t-ishii');
 host | port  |      status       | weight 
------+-------+-------------------+--------
 /tmp | 11002 | Connection in use |      0
(1 row)

引数:
node_id

バックエンドノードの番号

host

PCPが稼働中のホスト名とIPアドレス

port

PCPサーバがリッスンしているポート番号です

username

PCPサーバにアクセスするためのユーザ名

password

PCPサーバにアクセスするためのパスワード

pcp_server

PCPサーバのforeign server名

pcp_pool_status

形式:
pcp_pool_status(text host, integer port, text username, text password) returns record
pcp_pool_status(text pcp_server) returns record
説明:

pgpool.confのパラメータを取得します。 See pool_status for more details.

実行例を示します。

test=# SELECT * FROM pcp_pool_status('localhost',11001,'t-ishii','t-ishii') WHERE item ~ 'backend.*0';
          item           |                     value                      |          description          
-------------------------+------------------------------------------------+-------------------------------
 backend_hostname0       | /tmp                                           | backend #0 hostname
 backend_port0           | 11002                                          | backend #0 port number
 backend_weight0         | 0.500000                                       | weight of backend #0
 backend_data_directory0 | /home/t-ishii/work/pgpool-II/current/aaa/data0 | data directory for backend #0
 backend_status0         | 2                                              | status of backend #0
 backend_flag0           | ALLOW_TO_FAILOVER                              | backend #0 flag
(6 rows)

引数:
host

PCPが稼働中のホスト名とIPアドレス

port

PCPサーバがリッスンしているポート番号

username

PCPサーバにアクセスするためのユーザ名

password

PCPサーバにアクセスするためのパスワード

pcp_server

PCPサーバのforeign server名

pcp_node_node_count

形式:
pcp_node_count(integer node_id, text host, integer port, text username, text password, OUT node_count integer) returns integer
pcp_node_count(integer node_id, OUT node_count integer) returns record
説明:

ノード数を取得します。 詳細はpcp_node_countコマンドを参照してください。

実行例を示します。

test=# SELECT * FROM pcp_node_count('localhost',11001,'t-ishii','t-ishii');
 node_count 
------------
          2
(1 row)

引数:
host

PCPが稼働中のホスト名とIPアドレス

port

PCPサーバがリッスンしているポート番号です

username

PCPサーバにアクセスするためのユーザ名

password

PCPサーバにアクセスするためのパスワード

pcp_server

PCPサーバのforeign server名

pcp_attach_node

形式:
pcp_attach_node(integer node_id, text host, integer port, text username, text password, OUT node_attached boolean) returns boolean
pcp_attach_node(integer node_id, text pcp_server, OUT node_attached boolean) returns boolean
説明:

attaches a node to pgpool-II. 詳細はpcp_attach_nodeコマンドを参照してください。

実行例を示します。

test=# SELECT * FROM pcp_attach_node(1,'localhost',11001,'t-ishii','t-ishii');
 node_attached 
---------------
 t
(1 row)

説明:
node_id

バックエンドノードの番号

host

PCPが稼働中のホスト名とIPアドレス

port

PCPサーバがリッスンしているポート番号

username

PCPサーバにアクセスするためのユーザ名

password

PCPサーバにアクセスするためのパスワード

pcp_server

PCPサーバのforeign server名

pcp_detach_node

形式:
pcp_detach_node(integer node_id, boolean gracefully, text host, integer port, text username, text password, OUT node_detached boolean) returns boolean
pcp_detach_node(integer node_id, boolean gracefully, text pcp_server, OUT node_detached boolean) returns boolean
説明:

Detaches a node to pgpool-II and initiate fail over. See pcp_detach_node for more details.

実行例を示します。

test=# SELECT * FROM pcp_detach_node(1, 'false', 'localhost',11001,'t-ishii','t-ishii');
 node_detached 
---------------
 t
(1 row)

引数:
node_id

バックエンドノードの番号

gracefully

もしtrueなら、pgpool-IIのすべてのセッションが切断されるまで待ちます。 実際には、この引数にtrueをセットするのはおすすめできません。 なぜなら、このSQLの結果を待っているセッション自体が終わらないからです。 このパラメータはfalseにすることを強くおすすめします。

host

PCPが稼働中のホスト名とIPアドレス

port

PCPサーバがリッスンしているポート番号です

username

PCPサーバにアクセスするためのユーザ名

password

PCPサーバにアクセスするためのパスワード

pcp_server

PCPサーバのforeign server名

トラブルシューティング

この章では、pgpool-IIを運用中に直面しやすい障害と、その対策方法をケース別に説明します。

health check failed

ヘルスチェックでpgpool-IIがDBノードの障害を検出しました。

2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
2010-07-23 16:42:57 LOG:   pid 20031: set 1 th backend down status
2010-07-23 16:42:57 LOG:   pid 20031: starting degeneration. shutdown host foot(5432)
2010-07-23 16:42:58 LOG:   pid 20031: failover_handler: set new master node: 0
2010-07-23 16:42:58 LOG:   pid 20031: failover done. shutdown host foo(5432)

このログは、DBノード1(ホスト名 foo)がダウンして切り離され、 新しくDBノード0がマスタとして扱われ出したことを示しています。 DBノード1をチェックし、異常原因を取り除いた後に、可能であればオンラインリカバリ機能を使っ てDBノード1を復帰させてください。

failed to read kind from frontend
2010-07-26 18:43:24 LOG:   pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited

pgpool-IIから見てクライアントが突然セッションを切断した際にこのようなログが残ります。 原因としては、アプリケーションのバグ、アプリケーションが強制終了された、 やネットワークの一時的な障害が考えられます。 このログが出ても、DBが壊れるとか一貫性がなくなるような問題は起きませんが、 継続してこのログが出力されるようであれば、アプリケーションやネットワークの障害を調査することをおすすめします。

kind mismatchエラー

レプリケーションモードで運用している場合に出ることがあるエラーです。

2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]

pgpool-IIは、SQLコマンドを各DBノードに送信したら、各DBノードから同じレスポンスが返ってくることを期待します。 このエラーは、異なるレスポンスが返ってきたことを示します。 Possible last query was:のあとに、このエラーを返す原因となった問い合わせのSQL文が表示されます。 そのあとで、各DBノードからのレスポンスの種類と、レスポンスがエラーの場合は、 PostgreSQLのエラーメッセージが表示されます。 ここでは、"0[T]"により、0番目のDBノードが"T"(行情報の開始)という応答を返したこと、 一方"1[E"で、DBノード1がエラーを返したとこと、そのエラーメッセージは 「cursor "c" does not exist」であったことがわかります。

注意: このエラーは、マスタースレーブモードでも出ることがあります。 たとえば、SETコマンドは、各セッションの状態を同じにするために、基本的にすべてのDBノードに送信されるからです。

データベースを調べて原因を特定し、もしDBの同期が崩れているようであれば、 オンラインリカバリを使って正しいデータと同期させてください。

pgpool detected difference of the number of inserted, updated or deleted tuples

レプリケーションモードにおいて、pgpool-IIが、DBノード間でINSERT/UPDATE/DELETEが返す結果行の違いを検出しました。

2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Degenerate backends: 1
2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Affected tuples are: 0 1

この例では、update t1 set i = 1によって更新された行数が、DBノードで異なっています。 また、次の行では、DBノード1を切り離したこと、更にDBノード0での結果行数が0だったのに対して、DBノード1では、1行だったことを表しています。

正しくないデータを持っていると思われるDBノードを停止し、オンラインリカバリを使って 正しいデータと同期させてください。

制限事項

PostgreSQLの機能

認証・アクセス制御方式

一時テーブルの扱い

制限対象:マスタースレーブモード

一時テーブルの作成、更新は常にマスタ(primary)で行なわれます。 一時テーブルの検索も、pgpool-II 3.0以降では、マスタで行なわれるので、 一時テーブルを使っているかどうかを意識する必要はありません。 ただし、文字列として一時テーブル名をSELECTの中で使っている場合は一時テーブルかどうかの確認のしようがないので、 負荷分散されてしまい、その一時テーブルが見つからないか、 もしくは同じ名前の別のテーブルを検索してしまうことになります。 そのような問い合わせは避けるか、/*NO LOAD BALNCE*/のコメントを挿入してください。

SELECT 't1'::regclass::oid;

ちなみに、psqlの\dコマンドのように、システムカタログを問い合わせる中で 文字列としてのテーブル名を使っている場合は、pgpool-II 3.0以降ではマスタで検索が行なわれるので、問題になりません。 なぜなら、システムカタログへの検索は常にマスタで行なわれるからです。

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

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

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

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

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 では扱うことができないクエリについて説明します。

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

制限対象:全モード

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

マルチステートメント

制限対象:全モード

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

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

ビルドに必要な環境

libpq

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

リリースノート


3.5.1 (ekieboshi) 2016/04/04

概要

このバージョンは 3.5.0 に対するバグ修正リリースです。

バグ修正

3.5.0 (ekieboshi) 2016/01/29

概要

このバージョンは 3.5 系列の最初の版で、3.4 系からの「メジャーバージョンアップ」にあたります。

互換性のない変更

新機能

改善点

バグ修正 (pgpool-II 3.4.3以降のもの)


3.4.5 (tataraboshi) 2016/04/04

概要

このバージョンは 3.4.4 に対するバグ修正リリースです。

バグ修正

3.4.4 (tataraboshi) 2016/02/05

概要

このバージョンは 3.4.3 に対するバグ修正リリースです。

バグ修正

3.4.3 (tataraboshi) 2015/07/24

概要

このバージョンは 3.4.2 に対するバグ修正リリースです。

バグ修正

3.4.2 (tataraboshi) 2015/04/08

概要

このバージョンは 3.4.1 に対するバグ修正リリースです。

バグ修正

3.4.1 (tataraboshi) 2015/02/05

概要

このバージョンは 3.4.0 に対するバグ修正リリースです。

バグ修正

3.4.0 (tataraboshi) 2014/11/07

概要

このバージョンは 3.4 系列の最初の版で、3.3 系からの「メジャーバージョンアップ」にあたります。

互換性のない変更

新機能

改善点

バグ修正(pgpool-II 3.3.4以降のもの)


3.3.9 (tokakiboshi) 2016/04/04

概要

このバージョンは 3.3.8 に対するバグ修正リリースです。

バグ修正

3.3.8 (tokakiboshi) 2016/02/05

概要

このバージョンは 3.3.7 に対するバグ修正リリースです。

バグ修正

3.3.7 (tokakiboshi) 2015/07/24

概要

このバージョンは 3.3.6 に対するバグ修正リリースです。

バグ修正

3.3.6 (tokakiboshi) 2015/04/08

概要

このバージョンは 3.3.5 に対するバグ修正リリースです。

バグ修正

3.3.5 (tokakiboshi) 2015/02/05

概要

このバージョンは 3.3.4 に対するバグ修正リリースです。

バグ修正

3.3.4 (tokakiboshi) 2014/09/05

概要

このバージョンは 3.3.3 に対するバグ修正リリースです。

バグ修正

3.3.3 (tokakiboshi) 2014/03/24

概要

このバージョンは 3.3.2 に対するバグ修正リリースです。

バグ修正

3.3.2 (tokakiboshi) 2013/11/29

概要

このバージョンは 3.3.1 に対するバグ修正リリースです。

バグ修正

3.3.1 (tokakiboshi) 2013/09/06

概要

このバージョンは 3.3.0 に対するバグ修正リリースです。

バグ修正

3.3.0 (tokakiboshi) 2013/07/30

概要

このバージョンは 3.3 系列の最初の版で、3.2 系からの「メジャーバージョンアップ」にあたります。

互換性のない変更

以下は全て watchdog に関する変更です。詳細は以下の新機能の項目を 参照してください。

新機能

watchdog

その他

バグ修正

改良


3.2.14 (namameboshi) 2016/04/04

概要

このバージョンは 3.2.13 に対するバグ修正リリースです。

バグ修正

3.2.13 (namameboshi) 2016/02/05

概要

このバージョンは 3.2.12 に対するバグ修正リリースです。

バグ修正

3.2.12 (namameboshi) 2015/07/24

概要

このバージョンは 3.2.11 に対するバグ修正リリースです。

バグ修正

3.2.11 (namameboshi) 2015/04/08

概要

このバージョンは 3.2.10 に対するバグ修正リリースです。

バグ修正

3.2.10 (namameboshi) 2015/02/05

概要

このバージョンは 3.2.9 に対するバグ修正リリースです。

バグ修正

3.2.9 (namameboshi) 2014/09/05

概要

このバージョンは 3.2.8 に対するバグ修正リリースです。

バグ修正

3.2.8 (namameboshi) 2014/03/24

概要

このバージョンは 3.2.7 に対するバグ修正リリースです。

バグ修正

3.2.7 (namameboshi) 2013/12/06

概要

このバージョンは 3.2.7 に対するバグ修正リリースです。

バグ修正

3.2.6 (namameboshi) 2013/09/06

概要

このバージョンは 3.2.5 に対するバグ修正リリースです。

バグ修正

3.2.5 (namameboshi) 2013/07/10

概要

このバージョンは 3.2.4 に対するバグ修正リリースです。

バグ修正

3.2.4 (namameboshi) 2013/04/26

概要

このバージョンは 3.2.3 に対するバグ修正リリースです。

バグ修正

3.2.3 (namameboshi) 2013/02/18

概要

pgpool-II 3.2.2 に対するバグ修正リリースです。 おもに、3.2.2 のヘルスチェックに関する致命的な問題を修正するものです。

以下の条件がすべて満たされたとき、フェイルオーバ発生時に pgpool のメインプロセスが消滅し、 pgpool-II へのクライアントの接続がすべてハングします。 また、その状態から復帰するには、pgpool の子プロセスを手動で kill し、pgpool-II を 再起動するしかありませんでした。

バグ修正

3.2.2 (namameboshi) 2013/02/08

概要

このバージョンは 3.2.1 に対するバグ修正リリースです。

バグ修正

3.2.1 (namameboshi) 2012/10/12

概要

このバージョンは 3.2.0 に対するバグ修正リリースです。

バグ修正

3.2.0 (namameboshi) 2012/08/03

概要

このバージョンは 3.2 系列の最初の版で、3.1 系からの「メジャーバージョンアップ」にあたります。

互換性のない変更

新機能

改良

バグ修正


3.1.17 (hatsuiboshi) 2016/04/04

概要

このバージョンは 3.1.16 に対するバグ修正リリースです。

バグ修正

3.1.16 (hatsuiboshi) 2016/02/05

概要

このバージョンは 3.1.15 に対するバグ修正リリースです。

バグ修正

3.1.15 (hatsuiboshi) 2015/07/24

概要

このバージョンは 3.1.14 に対するバグ修正リリースです。

バグ修正

3.1.14 (hatsuiboshi) 2015/04/08

概要

このバージョンは 3.1.13 に対するバグ修正リリースです。

バグ修正

3.1.13 (hatsuiboshi) 2015/02/05

概要

このバージョンは 3.1.12 に対するバグ修正リリースです。

バグ修正

3.1.12 (hatsuiboshi) 2014/09/05

概要

このバージョンは 3.1.11 に対するバグ修正リリースです。

バグ修正

3.1.11 (hatsuiboshi) 2014/03/24

概要

このバージョンは 3.1.10 に対するバグ修正リリースです。

バグ修正

3.1.10 (hatsuiboshi) 2013/12/06

概要

このバージョンは 3.1.9 に対するバグ修正リリースです。

バグ修正

3.1.9 (hatsuiboshi) 2013/09/06

概要

このバージョンは 3.1.8 に対するバグ修正リリースです。

バグ修正

3.1.8 (hatsuiboshi) 2013/07/10

概要

このバージョンは 3.1.7 に対するバグ修正リリースです。

バグ修正

3.1.7 (hatsuiboshi) 2013/04/26

概要

このバージョンは 3.1.6 に対するバグ修正リリースです。

バグ修正

3.1.6 (hatsuiboshi) 2013/02/08

概要

このバージョンは3.1.5に対するバグ修正リリースです。

3.1.5 (hatsuiboshi) 2012/10/12

概要

このバージョンは3.1.4に対するバグ修正リリースです。

バグ修正

3.1.4 (hatsuiboshi) 2012/08/06

概要

このバージョンは3.1.3に対するバグ修正リリースです。

また、PostgreSQL 9.2 に対応しました。

バグ修正

3.1.3 (hatsuiboshi) 2012/04/23

概要

このバージョンは3.1.2に対するバグ修正リリースです。

バグ修正

3.1.2 (hatsuiboshi) 2012/01/31

概要

このバージョンは3.1.1に対するバグ修正リリースです。

バグ修正

3.1.1 (hatsuiboshi) 2011/12/06

概要

このバージョンは3.1に対するバグ修正リリースです。

バグ修正

3.1 (hatsuiboshi) 2011/09/08

概要

このバージョンは3.1系列の最初の版で、3.0系からの「メジャーバージョンアップ」にあたります。

互換性のない変更

新機能

バグ修正

改良


3.0.20 (umiyameboshi) 2016/02/05

概要

このバージョンは 3.0.19 に対するバグ修正リリースです。

これは 3.0 系の最終リリースです。pgpool-II 3.0 は End of Life となり、これ以上のメンテナンスやアップデートは行われません。

バグ修正

3.0.19 (umiyameboshi) 2015/07/24

概要

このバージョンは 3.0.18 に対するバグ修正リリースです。

バグ修正

3.0.18 (umiyameboshi) 2015/04/08

概要

このバージョンは 3.0.17 に対するバグ修正リリースです。

バグ修正

3.0.17 (umiyameboshi) 2015/02/05

概要

このバージョンは 3.0.16 に対するバグ修正リリースです。

バグ修正

3.0.16 (umiyameboshi) 2014/09/05

概要

このバージョンは 3.0.15 に対するバグ修正リリースです。

バグ修正

3.0.15 (umiyameboshi) 2014/03/24

概要

このバージョンは 3.0.14 に対するバグ修正リリースです。

バグ修正

3.0.14 (umiyameboshi) 2013/12/06

概要

このバージョンは 3.0.13 に対するバグ修正リリースです。

バグ修正

3.0.13 (umiyameboshi) 2013/09/06

概要

このバージョンは 3.0.12 に対するバグ修正リリースです。

バグ修正

3.0.12 (umiyameboshi) 2013/07/10

概要

このバージョンは 3.0.11 に対するバグ修正リリースです。

バグ修正

3.0.11 (umiyameboshi) 2013/04/26

概要

このバージョンでは、3.0.10における様々なバグが修正されています。

バグ修正

3.0.10 (umiyameboshi) 2013/02/08

概要

このバージョンでは、3.0.9における様々なバグが修正されています。

バグ修正

3.0.9 (umiyameboshi) 2012/10/12

概要

このバージョンでは、3.0.8における様々なバグが修正されています。

バグ修正

3.0.8 (umiyameboshi) 2012/08/06

概要

このバージョンでは、3.0.7における様々なバグが修正されています。

バグ修正

3.0.7 (umiyameboshi) 2012/04/23

概要

このバージョンでは、3.0.6におけるバグが修正されています。

バグ修正

3.0.6 (umiyameboshi) 2012/01/31

概要

このバージョンでは、3.0.5におけるバグが修正されています。

バグ修正

3.0.5 (umiyameboshi) 2011/10/31

概要

このバージョンでは、3.0.4における様々なバグが修正されています。

バグ修正

改良

3.0.4 (umiyameboshi) 2011/06/01

概要

このバージョンでは、3.0.3における様々なバグが修正されています。

互換性のない変更

バグ修正

改良

3.0.3 (umiyameboshi) 2011/02/23

概要

このバージョンでは、3.0.1における様々なバグが修正されています (pgpool-II 3.0.2のリリースはパッケージングの問題でキャンセルされました)。

互換性のない変更

バグ修正

改良

3.0.2(umiyameboshi) 2011/02/17

概要

このバージョンは問題があったために、リリースが取り消されました。

3.0.1 (umiyameboshi) 2010/10/19

概要

このバージョンでは、3.0における様々なバグが修正されています。

バグ修正

3.0 (umiyameboshi) 2010/09/10

概要

このバージョンは3.0系列の最初の版で、2.2系や2.3系からの「メジャーバージョンアップ」にあたります。 PostgreSQL 9.0の新機能であるStreaming Replication/Hot Standby構成に対応するなど、 多くの機能が追加されると共に、内部構造が整理されて見通しが良くなって保守性が向上しています。

マスタースレーブモード全般で多くの改善がなされています。

レプリケーションモードにおいても、書き込みを伴う関数呼び出しを行なうSELECTを負荷分散するかどうかの制御できるようになるなどの改良が加えられています。

新機能

互換性のない変更

バグ修正


2.3.4 (tomiteboshi) 2012/08/06

概要

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

バグ修正

2.3.3 (tomiteboshi) 2010/04/23

概要

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

互換性のない変更

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

バグ修正

2.3.2.2 (tomiteboshi) 2010/02/22

概要

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

バグ修正

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サポート、ラージオブジェクトのレプリケーション機能が追加されています。

改良点

バグ修正

2.3.1 (tomiteboshi) 2009/12/18

概要

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

バグ修正と改良点

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.からの非互換性

改良点


2.2.8 (urukiboshi) 2012/08/06

概要

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

バグ修正

2.2.7 (urukiboshi) 2010/04/15

概要

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

バグ修正

2.2.6 (urukiboshi) 2009/12/01

概要

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

バグ修正

2.2.5 (urukiboshi) 2009/10/4

概要

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

バグ修正

2.2.4 (urukiboshi) 2009/8/24

概要

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

バグ修正

2.2.3 (urukiboshi) 2009/8/11

概要

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

バグ修正

2.2.2 (urukiboshi) 2009/5/5

概要

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

バグ修正

2.2.1 (urukiboshi) 2009/4/25

概要

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

バグ修正

2.2 (urukiboshi) 2009/2/28

概要

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

新機能

互換性

バグ修正


2.1 (inamiboshi) 2008/7/25

新機能

互換性

修正

全般

レプリケーション

マスタースレーブ

パラレルクエリ


2.0.1 (hikitsuboshi) 2007/11/21

2.0 (hikitsuboshi) 2007/11/16

互換性

全般

レプリケーション

パラレルクエリ


1.3 (sohiboshi) 2007/10/23


1.2.1 (tomoboshi) 2007/09/28

1.2 (tomoboshi) 2007/08/01


1.1.1 (amiboshi) 2007/06/15

1.1 (amiboshi) 2007/05/25


1.0.2 (suboshi) 2007/02/13