Pgpool-II 4.7 では、クライアント情報表示機能や、Watchdog と heartbeat receiver のセキュリティ強化、オンラインリカバリの機能が強化されました。また、フロントエンド/バックエンドプロトコルバージョン 3.2 サポートの追加、PostgreSQL 18 への対応も行われました。

Pgpool-II 4.7 の新機能及び変更点は Pgpool-II 公式ドキュメントの以下のページに記載されています。

Pgpool-II 4.7 リリースノート

本記事では、これらの新機能について詳しく紹介します。

クライアント情報を表示するための pcp_proc_info, show pool_pools の機能強化

4.6 までは Pgpool-II 経由で PostgreSQL に接続した場合、PostgreSQL 側からは各クライアントの接続情報を確認することができず、Pgpool-II のネットワークアドレスとポート番号のみしかわかりませんでした。
そのため障害が起きてもどのクライアント接続で障害が発生しているのかを調査することが困難でした。

4.7 からは pcp_proc_info, show pool_pools コマンドで Pgpool-II 経由で接続しているクライアントのホスト名、ポート番号、最後に実行した SQL を参照できるようになりました。

Pgpool-II の子プロセス情報を表示する pcp_proc_info コマンドでは client_host(ホスト名), client_port(ポート番号), statement(最後に実行した SQL) が追加されました。

これにより PostgreSQL からでも Pgpool-II 経由で接続しているクライアントの接続情報や最後に実行したクエリ情報を参照できるようになり障害時などに障害が起きているクライアント接続を調査することが容易になりました。

sraoss@server1:~/setuptest$ pcp_proc_info -p 50001 --verbose
Database : test
Username : sraoss
Start time : 2026-01-08 12:15:18 (0:15 before process restarting)
Client connection count : 1
Major : 3
Minor : 0
Backend connection time : 2026-01-08 12:15:18
Client connection time : 2026-01-08 12:15:18
Client idle duration : 0
Client disconnection time : 2026-01-08 12:16:38
Pool Counter : 1
Backend PID : 20250
Connected : 0
PID : 20195
Backend ID : 0
Status : Wait for connection
Load balance node : 0
client_host : 127.0.0.1
client_port : 54726
statement : SELECT 1;

Pgpool-II のコネクションプールの状態を表示する show pool_pools コマンドにも、client_host(ホスト名), client_port(ポート番号), statement(最後に実行した SQL) が追加されました。

これらの変更で子プロセスやコネクションプーリングの情報とあわせてクライアント情報を参照できるようになりました。

test=# show pool_pools;
 pool_pid |                      start_time                      | client_connection_count | pool_id | backend_id | database | username | backend_connection_time | client_connection_time | client_disconnection_time | client_idle_duration | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected |       status        | load_balance_node |  client_host  | client_port |  statement  
----------+------------------------------------------------------+-------------------------+---------+------------+----------+----------+-------------------------+------------------------+---------------------------+----------------------+--------------+--------------+--------------+-----------------+----------------+---------------------+-------------------+---------------+-------------+-------------
[snip]
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 0       | 0          | test     |  sraoss  | 2025-06-24 10:55:58     | 2025-06-24 10:55:59    |                           | 0                    | 3            | 0            | 1            | 1336703         | 1              | Idle                | 0                 | 192.168.10.11 | 39216       | 
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 0       | 1          | test     |  sraoss  | 2025-06-24 10:55:58     | 2025-06-24 10:55:59    |                           | 0                    | 3            | 0            | 1            | 1336704         | 1              | Idle                | 1                 | 192.168.10.11 | 39216       | select 1;
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 1       | 0          |          |          |                         |                        |                           | 0                    | 0            | 0            | 0            | 0               | 0              | Idle                | 0                 | 192.168.10.11 | 39216       | 
 1336537  | 2025-06-24 10:53:35                                  | 0                       | 1       | 1          |          |          |                         |                        |                           | 0                    | 0            | 0            | 0            | 0               | 0              | Idle                | 0                 | 192.168.10.11 | 39216       | select 1;

pgpool_adm_pcp_proc_info 関数の追加

pgpool_adm エクステンションに、Pgpool-II の子プロセスの情報を表示する pgool_adm_pcp_proc_info 関数が追加されました。 pgpool_adm エクステンションは Pgpool-II 経由でも、あるいは直接 PostgreSQL から呼び出せる関数群です。

pgool_adm_pcp_proc_info で表示される情報は pcp_proc_info コマンドと同様ですが、pgpool_adm エクステンションの関数であるため 、PostgreSQL クライアントからでも呼び出せます。

pgpool_adm を使うメリットは、SQLが使用でき WHERE 句で条件を指定して表示内容を絞り込むことができることです。(pcp コマンドの場合は、出力結果を整形するために OS のコマンドを併用する必要があります。)

導入には以下コマンドで各サーバーで pgpool_adm をインストールしてください。

# 各サーバーで以下を実行してインストール 
$ psql test
test=# CREATE EXTENSION pgpool_adm;

その後 Pgpool-II や PostgreSQL のクライアント上で pgpool_adm_pcp_proc_info を実行します。
connected 列は接続状況を表示(0=接続なし, 1=接続中) しており、今回の例のように WHERE 句に “connected = 1” を指定することで接続中の情報に絞ることもできます。

test=# select * from pcp_proc_info(host => '', port => 11001, username => 'sraoss', password => 'sraoss') where connected = '1';
-[ RECORD 1 ]-------------+----------------------------------------------------------------------------------------------------------------------------
database                  | test
username                  | sraoss
start_time                | 2026-01-08 10:56:08
client_connection_count   | 0
major                     | 3
minor                     | 0
backend_connection_time   | 2026-01-08 10:58:37
client_connection_time    | 2026-01-08 10:58:37
client_idle_duration      | 0
client_disconnection_time | 
pool_counter              | 1
backend_pid               | 14750
connected                 | 1
pid                       | 14585
backend_id                | 0
status                    | Execute command
load_balance_node         | 1
client_host               | 127.0.0.1
client_port               | 59120
statement                 | select * from pcp_proc_info(host => '', port => 11001, username => 'sraoss', password => 'sraoss') where connected = '1';

また pg_stat_activity と組み合わせてより詳細な情報を表示することも可能です。
以下の SQL では pgpool_adm_pcp_proc_info とpg_stat_activity を結合して pgool_adm_pcp_proc_info では取得できない state を pg_stat_activity をから取得しています。
他にも wait_event など pg_stat_activity にしかない情報も同時に取得するなど要件に応じてクライアント情報を取得できます。

test=# SELECT p.username, p.database, p.client_port, s.state, s.wait_event, s.query,
              p.pid as pgpool_pid, s.pid as backend_pid
              FROM pcp_proc_info(host => '', port => 11001,
                                 username => 'sraoss', password => 'sraoss') AS p
              JOIN pg_stat_activity AS s ON s.pid::text = p.backend_pid;
-[ RECORD 1 ]-------------+----------------------------------------------------------------------------------------------------------------------------
username                  | sraoss
 database                 |  test
 client_host              | 192.168.100.101
client_port               | 50001
state                     | active  
query                     | select 1;
pgpool_pid                | 21467
backend_pid               | 21500

ライフチェックログの改善

ライフチェックが開始したとき Watchdog は ライフチェックが開始したことを知らせるログを出力します。
4.6 までは正常に開始したタイミングでしかログが出力されないため、正常に動作しているかを確認するために開始ログが出るまでログを監視する必要があり、またライフチェックが正常に開始していない状況に気づくのが困難でした。

LOG:  watchdog: lifecheck started

4.7 からはライフチェックが開始されるまで定期的にライフチェックが開始していない警告を出力するようになり、ライフチェック開始までログファイルを監視する必要がなくなりました。
間隔は wd_interval × 10 秒です。

WARNING:  watchdog: lifecheck has not started yet

Watchdog と heartbeat receiver のセキュリティ強化

Watchdog と heartbeat receiver が受け付けるアドレスを制限することができるようになりました。

4.6 まではいずれのプロセスも、ホストが持つすべてのネットワークアドレスへの接続を受け付けていました。

tcp        0      0 0.0.0.0:9000            0.0.0.0:*     LISTEN   3583037/pgpool: watchdog
Tcp6       0      0 :::9000                 :::*          LISTEN   3583037/pgpool: watchdog
Udp        0      0 0.0.0.0:9694            0.0.0.0:*              3583050/pgpool: heartbeat receiver
udp        0      0 0.0.0.0:9694            0.0.0.0:*              3583044/pgpool: heartbeat receiver
udp6       0      0 :::9694                 :::*                   3583044/pgpool: heartbeat receiver
udp6       0      0 :::9694                 :::*                   3583050/pgpool: heartbeat receiver

4.7 からはセキュリティ上の点から hostname, heartbeat_hostname で指定したネットワークアドレスへのみ接続を受け付けるようになりました。

# pgpool.conf 設定例
hostname0 = '192.168.100.50'
wd_port0 = 9000
heartbeat_hostname0 = '192.168.100.101'
heartbeat_port0 = 9694
hostname1 = '192.168.100.60'
wd_port0 = 9000
heartbeat_hostname1 = '192.168.100.102'
heartbeat_port1 = 9694
hostname2 = '192.168.100.70'
wd_port0 = 9000
heartbeat_hostname2 = '192.168.100.103'
heartbeat_port2 = 9694

tcp        0      0 192.168.100.50:9000    0.0.0.0:*     LISTEN      41636/pgpool: watchdog
tcp        0      0 192.168.100.50:9000    0.0.0.0:*     LISTEN      41638/pgpool: watchdog
udp        0      0 192.168.100.101:9694   0.0.0.0:*                 41649/pgpool: heartbeat receiver
udp        0      0 192.168.100.101:9694   0.0.0.0:*                 41650/pgpool: heartbeat receiver

もし他ノードから hostname, heartbeat_hostname で指定したネットワークアドレス以外へ heartbeat を送る設定とすると以下メッセージのように lifecheck に失敗します。
4.7 へ移行する場合は hostname, heartbeat_hostname で watchdog と heartbeat で LISTEN するソケットを設定し、他ノードから heartbeat を送るソケットを hostname, heatbeat_hostname で指定したネットワークアドレスとしてください。

WARNING:  watchdog: lifecheck has not started yet

また 4.7. 1 ではさらに Watchdog と heartbeat それぞれについて LISTEN するソケットを個別で指定できるようになりました。
これによりノード外部から見えるアドレスと、ノード内部から認識されるアドレスが異なる可能性があるコンテナ環境や、ポートフォワーディングを設定している場合でも、より柔軟に設定できるようになりました。
Watchdog については wd_listen_address によってネットワークアドレスを、wd_listen_port によってポートも指定することができます。
heartbeat についてはそれぞれ wd_heartbeat_listen_addresses, wd_heartbeat_listen_port によって指定できます。
これらのパラメータが設定されているとき hostname, heartbeat_hostname, wd_port, heartbeat_port のローカルの設定は上書きされてソケットが作成されます。

# pgpool.conf 設定例
hostname0 = '192.168.100.50'
wd_port0 = 9000
heartbeat_hostname0 = '192.168.100.101'
heartbeat_port0 = 9694
wd_listen_address = 192.168.100.100
wd_listen_port = 50000
wd_heartbeat_listen_addresses = 102.168.100.110
wd_heartbeat_listen_port = 51000

tcp        0      0 192.168.100.100:50000    0.0.0.0:*     LISTEN      41636/pgpool: watchdog
udp        0      0 192.168.100.110:51000    0.0.0.0:*                 41649/pgpool: heartbeat receiver
udp        0      0 192.168.100.110:51000    0.0.0.0:*                 41650/pgpool: heartbeat receiver

これらのパラメータが導入された背景は、Docker 環境を代表とした TCP 転送ルールを設けているインターフェース間で通信をする際に LISTEN するソケットを転送ルールに合わせて設定したいケースに対応するためです。
例えばノード 0 が IP:192.168.0.0, ポート番号:10000 のソケットに接続しようとし、TCP 転送ルールによってノード 1 の IP:192.168.100.100,ポート番号:20000 のソケットにリダイレクトされる環境の場合、ノード 1 側でリダイレクト後のネットワークアドレス、ポート番号(今回の例では IP:192.168.100.100, ポート番号:20000)に設定することで TCP 転送ルールがある場合でも通信が可能となりました。

オンラインリカバリに使用するデータベースを指定する recovery_database パラメータの追加

オンラインリカバリとは障害が発生して切り離されてしまった PostgreSQL ノードをプライマリに再同期して復帰する処理を各ノードを停止することなく行うことができる機能です。

以前はオンラインリカバリに template1 データベースを使用するようにしていましたが、今回追加された recovery_databse パラメータにオンラインリカバリに使用するデータベースを指定することができるようになりました。

#pgpool.conf の recovery_database を指定
recovery_database = 'postgres'

デフォルト値は postgres になっています。
4.6 以前から移行をする際には recovery_database に指定したデータベースで下記コマンドを実施してオンラインリカバリに必要な関数をインストールしておく必要があります。

psql postgres -c "CREATE EXTENSION pgpool_recovery"

.pcppassファイルからの読み取りに失敗時の挙動改善

.pcppass ファイルは pcp コマンドを実行したときに読み込まれるパスワードファイルです。

4.6 までは pcp コマンド実行時に .pcppass ファイルが未作成かパスワードファイルの権限設定が不適切の場合、エラーで終了していました。
また -d, –debug オプションがないとデバッグ情報が出力されず失敗の原因も特定できませんでした。

FATAL:  authentication failed for user "sraoss"
DETAIL:  username and/or password does not match

失敗後は .pcppass ファイルを適切な権限で作成するか、パスワード入力を受け付けるオプションである -W オプションをつけて pcp コマンドを再実行する必要がありました。

pcp_node_info -p 9898 -W
Password:

4.7 からはエラーを出力して終了するのではなく、クライアントのコマンドプロンプトにフォールバックして引き続きパスワードを入力することができるようになりました。

また WARNING による警告が -d, –debug オプションなく出力される仕様に変更され、読み取りができなかった原因もメッセージから特定することができます。

WARNING: password file ~/.pcppass is not a plain file
WARNING: password file ~/.pcppass has group or world access; permissions should be u=rw (0600) or less

フロントエンド / バックエンドプロトコルバージョン 3.2 サポートの追加

PostgreSQL 18 ではプロトコルバージョン 3.2 に対応し、可変長のキャンセルキーが用いることができるようになりました。
この変更に合わせ、Pgpool-II でもプロトコルバージョン 3.2 を利用できるように改善がされました。

max_protocol_version や PGMAXPROTOCOLVERSION を用いた以下のようなコマンドで 3.2 プロトコルを使用して PostgreSQL のフロントエンドとバックエンドを接続することができます。
バージョンには 3.2 だけでなく PostgreSQL 18 のデフォルトのプロトコルバージョンである 3.0 を指定することもできます。

# max_protocol_version オプションで 3.0 バージョンで接続
psql "host=localhost dbname=test user=sraoss max_protocol_version=3.0 port=11000"

# 環境変数 PGMAXPROTOCOLVERSION に 3.2 を指定して接続
PGMAXPROTOCOLVERSION="3.2" psql -p 11000 test

新規接続時は指定したプロトコルバージョンで接続を確立しますが、コネクションプーリングのキャッシュがある場合は既存のキャッシュに保存されたのプロトコルバージョンを用いて接続を行うため確立済みの接続間でバージョンが異なることによるエラーの心配もありません。

PostgreSQL 18 の SQL パーサの導入

Pgpool-II ではメジャーリリースするたびに、PostgreSQL の最新パーサを移植しています。今回のリリースでは PostgreSQL 18 の新しいパーサを取り込みました。

Pgpool-II の負荷分散機能では、SQL を解析して参照か更新かを判別し、どのノードに振り分けるかを決めています。そのため、PostgreSQL の新バージョンでの SQL の変更に対応するには、SQL パーサを移植する必要があります。

PostgreSQL 18 での SQL のおもな変更点は以下のとおりです。

• 生成列を仮想列として使用可能に
• DML クエリの RETURNING にOLD/NEWのサポートを追加
• 各種制約の追加(例: WITHOUT OVERLAPS、ENFORCED/NOT ENFORCED)

Pgpool-II 4.7 では上記の変更点に対応しています。

logdir パラメータ名を work_dir へ変更

4.6 までは Pgpool-II の起動状態を記述する pgpool_status や memq_lock_file といった管理ファイルを logdir に指定するディレクトリに保存していました。
しかし logdir というパラメータ名はログ関連のファイルを格納するディレクトリの設定パラメータと誤解されやすい問題がありました。

4.7 からはパラメータ名が work_dir へ変更となりました。

logdir のパラメータ自体も引き続き利用することができ、logdir に指定した値が work_dir の設定値へと再設定され Pgpool-II の終了時に以下ワーニングが表示されます。

2026-01-08 11:50:48.193: main pid 18667: WARNING: logdir is changed to work_dir
2026-01-08 11:50:48.193: main pid 18667: DETAIL: if logdir is specified, the value will be set to work_dir

Slony モードの廃止

backend_clustering_mode で指定することができていた Slony モードが廃止されました。

データのレプリケーションを Slony-I が行うクラスタリングモードの一つでしたが、Slony-I は 3 年前からリリースが停止しています。
現在は Slony モードについて積極的に利用するユーザーが見られず、廃止のアナウンスに異議がなかったため 4.7 からは廃止となりました。

Pgpool-II の libpcp ライブラリの名称を libpgpoolpcp に変更

4.7.1 のマイナリリースにて Pgpool-II のライブラリである libpcp の名称を libpgpoolpcp に変更されました。
背景として、RHEL の libpcp ライブラリと Pgpool-II の libpcp ライブラリがコンフリクトする問題があったためです。

おわりに

今回は、Pgpool-II 4.7 の新機能について紹介しました。

Pgpool-II 4.7 では、より実用的で便利な機能が数多く追加・改善されています。PostgreSQL の高可用性構成や負荷分散の実現を検討されている方にとって、Pgpool-II は有力な選択肢です。ぜひこの機会に Pgpool-II の導入をご検討ください。

本記事では、性能向上やサーバリソースの効率的な活用に役立つコネクションプーリングの仕組みについて解説します。あわせて、運用時に押さえておくべき設定のポイントについても紹介します。

コネクションプーリングとは

データベースへの接続には、ネットワークのハンドシェイクや認証といった初期処理が伴います。そのため、リクエストのたびに接続してすぐに切断するような動作を繰り返すと、システム全体に大きなオーバーヘッドが発生してしまいます。

そこで効果を発揮するのが、コネクションプーリングという仕組みです。この機能では、一度確立したデータベース接続をキャッシュしておき、次回のリクエスト時に再利用することで、接続処理の無駄を省きます。これにより、システム全体のパフォーマンスが向上し、リソースを無駄なく効率的に活用できるようになります。

Pgpool‑II コネクションプーリングの仕組み

Pgpool-II は、ユーザ名・データベース名・プロトコルバージョンなどの接続プロパティが同一であるリクエストに対して、すでに確立された接続を再利用する仕組みを持っています。これにより、毎回の接続処理にかかるコストを削減し、全体の処理効率を高めることができます。

以下は、Pgpool-II コネクションプーリングの基本的な動作の流れです。

1. 起動時に、Pgpool-II の親プロセスは num_init_children で指定された数の子プロセスをあらかじめフォークします。各子プロセスは max_pool の設定値まで接続をキャッシュします。
2. Pgpool-II はクライアントからの接続要求を待ち受けます。
3. いずれかの Pgpool-II の子プロセスが、クライアントからの接続要求を受け取ります。
4. その子プロセスは、保持している接続内に、接続情報 (データベース/ユーザ) の一致するものがあるかどうかを探します。見つかったら再利用します。
5. 見つからなければ、子プロセスは新たに PostgreSQL サーバへ接続し、それをプールに登録します。
   プールに空きスロットがない場合は、最も古い接続を切断し、そのスロットを再利用します。
6. クライアントがセッション終了要求を送るまで、クエリ処理を行います。
7. クライアントが接続を終了します。Pgpool-II はクライアントへの接続をクローズしますが、PostgreSQL への接続を保持します。

主な設定パラメータ

以下は、コネクションプーリングに関連する設定項目です。

PostgreSQL では、接続ごとにプロセスが生成されますが、接続が切断されない限り、そのプロセスが使用するメモリは解放されません。Pgpool-II のコネクションプーリングを使用している場合、クライアントが切断しても PostgreSQL 側の接続は保持され続けるため、そのプロセスが使用するメモリも解放されません。

そのため、もし DB サーバのメモリ使用量が徐々に増加していく事象が発生している場合、Pgpool-II のコネクションプーリングが影響している可能性があります。このような事象やメモリリークのリスクを防ぐために、child_life_time を設定することが推奨されています。ただし、Pgpool-II の子プロセスがアイドル状態になる時間が child_life_time より短い場合、PostgreSQL への接続を終了する機会が得られません。そのため、child_max_connections も併せて設定しておくことで、一定回数の接続処理後に子プロセスを終了させ、より確実に接続とメモリを解放することができます。

設定上の注意点

Pgpool-II は、各 PostgreSQL サーバに対して以下の数の接続を確立する可能性があります。

num_init_children × max_pool

そのため、PostgreSQL 側の max_connections 設定と照らし合わせて、Pgpool-II の接続数を適切に設定する必要があります。

まず、PostgreSQL にはスーパーユーザ用の接続枠が superuser_reserved_connections によって確保されており、これは通常ユーザの接続には使用できません。したがって、Pgpool-II からの接続数は、この予約分を除いた枠内に収まるように調整する必要があります。

また、Pgpool-II はクエリキャンセルを行う際に、既存の接続とは別に新たな接続を PostgreSQL に確立するため、この追加分も接続数として考慮する必要があります。

さらに、Pgpool-II の Watchdog 機能を利用している場合、リーダー切り替えのタイミングで旧リーダーの接続が残ったまま、新しいリーダーが接続を開始するケースもあります。このような状況では一時的に接続数が増加し、PostgreSQL 側の制限を超えてしまうリスクがあります。

これらを踏まえると、Pgpool-II の接続数が PostgreSQL の接続数上限に収まるように、以下の条件を満たすように設計する必要があります。

• クエリキャンセルを考慮しない場合

max_pool × num_init_children × 2 ≤ max_connections − superuser_reserved_connections

• クエリキャンセルを考慮する場合

max_pool × num_init_children × 2 × 2 ≤ max_connections − superuser_reserved_connections

終わりに

今回は Pgpool-II のコネクションプーリング機能について紹介しました。この機能を活用することで、PostgreSQL の接続効率を高め、リソースの最適化が期待できます。Pgpool-II を導入する際は、ぜひコネクションプーリング機能の活用をご検討ください。

Pgpool-II 4.6 では、ロギングコレクター、クエリキャッシュの機能強化がされました。また、バックエンドからのメッセージのログ機能の搭載、PostgreSQL 17 への対応、Watchdog の IPv6 への対応も行われました。

Pgpool-II 4.6 の新機能及び変更点は Pgpool-II 公式ドキュメントの以下のページに記載されています。

Pgpool-II 4.6 リリースノート

本記事では、これらの新機能について詳しく紹介します。

ログのローテーションを指示する新しい PCP コマンド

Pgpool-II には、PostgreSQL のロギングコレクター(logging_collector) と同様のログ収集機能が備わっています。

ロギングコレクターを使ってログを収集する場合、これまではロギングコレクターにシグナルを送ることでしかログのローテーションを行えませんでしたが、pcp_log_rotate コマンドを使用することで Pgpool-II のログファイルを簡単にローテーションできるようになりました。

動作確認のための設定例は以下の通りです。

(pgpool.conf 設定例)
log_destination = 'stderr' 
logging_collector = on 
log_directory = '/var/log/pgpool_log' 
log_filename = 'pgpool-%Y-%m-%d_%H%M%S.log'

log_directory で指定したディレクトリを確認すると、現時点でのログが出力されていることが確認できます。

[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 4
-rw-------. 1 postgres postgres 193 6月 9 16:21 pgpool-2025-06-09_162145.log

その後、 pcp_log_rotate を実行することで新しいログファイルへとローテートされていることが確認できます。

[root@server1 ~]# pcp_log_rotate -h 192.168.100.50  -p 9898 -U pgpool -W
Password:
pcp_log_rotate -- Command Successful

[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 8
-rw-------. 1 postgres postgres 284 6月 9 16:21 pgpool-2025-06-09_162145.log
-rw-------. 1 postgres postgres 193 6月 9 16:21 pgpool-2025-06-09_162159.log

また -s scope オプションによってコマンドの与える影響範囲を指定することができます。サポートされているコマンドスコープは以下です。(デフォルトは local)

• c, cluster : クラスタを構成するすべての Pgpool-II のログファイルをローテーションします。
• l, local : ローカル Pgpool-II のログファイルをローテーションします。

リロードによる logging_collector 関連のパラメータの変更

logging_collector 関連の以下の設定パラメータの変更が、Pgpool-II のリロードで反映されるようになりました。これにより logging_collector の設定の反映のために Pgpool-II の再起動の必要がなくなりました。

• log_truncate_on_rotation
• log_directory
• log_filename
• log_rotation_age
• log_rotation_size
• log_file_mode

リロードで設定が反映されるかの動作確認として log_filename の値を変更したうえで pcp_log_rotate コマンドを実行してログファイルの名前が変更されて出力されるかを確認します。

まず、pgpool.conf を以下の設定に変更し、 Pgpool-II をリロードします。

[root@server1 ~]# vi /etc/pgpool-II/pgpool.conf
#log_filename = 'pgpool-%Y-%m-%d_%H%M%S.log'
log_filename = 'pgpool-%a.log'

[root@server1 ~]# systemctl reload pgpool.service

その後 pcp_rotate_log コマンドを実行すると出力されるログファイルの名前が変更されていることが確認できます。

[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 8
-rw-------. 1 postgres postgres 284  6月 12 09:51 pgpool-2025-06-12_095140.log
-rw-------. 1 postgres postgres 193  6月 12 09:51 pgpool-2025-06-12_095142.log

[root@server1 ~]# pcp_log_rotate -U pgpool -W -h 192.168.100.50
Password:
pcp_log_rotate -- Command Successful
[root@server1 ~]# ls -l /var/log/pgpool_log/
合計 12
-rw-------. 1 postgres postgres 284  6月 12 09:51 pgpool-2025-06-12_095140.log
-rw-------. 1 postgres postgres 411  6月 12 09:52 pgpool-2025-06-12_095142.log
-rw-------. 1 postgres postgres 361  6月 12 09:52 pgpool-Thu.log

クエリキャッシュの強制的な作成

クエリキャッシュは SELECT クエリの実行結果を共有メモリに保存し、同じクエリ(パラメータ、データベース、ユーザ含む)が実行されたら、結果を再利用する機能です。PostgreSQL にアクセスせず、ディスクアクセスもないので極めて高速に問い合わせ結果を返すことができます。

Pgpool-II では、クエリキャッシュは通常自動的に作成されますが、安全性の観点から、immutable でない関数を含むクエリ (たとえば SELECT now();) はキャッシュされない仕様になっています。

以下の実行例では、クエリを実行するたびに結果が変化していることがわかります。

postgres=> SELECT now();
now
-------------------------------
2025-06-12 17:10:27.241885+09
(1 行)

postgres=> SELECT now();
now
-------------------------------
2025-06-12 17:10:29.156295+09
(1 行)

また、ログからも毎回 PostgreSQL にアクセスしていることが確認できます。

2025-06-12 17:10:27.241: psql pid 2628: LOG: DB node id: 1 backend pid: 2644 statement: SELECT now();
2025-06-12 17:10:29.155: psql pid 2628: LOG: DB node id: 1 backend pid: 2644 statement: SELECT now();

それでも、内容を理解したうえでキャッシュを行いたいユースケースが存在することから、今回のリリースではクエリキャッシュを強制的に作成する機能が追加されました。クエリの先頭に /*FORCE QUERY CACHE*/ を付けて実行することで、クエリキャッシュを強制的に作成できるようになります。

以下のようにクエリを実行することで、キャッシュされた時点のタイムスタンプが返されていることが確認できます。このキャッシュは Pgpool-II を再起動するまで保持されます。

postgres=> /*FORCE QUERY CACHE*/SELECT now();
now
------------------------------
2025-06-12 17:14:47.297804+09
(1 行)

postgres=> /*FORCE QUERY CACHE*/SELECT now();
now
------------------------------
2025-06-12 17:14:47.297804+09
(1 行)

さらに、ログにもキャッシュが利用されていることが記録されています。

2025-06-12 17:14:47.297: psql pid 2621: LOG: DB node id: 0 backend pid: 2901 statement: /*FORCE QUERY CACHE*/SELECT now(); 
2025-06-12 17:14:50.138: psql pid 2621: LOG: fetch from memory cache 
2025-06-12 17:14:50.138: psql pid 2621: DETAIL: query result fetched from cache. statement: /*FORCE QUERY CACHE*/SELECT now();

また /*NO QUERY CACHE*/ を冒頭に付記して宣言しても、 宣言したクエリキャッシュを削除することは出来ません。 /*NO QUERY CACHE*/ はキャッシュエントリが作成されないようにするだけなためです。

Pgpool-II を再起動することなく作成したクエリを削除する場合は、後述する PGPOOL SET CACHE DELETE コマンドか、pcp_invalidate_query_cache コマンドを使用する必要があります。

新しい PGPOOL SET CACHE DELETE コマンド

登録されているクエリキャッシュを削除する PGPOOL SET CACHE DELETE コマンドが追加されました。引数としてクエリの文字列を渡すことによってクエリキャッシュを指定して削除することができます。

postgres=> /*FORCE QUERY CACHE*/SELECT now();
              now
-------------------------------
 2025-06-12 09:58:49.983346+09
(1 行)

postgres=> PGPOOL SET CACHE DELETE '/*FORCE QUERY CACHE*/SELECT now();';
NOTICE:  query cache deleted. query: "/*FORCE QUERY CACHE*/SELECT now();"
SET
postgres=> /*FORCE QUERY CACHE*/SELECT now();
              now
-------------------------------
 2025-06-12 09:59:32.998492+09
(1 行)

引数に記述するクエリキャッシュはクエリ文字列は、末尾の「;」も含めて以前のクエリと完全に一致していなければならず、一致しない場合は以下エラーとなります。

postgres=> PGPOOL SET CACHE DELETE '/*FORCE QUERY CACHE*/SELECT now()'; -- 末尾の ';' が不足
NOTICE: query cache does not exist for query: "/*FORCE QUERY CACHE*/SELECT now()" -- クエリキャッシュが存在しないエラーとなる
SET

クエリキャッシュを削除する新しい PCP コマンド

すべてのクエリキャッシュを削除する PCP コマンド、pcp_invalidate_query_cache が追加されました。

今までは、クエリキャッシュの削除は Pgpool-II の再起動が必要でしたが、このコマンドを実行することによって Pgpool-II を再起動することなくクエリキャッシュを削除することができます。

「/*FORCE QUERY CACHE*/」で 「SELECT now();」 クエリをキャッシュします。

postgres=> /*FORCE QUERY CACHE*/SELECT now();
now
-------------------------------
2025-06-09 13:50:37.066191+09
(1 行)

その後、 pcp_invalidate_query_cache を実行すると、クエリキャッシュを削除することができます。

[postgres@server1 ~]$ pcp_invalidate_query_cache -h 192.168.100.50 -p 9898 -U pgpool -W
Password:
pcp_invalidate_query_cache -- Command Successful

postgres=> /*FORCE QUERY CACHE*/SELECT now(); -- クエリキャッシュが削除されているため再作成となる
now
-------------------------------
2025-06-09 13:50:56.561619+09
(1 行)

新しい設定パラメータ log_backend_messages

バックエンドからのメッセージログを出力する log_backend_messages パラメータが追加されました。terse または verbose に設定されている場合、バックエンドからのメッセージをログ出力します。

以下が受け取るメッセージ例です。

2025-06-09 14:00:57.494: psql pid 7579: LOG: last ParameterStatus message from backend 0 repeated 13 times

terse では、同じ種類のメッセージが同じバックエンドから送られてくると、その回数を記録し、次に異なる種類のメッセージが送られてきた時に繰り返し回数を報告します。そのため、繰り返している最中にセッションに対応するプロセスが強制終了すると、その分のログが出力されません。この場合でもすべてのログを出力するには、 verbose オプションを使用します。

verbose に設定したときのログ出力例は以下です。同一内容のメッセージであっても送られてくるたびに出力するためプロセスの強制終了によるログの損失は避けられますが、大量のメッセージがバックエンドから送られてくる場合は注意が必要です。

2025-06-09 13:58:16.390: child pid 7263: LOG: ParameterStatus message from backend 0
2025-06-09 13:58:16.390: child pid 7263: LOG: ParameterStatus message from backend 0
2025-06-09 13:58:16.390: child pid 7263: LOG: ParameterStatus message from backend 0

PostgreSQL 17 の SQL パーサの導入

Pgpool-II ではメジャーリリースするたびに、PostgreSQL の最新パーサを移植しています。今回のリリースでは PostgreSQL 17 の新しいパーサを取り込みました。

Pgpool-II の負荷分散機能では、SQL を解析して参照か更新かを判別し、どのノードに振り分けるかを決めています。そのため、PostgreSQL の新バージョンでの SQL の変更に対応するには、SQL パーサを移植する必要があります。

PostgreSQL 17 での SQL のおもな変更点は以下のとおりです。

• MERGE への NOT MATCHED BY SOURCE と RETURNING 句の追加
• COPY オプションの ON_ERROR ignore と LOG_VERBOSITY の追加
• COPY FROM オプションの FORCE_NOT_NULLとFORCE_NULL で「*」 を使用した全列を指定できる機能の追加
• EXPLAIN への SERIALIZE と MEMORY オプションの追加
• ALTER TABLE で SET STATISTICS DEFAULT を用いて、デフォルトの統計上情報ターゲットとする列の指定できる機能の追加
• ALTER TABLE での列の生成式を変更する機能の追加
• ALTER TABLE で .. SET ACCESS METHOD のデフォルトを指定できる機能の追加
• イベントトリガでログインイベントと REINDEX  を扱う機能の追加

Pgpool-II 4.6 では上記の変更点に対応しています。

Watchdog の hostname と heartbeat_hostname パラメータの IPv6 対応

これまで、IPv6 に対応していたパラメータは以下の通りです。

• backend_hostnameX
• listen_addresses
• pcp_listen_addresses

一方で、以下の Watchdog 関連パラメータはこれまで IPv6 に対応していませんでした。

• hostname
• heartbeat_hostname

今回のリリースにより、hostname と heartbeat_hostname も IPv6 に対応し、すべてのネットワーク関連パラメータで IPv6 アドレスを利用できるようになりました。

おわりに

今回は、Pgpool-II 4.6 の新機能について紹介しました。

Pgpool-II 4.6 では、より実用的で便利な機能が数多く追加・改善されています。PostgreSQL の高可用性構成や負荷分散の実現を検討されている方にとって、Pgpool-II は有力な選択肢です。ぜひこの機会に Pgpool-II の導入をご検討ください。

Watchdogとは

具体的にPgpool-II 4.1のwatchdogの機能強化について説明する前に、watchdogとは何かについておさらいしておきましょう。Watchdogは、Pgpool-IIのオプション機能の一つで、Pgpool-II自体の可用性を高めるものです。Pgpool-IIでは、以下の図のようにすべてのクライアントからのアクセスがPgpool-IIを経由してPostgreSQLに送られるので、もしもPgpool-IIがダウンしてしまうと、データベースがまったく使えなくなってしまいます。

そこでPgpool-IIを複数台用意し、万が一Pgpool-IIがダウンしてしまった時にもう1台のPgpool-IIに切り替えて処理を続行するのがwatchdogの役割です。

Pgpool-IIが切り替わっても、クライアントは引き続き同じVIP (Virtual IP)でPgpool-IIに接続することにより、Pgpool-IIが切り替わったことを意識せずにデータベースシステム全体の利用を継続することができます。この図ではPgpool-IIは2つですが、実際にはいくつでもPgpool-IIをもっと設置することも可能で、Pgpool-IIは3台以上の奇数台数を設置することが推奨されています。この理由については後で説明します。

なお、wathdog機能は実際にはPgpool-IIから起動される別プロセスで実装されていますが、概念的にはPgpool-II = watchdogと考えて差し支えありません。そこで、以下の説明ではPgpool-IIの代わりにwatchdogという用語を用います。

Watchdogの改善点その1 – マスタwatchdogノードの自動辞退

上の図で、VIPを持つwatchdogとVIPを持たないwatchdogの2つが出てきました。VIPを持つwatchdogは「マスタwatchodg」と呼ばれ、watchdogがいくつあっても、クラスタ内には1台のみ存在するのが原則です。マスタwatchdogはクラスタシステム起動時にパラメータ「wd_priority」パラメータが大きいwatchdogがその役割を担います。マスタ以外のwatchdogは「スタンバイ」と呼ばれます。

さて、昨今ではPostgreSQLはストリーミングレプリケーションで構成するのが一般的です。これにより、可用性や参照負荷分散などのメリットをユーザは享受できます。以下はPgpool-IIコミュニティによって推奨される本格的なクラスタシステムで、Pgpool-IIが3台、PostgreSQLが2台で構成されています。

（具体的なセットアップ方法はマニュアルに詳しく記載されています）

この図の中で点線が各Pgpool-IIからPostgreSQLに出ていますが、これは「ヘルスチェック」という、Pgpool-IIがPostgreSQLデータベースの健全性をチェックする機能を表しています。これにより、たとえばプライマリPostgreSQLがダウンしても、スタンバイPostgreSQLを自動昇格させてデータベースシステムとしての運用を継続することができます。

Pgpool-II同士で意見が合わない？

PostgreSQLの健全性の確認は、ネットワークを通じてPgpool-IIがPostgreSQLに接続することにより行われます。ネットワークが正常ならば、どのPgpool-IIから見てもPostgreSQLが正常かどうかの見解は変わらないはずです。しかし、今マスタPgpool-IIとプライマリPostgreSQLの間のネットワークだけに故障が発生したらどうでしょう？この場合、マスタPgpool-IIはプライマリPostgreSQLを故障と判断、スタンバイPgpool-IIは健全と判断し、意見が別れてしまいます。そこでwatchdogはお互いに意見を交換して多数決で判断を下し、マスタPgpool-IIの「故障」判断は却下されます。（Pgpool-IIが偶数だと多数決が下せないので、困ったことになります。これが奇数台のPgpool-IIを設置することが推奨される理由です)

判断が却下されたプライマリPgpool-IIはプライマリPostgreSQLを「隔離(quarantine)」状態にします。隔離状態にあるPostgreSQLにはPgpool-IIは問い合わせを送信せず、スタンバイPostgreSQLに問い合わせを送ることになります。しかし相変わらずVIPはそのマスタPgpool-IIにアサインされており、クライアントからの更新問い合わせもスタンバイに送られます。スタンバイのPostgreSQLでは更新処理が実行できないので、そうした問い合わせはすべてエラーになってしまします。

watchdogマスタが自主降格して問題を回避

そこでPgpool-II 4.1では、こうした場合にマスタwatchdogは自主的に自分を降格して他のPgpool-IIにマスタの役割を移譲するようになりました。もちろんVIPも新しいPgpool-IIにアサインされるので、引き続き更新処理も正常に実行することができます。

多数決原則はPgpool-IIダウン時にも適用

ちなみに、Pgpool-IIが多数決でものごとを決める仕組みは、Pgpool-II自体のダウン時にも適用されます。Pgpool-IIはお互いに通信しながら互いの生死を確認しており、たとえば以下の図のように、Pgpool-IIの1,2はお互いに通信できるが、3は他のPgpool-IIと通信できない状態になっても、Pgpool-II 3は過半数の投票を得られないため、勝手にPgpool-II 3がマスタに昇格してしまうことを防ぐことができます。これはいわゆる「スプリットブレイン」状態の防止につながります。

Watchdogの改善点その2 – 新しいパラメータenable_consensus_with_half_votes

前述のように、Pgpool-IIでは多数決でものごとを決められるように、設置台数を奇数台にすることが推奨されています。しかし世の中にはリソースを節約するために2台でシステムを更正している例も多く、従来はPgpool-II台数が偶数の場合にはその半分、すなわち1台だけの賛成が得られても多数決の合意が得られるとしていました。しかしこれでは、たとえば台数が4台の時に2台の賛成で合意が得られることになり、おかしなことになります。そこでPgpool-II 4.1では、デフォルトで過半数の合意を得るためにPgpool-II台数の過半数の賛成が必要となりました。しかしPgpool-II台数が2台のときには、これだとPgpool-IIが1台ダウンした時に決して過半数が得られなくなってしまうため、救済のために新しいパラメータenable_consensus_with_half_votesが追加されました。このパラメータがonなら、Pgpool-II台数が2台のときには、1台のPgpool-IIの賛成のみで合意が得られます。ただし、Pgpool-IIが2台構成の時は、お互いの監視ネットワークがダウンした時にお互いに自分だけが生きていると思い込むスプリットブレイン状態になることを防ぐことができない点は変わりません。

終わりに

9回に渡ってPgpool-II 4.1の新機能をご紹介しました。Pgpool-IIはバージョンごとに機能が充実しており、適用できる案件が増えてきていると思います。今回のリリースでは、すぐに利用できるインストール方法とともに、各種雛形設定ファイルも配布物に同梱されています。この機会にPgpool-IIを使ったPostgreSQLクラスタシステムの構築にチャレンジしてみてはいかがでしょう。

Pgpool-II 4.1の紹介【第1回】
Pgpool-II 4.1 新機能: ステートメントレベルの負荷分散【第2回】
Pgpool-II 4.1 新機能: reserved_connections【第3回】
Pgpool-II 4.1 新機能:自動フェイルバック 【第4回】
Pgpool-II 4.1 新機能:PostgreSQL 12への対応【第5回】
Pgpool-II 4.1 新機能:2拠点に分かれたレプリケーション構成への対応【第6回】
Pgpool-II 4.1 新機能: シェアードリレーションキャッシュ【第7回】
Pgpool-II 4.1 新機能: Pgpool-II によって発行される内部クエリの改善【第8回】
Pgpool-II 4.1 新機能: Watchdogの機能強化【第9回】

バージョン情報を活用した内部クエリの削減

Pgpool-IIは、クライアントから受信した問い合わせを解析するために必要な様々な情報を入手するためにPostgreSQLに内部的にクエリを発行します。第7回で解説したシェアードリレーションキャッシュは、そうしたクエリ結果のキャッシュの利用を改善するものでした。Pgpool-II 4.1では、それとは別に発行する内部クエリそのものを削減する努力をしています。その一つが、PostgreSQLのバージョン情報を活用した内部クエリの削減です。

バージョンで異なるPostgreSQLのシステムカタログへの問い合わせ

Pgpool-IIが発行する内部クエリは、主にPostgreSQLのシステムカタログを問い合わせるものです。たとえば、Pgpool-IIではあるテーブルが一時テーブルかどうか各テーブルごとに問い合わせを行います。一時テーブルを含む問い合わせはストリーミングレプリケーションのスタンバイサーバには送信できないからです。あるテーブルが一時テーブルかどうかの判断方法はPostgreSQLのバージョンで異なり、実は結構厄介です。

• PostgreSQL 8.4と9.0では、システムカタログpg_classの”relistemp”列がtrueなら一時テーブル
• それ以外のバージョンではスキーマが”pg_temp”なら一時テーブル

という具合です。従来は、

1. pg_classにrelistempという列があるかどうか調べる
2. もしなければシステムカタログpg_namespaceを調べてスキーマがpg_tempであるかどうか調べる
3. もしrelistempがあればそれがtrueなのかfalseなのか調べる

という具合に最大2回の内部クエリ発行が必要でした。

バージョン情報を活用して内部クエリを削減

Pgpool-II 4.1では、あらかじめPostgreSQLのバージョンを調べておき、それによってpg_classのrelistempを調べるか、pg_namespaceを調べるかを判断できるので、内部クエリの発行回数を1回にすることができます。

他の内部クエリでも同様の工夫を行うことにより、従来一つのユーザからの問い合わせにつき最大内部クエリが7回ほど発行されていたのが2-3回に減らすことができました。

より効率的な一時テーブルのチェック

上の改良により、一時テーブルのチェックはかなり効率的になりましたが、それでも一時テーブルかどうか知るための内部クエリを完全になくすことはできません。そこで導入されたのがcheck_temp_tableというパラメータです。このパラメータを"trace"に設定すると、システムカタログに内部クエリを発行せずに、CREATE TEMP TABLE文がこのセッションで投入されたかどうかを追跡することによって一時テーブルかどうかの判定を行います。これにより内部クエリの発行が不要になりますが、注意することもあります。

一時テーブルの生成がPgpool-IIから見えない場合（たとえば関数やトリガの中で行われる場合）、Pgpool-IIは一時テーブルの生成を認識できません。この場合は、check_temp_tableに”catalog”を設定することにより、従来と同じシステムカタログを検索する動作になります。

終わりに

今回はPgpool-IIが発行する内部クエリの改善について解説しました。Pgpool-IIの発行する内部クエリの多さが気になる方はPgpool-II 4.1を試してみてはいかがでしょう。

リレーションキャッシュ

Pgpool-IIではクライアントから送られてきたクエリを解析し、クエリに含まれているテーブルや関数に関する情報をバックエンドのPostgreSQL上のシステムカタログから取得しています。
これらの取得した情報により柔軟なクエリレベルの負荷分散などの様々な機能が実現しています。
クエリが実行されるたびにシステムカタログを参照しに行くと無視できないオーバヘッドとなるため、各子プロセスでは1度取得した情報はローカルメモリにキャッシュしておきます。これをリレーションキャッシュと呼びます。
ローカルメモリに既に該当のシステムカタログ情報がキャッシュされている場合、それを直接使用することでこのオーバヘッドを軽減しています。

シェアードリレーションキャッシュ

Pgpool-IIの起動直後やPostgreSQLのフェイルオーバ処理後、その他各種設定により子プロセスが再起動した直後では子プロセスはローカルキャッシュを持っていません。そのため num_init_children が大きな値に設定されるような接続数が多いシステムの場合、子プロセスの数だけシステムカタログへの問い合わせが同時に発生し、このオーバヘッドが重なり大きくなる場合があります。

このような場合を想定して、Pgpool-II 4.1ではリレーションキャッシュをローカルキャッシュに加えて共有メモリにもキャッシュできる機能が追加されました。この機能は、デフォルトで有効(enable_shared_relcache=on)となります。
リレーションキャッシュはローカルキャッシュに加え、 memqcache_method(デフォルトは’shmem’) で指定されているキャッシュストレージに保存されます。
各子プロセスは、自身のローカルキャッシュにシステムカタログの情報が無ければ、キャッシュストレージを確認し、どちらにもなかった場合のみ、PostgreSQLのシステムカタログを参照します。その後、システムカタログから取得した情報は、自身のローカルキャッシュとキャッシュストレージの双方にキャッシュします。
つまり、いずれかの子プロセスが参照したシステムカタログはすべての子プロセスで共有されるため、上記のようなケースでも同じシステムカタログを参照する処理は1度で済むため、オーバヘッドをかなり抑えることができます。

ベンチマークによるシェアードリレーションキャッシュ機能の効果

PostgreSQL12とPgpool-II 4.1を用いた簡易なベンチマークテストを行いました。以下のグラフは、 enable_shared_relation_cache=off の場合と比較して enable_shared_relation_cache=on の場合に実行速度が相対的にどの程度向上しているかを表しています。この結果より、シェアードリレーションキャッシュ機能により2倍程度実行速度が向上していることが確認できました。

(テストコマンド)
pgbench  -C -T 30 -c 30 -n -f script_file

まとめ

今回は、Pgpool-II 4.1で追加されたシェアードリレーションキャッシュ機能について紹介しました。
この機能によりPgpool-II自体のオーバヘッドを軽減し、より快適に使用することができます。
特に num_init_children の設定値が大きい場合や、接続先のテーブル数が多い大規模な環境で効果が見込めるため、このような環境の場合Pgpool-II 4.1の使用を検討していただくと良いかと思います。

本店・支店が遠隔地にある場合のレプリケーション

ある程度の規模の企業では、本店が東京、支店が大阪といったように、拠点が複数あり、しかもそれぞれが離れていることがよくあります。
ときには本店が東京、支店がニューヨークというように、国をまたいで拠点が存在することも珍しくありません。
今、ある企業で本店にPostgreSQLのストリーミングレプリケーションのプライマリサーバを置き、データベースの更新と本店社員の情報検索をそこで行い、一方支店の方にはスタンバイサーバを置いて、主に支店の社員が情報検索を行うものとします。たまにデータベースの更新を行うこともありますが、頻度は高くなく、その場合は本店のプライマリサーバに更新をかけるとします。

このような構成を取ることにより、それぞれの拠点の情報検索業務はネットワーク的に近いサーバを利用できるため、レスポンスが高速になりますし、万が一本店のサーバがダウンしても支店のサーバを昇格させることによって業務が継続できます。

Pgpool-IIによるサーバ問い合わせ自動振り分け

こうした構成では社員はそれぞれ本店のサーバにアクセスするのか支店のサーバにアクセスするのかを意識する必要があります。更にデータベースへのアクセスは通常アプリケーションを通じて行いますので、そのアプリケーションを変更しない限り、データベースのアクセス先を適切に設定することができません。しかしPgpool-IIを使えば設定によってPgpool-IIが自動的に振り分けをしてくれるので、社員はアクセス先のデータベースを意識する必要がなくなります。以下の構成では、本店、支店の社員はそれぞれ本店、支店に設置されたPgpool-IIに常にアクセスします。支店において更新クエリを本店のプライマリサーバに送出するのはPgpool-IIが行います。

リレーションキャッシュ問題

しかし従来のPgpool-IIでは、この構成はうまく動きません。なぜなら、Pgpool-IIはクエリを解析する際にクエリに含まれるテーブルなどに関する情報をプライマリサーバから取得するからです。これをリレーションキャッシュと呼びます。キャッシュなので2度目以降は高速にアクセスされますが、支店から見て本店がネットワーク的に遠い場合、1度目は遅くなる可能性があります。（下の図における赤点線）

relcache_query_target

そこで導入されたのが新しいパラメータrelcache_query_targetです。このパラメータは、リレーションキャッシュの取得先を指定します。デフォルトの値はmasterで従来と同じくプライマリサーバにアクセスします。スタンバイサーバ側のPgpool-IIの設定でこの値をload_balance_nodeとすると、負荷分散用のサーバにアクセスするようになります。更にこのときプライマリサーバの負荷分散の重みを0にしておけば、常にリレーションキャッシュの問い合わせは支店側のスタンバイサーバに送られるようになります。（下図参照）これで支店の社員も快適にPostgreSQLデータベースにアクセスできるようになります。

レプリケーションの遅延に注意

ただし、relcache_query_targetをload_balanace_modeにした場合、注意すべきこともあります。たとえば新しいテーブルを作成した直後にそのテーブルに問い合わせを発行し、Pgpool-IIがスタンバイサーバ側のシステムカタログを検索した時に、レプリケーションの遅延によってスタンバイサーバ側のシステムカタログにそのテーブルの情報が到達していないと、その検索が失敗してしまいます。これを防ぐために同期レプリケーションを利用することもできますが、プライマリサーバ側の更新が遅くなります。ですからこの構成は、テーブルの作成が頻繁に行われるようなシステムでは採用が難しいかもしれません。

まとめ

今回はPgpool-II 4.1の新機能として、2拠点に分かれたレプリケーション構成への対応を可能にする新しい設定パラメータrelcache_query_targetをご紹介しました。クラウドが活用される時代においては、物理的に店舗が遠隔地に分かれていなくても、クラウドサービスのリージョンを2つ用意して万が一に備えることも珍しくなくなってきました。こうした構成においてもPgpool-IIが活用しやすくなったのではないかと思います。

PostgreSQL 12 への対応として、おもに最新の SQL パーサの移植とフェイルオーバやリカバリで使うサンプルスクリプトの修正が行われました。

PostgreSQL 12 SQL パーサの移植

Pgpool-II の負荷分散機能では、SQL を解析して参照か更新かを判別し、どのノードに振り分けるかを決めています。そのため、PostgreSQL の新バージョンでの SQL の変更に対応するには、SQL パーサを移植する必要があります。

PostgreSQL 12 での SQL のおもな変更点は以下のとおりです。

• VACUUM コマンドの SKIP_LOCKED、INDEX_CLEANUP、TRUNCATE オプション
• COMMIT AND CHAIN と ROLLBACK AND CHAIN コマンド
• COPY FROM コマンドの WHERE 句
• CREATE OR REPLACE AGGREGATE コマンド
• CREATE STATISTICS コマンドの mcv 種別
• REINDEX コマンドの CONCURRENTLY オプション
• EXPLAIN コマンドの SETTINGS オプション

Pgpool-II 4.1 では上記の変更点に対応しています。

サンプルスクリプトの修正

PostgreSQL 12 では、ストリーミングレプリケーションでスタンバイとして起動する場合の設定ファイル recovery.conf が廃止されました。パラメータは設定ファイル postgresql.conf で設定するように統合されました。また、スタンバイとして起動するかは recovery.signal ファイルを配置して指定するようになりました。

それに伴って、フェイルオーバやリカバリで使うサンプルスクリプトが修正され、PostgreSQL 12 でも動作するようになりました。サンプルスクリプトは Pgpool-II 4.1 文書 の「8.3. Pgpool-II + Watchdog の構築の例」に掲載されています。

また、今回のリリースからサンプルスクリプトが配布物に同梱されるようになりました。RPM パッケージを使ってインストールした場合には、/etc/pgpool-II ディレクトリに配置されます。

$ ll /etc/pgpool-II/*.sample
-rwxr-xr-x 1 postgres postgres 2756 11月 19 09:06 /etc/pgpool-II/failover.sh.sample
-rwxr-xr-x 1 postgres postgres 6575 11月 19 09:06 /etc/pgpool-II/follow_master.sh.sample
-rwxr-xr-x 1 postgres postgres 1080 11月 19 09:06 /etc/pgpool-II/pgpool_remote_start.sample
-rwxr-xr-x 1 postgres postgres 2830 11月 19 09:06 /etc/pgpool-II/recovery_1st_stage.sample
-rwxr-xr-x 1 postgres postgres 712 11月 19 09:06 /etc/pgpool-II/recovery_2nd_stage.sample

サンプルスクリプトを使う場合には、ファイル名から .sample を外して適当な場所にコピーし、変数 PGHOME を PostgreSQL のインストール先に合わせて変更してください。

また、pgpool_setup が生成するスクリプトも PostgreSQL 12 に対応しています。

まとめ

今回、PostgreSQL 12 への対応として SQL パーサの移植とサンプルスクリプトの修正について説明しました。今回からサンプルスクリプトが同梱されるようになったことで、これまでスクリプトの作成に悩んでいた方も導入しやすくなったと思います。これを機に Pgpool-II の導入をぜひお試しください。

Pgpool-II 4.1 の概要ついては、第1回記事を参照ください。

自動フェイルバック

Pgpool-IIでは、ヘルスチェック機能やPostgreSQLからのデータの読み出し/書き込みの失敗を契機にクラスタ配下のPostgreSQLを自動でフェイルオーバします。これにより故障したノードを管理下から切り離しサービスを継続させることができます。ただし、一度切り離されたPosrtgreSQLをPgpool-IIの管理下に復帰させるためには、管理者が復旧を確認し手動でアタッチする必要がありました。これは、一度障害が発生したと判断され切り離されたPostgreSQLの正常性をPgpool-II側から自動で判断することが困難なためでした。
Pgpool-II 4.1からは、一度切り離されてしまったスタンバイに対してPostgreSQLの正常性が確認できた際に自動で復帰させることができるようになりました。これにより、ネットワーク障害などによりスタンバイノードが切り離された場合においても、障害が復旧後にPgpool-IIが自動でスタンバイノードをフェイルバックするため、管理者の負担を軽減することが期待できます。

使用方法

自動フェイルバック機能では、新たに追加された以下のパラメータを使用します。

auto_failback

自動フェイルバック機能を有効化するためのパラメータです。デフォルトは、offです。

auto_failback_interval

自動フェイルバック機能の最短の実行間隔(秒単位)を指定できます。デフォルトは、60(秒)です。

また、ヘルスチェックとストリーミングレプリケーションのチェックの機能と連携しているため、これらの機能も有効である必要があります。

注意点

ネットワークが不安定な環境で、自動フェイルバックを有効にした場合、自動フェイルオーバと自動フェイルバックを繰り返してしまい、サービスの性能に影響が出る可能性が考えられます。
このような環境では、auto_failback_intervalの間隔を長めに設定することで防ぐことができます。

システムのメンテナンスなどにより意図的にPostgreSQLの再起動や切り離しを行う場合注意が必要です。自動フェイルバック機能が有効な場合、意図せずメンテナンス中のPostgreSQLが復帰してしまう可能性があります。そのため、メンテナンス作業などを行う際には、一時的にauto_failbackをoffにしPgpool-IIのreloadで設定を反映させてから実施することをお勧めします。

まとめ

今回は、Pgpool-II 4.1で追加された自動フェイルバック機能について紹介しました。
この機能により、サーバ管理者の負担が軽減しPostgreSQLのクラスタ環境の運用がより容易になるかと思います。

Pgpool-IIにおけるクライアントからの接続管理

reserved_connections機能を説明する前に、今までのクライアントからの接続管理について復習しておきましょう。reserved_connectionsは、今までの管理方法とは違う管理方法を導入するので、比較のためにもおさらいしておくのがわかりやすいと思います。Pgpool-IIでは、複数のサーバプロセスがクライアントからの接続を待ち受けており、クライアントからの接続要求があると、そのうちの一つのプロセスが接続要求を受け付けます。待受プロセスの数はnum_init_childrenという設定パラメータで決まります。

では、すでにnum_init_children分のプロセスがすべてクライアントからの接続を受付中で、待受プロセスが無い場合はどうなるのでしょう？
そのときはOSが新しいクライアントからの接続要求を一旦保留してキューに入れます。どれかのPgpool-IIプロセスへのクライアントからの接続が終了すると、そのプロセスは再びクライアントからの接続要求を待ち受ける状態になるので、OSはそのプロセスに接続要求を割り当てます。
つまり、クライアントから見ると、空きプロセスが出るまで接続要求は待たされることになります。

PostgreSQLが順調に処理を行っていればこの方式は問題なく動きます。しかし、PostgreSQLの処理能力が追いつかない状態になったり、あるクライアントがPgpool-IIに接続したまま長い時間何もせずに接続を専有したりすると、OSのキューが満杯になり、いつまでたっても新しいクライアントがPgpool-IIに接続できなくなります。それどころか、システムに重い負荷がかかり、システム全体の状態が不安定になることもあります。

reserved_connectionsによる接続管理の改善

この問題を解決するのがPgpool-II 4.1で導入された新しい設定パラメータreserved_connectionsです。このパラメータが1以上に設定されていると、(num_init_children – reserved_connections)以上のクライアントからの接続はブロックされるのではなく受け付けられず、”Sorry, too many clients already”というエラーになります。 たとえば、reserved_connections = 1で、num_init_children = 32なら、32番目のクライアントからの接続は拒否されます。これにより、PostgreSQLが忙しい場合でもOSにこれ以上負担がかからずに済みます。そのかわり、クライアントは接続に失敗したらしばらくたってから再度接続を試みるなどの対応が必要になります。
この挙動はPostgreSQLと同じで、PostgreSQLのmax_connectionsを越えた接続をしようとして”Sorry, too many clients already”のエラーが出てしまった経験をお持ちの方も多いと思います。ですから、reserved_connectionsを導入することによるこうした挙動の変化は、PostgreSQLユーザであればあまり違和感のないところでしょう。
逆に、システムの処理能力に十分余裕があり、クライアントが待ち状態になることがほとんどないようなシステムでは、今までどおりの挙動を維持するために、reserved_connectionsを0に設定するのがおすすめです。（ちなみにreserved_connections = 0がデフォルト設定です）
なお、reserved_connectionsを有効にしたい場合、できればその設定値を1ではなく、もう少し余裕を持たせると良いでしょう。具体的には、num_init_childrenの10%位をreserved_connectionsに割り当てます。Pgpool-IIのプロセスはクライアントの接続が解放されてから待ち受け状態に戻るまでに少し時間がかかることがあり、その分の余裕を見たいからです。

まとめ

今回、Pgpool-II 4.1の新しいパラメータreserved_connectionsについて説明しました。
reserved_connectionsを導入することにより、常に高負荷に悩まされているシステムでは改善が見込めることがあるので、是非お試しください。