Last modified: Fri May 16 16:43:02 JST 2014
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-2015 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 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モード(*3)レプリケーションモード マスタスレーブモードパラレルクエリモード
コネクションプーリング×
レプリケーション× ×△(*1)
負荷分散× △(*1)
フェイルオーバ ×
オンラインリカバリ× △(*2)×
パラレルクエリ×× ×
サーバ台数1以上2以上 2以上2以上
システムDB不要不要 不要必要

pcp.confの設定

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

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

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

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

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

./pg_md5 foo
acbd18db4cc2f85cedef654fccc4a4d8

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

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

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

pgpool.confの設定

サンプルファイル 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 を再起動してください。

backend_socket_dir 〜 V3.0

DEPRECATED(〜 3.0) このパラメータは、libpqのポリシーに合わせて削除されます。 代わりに backend_hostname パラメータを使ってください。

UNIXドメインソケット経由でpgpool-IIがPostgreSQLと接続する際に使用する PostgreSQLのUNIXドメインソケットが置かれているディレクトリです。デフォルト値は/tmpです。

このパラメータを変更した時には 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 を再起動してください。

child_life_time

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

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

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, FATAL, PANIC が指定でき、左に行くほど冗長です。 デフォルトは 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_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 〜

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

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

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の子プロセスをすべて再起動します。

パラレルモード

DEPRECATED(〜 3.4) このモードは3.5.0以降削除されます。利用を推奨しません。

パラレルクエリ機能が利用できるモードです。 テーブルを分割させ、各ノードにデータを持たせることができます。またレプリケーションや負荷分散機能も同時に使うことができます。

パラレルモードでは、pgpool.confのreplication_modeまたは loadbalance_modeにtrueを設定し、 master_slave をfalseにし、 parallel_mode をtrueにします。 このパラメータを変更した時には pgpool-I