PostgreSQL 19 の主な強化点は以下の通りです。これらについてレポートで取り扱っています。
なお、2026年 9月リリースの beta4版までで「バイナリpg_dumpall」「プロパティグラフ問合せ」「テンポラルテーブル更新」「パーティションの分割／統合」など、当初の beta1 には含まれていた機能追加が取り下げられました。

• 性能向上
  • 各種プランナ改善
  • タプルデフォーム高速化
  • SIMD利用拡大
  • 外部キー制約検査の高速化
  • 基数ソート
• SQL機能
  • グルーピングの拡張
  • COPYコマンドの拡張
  • 各種の追加関数
• 運用管理
  • Autovacuumスコア
  • 各種モニタリングビューの追加
  • ログ出力の拡張
  • REPACKコマンド
• レプリケーション
  • ストリーミングレプリケーションの拡張
  • 論理レプリケーションの拡張
• 拡張モジュール
  • pg_plan_advice追加
  • pg_stash_advice追加
  • pg_stat_statements改善

検証レポート

レポートは以下リンクから参照できます。

• PostgreSQL 19 検証レポート(2026年 9月 24日版、PDFファイル、94ページ、2.1MB)

PostgreSQL 19の機能のさらなる詳細はPostgreSQL 19公式ドキュメントを参照してください。

• PostgreSQL 19 公式ドキュメント（英語）

概要

YugabyteDB Voyagerは、無料かつオープンソースのYugabyteDB移行ツールです。PostgreSQL、Oracle、MySQLといった主要なデータベースを移行元としてサポートしており、オンプレミス環境・クラウド環境のどちらでも使用可能なため、さまざまなシステム構成からの移行に対応できます。また、すべてのYugabyteDB製品を移行対象としてサポートしています。

YugabyteDB Voyagerは、YugabyteDBに移行するにあたりどの程度修正が必要な箇所があるかをリストアップし、移行可能かどうかのアセスメントを支援します。また、実際に移行すると決定した際には、テーブル定義やインデックス定義については自動で変換を行い、移行に必要な労力を最小限に抑えます。データ移行の際にはチューニングを行い、インポートパフォーマンスの向上を自動で行います。

さらに、ソースデータベースとしてPostgreSQLを使用する場合、データベース停止が必要なオフラインマイグレーションの他に、ダウンタイムを最小限に抑えるライブマイグレーションが利用可能です。ビジネスクリティカルなアプリケーションにおいて、YugabyteDBへの移行を強力に支援します。

移行方式

YugabyteDB Voyagerで利用可能な移行方式は以下の通りです。

オフラインマイグレーション

今回は、PostgreSQLからYugabyteDBへのオフラインマイグレーションを実行してみます。
環境は以下の通りです。

今回は移行元データベースとしてPostgreSQLサーバ1台、移行先データベースとしてYugabyteDB3台のクラスタ構成を構築しています。
各サーバの情報は以下の通りです。

今回はPostgreSQLサーバ、YugabyteDBクラスタの構築手順については記載を省略します。YugabyteDBクラスタの構築についてはYugabyteDB OSS版の使い方、YugabyteDB Aeon Self-Managed (旧 YugabyteDB Anywhere) の使い方も参考にしてください。

YugabyteDB Voyagerのインストール

まず、YugabyteDB Voyagerをインストールします。
公式ドキュメントの手順に従って、インストールしてください。
本稿ではPostgreSQLサーバにYugabyteDB Voyagerをインストールしています。

ソースデータベースに対する事前準備

まず、ソースデータベース(PostgreSQL)にマイグレーション用のユーザを作成します。マイグレーション用ユーザは移行対象のすべてのリソースに対してREAD権限を持っている必要があります。

今回はybvoyagerユーザを作成します。
ソースデータベースに接続し、以下のSQLを実行しました。

CREATE USER ybvoyager PASSWORD 'password';

次に、必要な権限を与えます。移行対象のデータベースに接続し、/opt/yb-voyager/guardrails-scripts/以下にある yb-voyager-pg-grant-migration-permissions.sql を実行します。

psql -h 172.20.0.15 \
     -d db1 \
     -U postgres \
     -v voyager_user='ybvoyager' \
     -v schema_list='public' \
     -v is_live_migration=0 \
     -v is_live_migration_fall_back=0 \
     -f /opt/yb-voyager/guardrails-scripts/yb-voyager-pg-grant-migration-permissions.sql

これで、ソースデータベースに対する準備は完了しました。

ターゲットデータベースに対する事前準備

ターゲットデータベース(YugabyteDB)に移行先のデータベースを用意します。
移行先のデータベース名はソースデータベースと同じ名前でも異なる名前でも問題ありません。(以降のyb-voyagerコマンド実行時に、データベース名を指定しない場合、yb-voyagerは移行先データベースを yugabyte データベースとみなします。)
移行先データベース名をyugabyteから変更したい場合は、YugabyteDB クラスタにデータベースを作成してください。

CREATE DATABASE db1 WITH COLOCATION = true;

次に、ターゲットデータベースについてもマイグレーション用ユーザを作成します。スーパーユーザとして作成する必要があります。
今回はybvoyagerユーザを作成しました。

CREATE USER ybvoyager SUPERUSER PASSWORD 'password';

エクスポートディレクトリの設定

yb-voyagerはすべてのマイグレーションの状態をエクスポートディレクトリに書き出します。これは、Voyagerが使用するメタデータに加えて、スキーマやデータのダンプも含まれます。そのため、ソースデータベース全体を格納できる、十分な空き容量のあるファイルシステム上にエクスポートディレクトリを作成してください。

mkdir -p $HOME/yb-migrate/export-dir

マイグレーションを実行すると、yb-voyagerによって、以下のディレクトリが作成されます。

assessment: アセスメント時のメタデータと、アセスメント結果を格納します。
schema: ソースデータベースのスキーマがCSV形式で格納されます。
data: ソースデータベースのデータがCSV形式で格納されます。
metainfo/temp yb-voyagerが内部予約しているディレクトリです。
logs: コマンド実行時のログファイルが格納されます。

設定ファイルの用意

yb-voyagerコマンドには、設定値を一括で記載する設定ファイルが用意されています。設定ファイルを使用すると、コマンド実行時に逐一パラメータを指定する必要がないため便利です。(v2025.6.2以降に導入された機能です。)

/opt/yb-voyager/config-templates以下にテンプレートファイルが提供されているので、このテンプレートファイルをコピーして使用します。今回はオフラインマイグレーション用のファイル(offline-migration.yaml)を使用します。

cp /opt/yb-voyager/config-templates/offline-migration.yaml ~

ファイル内の、エクスポートディレクトリに関する項目、ソースデータベースの接続情報、ターゲットデータベースへの接続情報を編集する必要があります。以下は設定例です。

export-dir: /voyager/export-dir
yugabyted-control-plane:
  db-conn-string: postgresql://yugabyte:yugabyte@172.20.0.11:5433  
source:
  db-type: postgresql
  db-host: 172.20.0.15
  db-port: 5432
  db-name: db1
  db-schema: public
  db-user: ybvoyager
  db-password: password
target:
  db-host: 172.20.0.11
  db-port: 5433
  db-name: db1
  db-user: ybvoyager
  db-password: password

マイグレーションのアセスメント

以下のコマンドを実行して、マイグレーションのアセスメントを実施します。
このとき、先ほど作成したYAMLファイルのパスを–config-fileに指定します。
今回は、~/offline-migration.yamlを指定しています。

yb-voyager assess-migration --config-file ~/offline-migration.yaml

実行すると、評価レポートのパスがコンソールに出力されます。
評価レポートはJSON形式とHTML形式で出力されます。以下はhtml形式の評価レポートです。

移行の難易度や、非互換のオブジェクトが存在しているかを確認することができます。

スキーマのエクスポート

アセスメントが完了したら、次はソースデータベースからスキーマをエクスポートします。
以下のコマンドを実行してください。

yb-voyager export schema --config-file ~/offline-migration.yaml

実行すると、エクスポートディレクトリのschemaディレクトリに、結果が保存されます。

スキーマのエクスポートの際に、yb-voyagerはスキーマ定義の調整を自動で行います。

スキーマの分析

スキーマのエクスポート時に、yb-voyagerはスキーマ定義の調整を自動で行います。しかし、自動調整だけではYugabyteDBへのインポートが失敗する可能性があります。YugabyteDBはPostgreSQLと互換性がありますが、分散システムであるため、スキーマに若干の手動変更が必要になります。

以下コマンドを実行し、スキーマを分析してください。

yb-voyager analyze-schema --config-file ~/offline-migration.yaml

手動変更が必要なDDLステートメント一覧を表示するレポートを出力します。

スキーマの手動修正

生成されたレポートに記載のあるすべての問題について、EXPORT_DIR/schema/以下にある、対象のDDLを修正してください。手動で修正を加えたら、yb-voyager analyze-schema コマンドを再実行してください。変更内容を反映した新しいレポートが生成されます。生成されたレポートに問題がなくなるまで、この手順を繰り返す必要があります。

スキーマのインポート

スキーマの修正が完了したら、ターゲットデータベースにスキーマをインポートします。

yb-voyager import schema --config-file ~/offline-migration.yaml

yb-voyagerコマンドは、エクスポートディレクトリのschemaサブディレクトリにあるDDL を、ターゲットのYugabyteDBデータベースに適用します。もし、スキーマのインポートが途中で異常終了してしまった場合は、設定ファイルのignore-existパラメータをtrueに変更してから再実行してください。すでに作成に成功したオブジェクトは無視するようになります。

データのエクスポート

スキーマ移行が完了したら、次はデータ移行を行います。まずは、ソースデータベースからデータをエクスポートします。

yb-voyager export data --config-file ~/offline-migration.yaml

このコマンドは、EXPORT_DIR/data以下にCSV形式でデータをダンプします。

注意事項

データエクスポートの際は、以下の点に注意してください。

• PostgreSQLの場合、ソースデータベース上でロックを獲得しようとしている他のプロセスが存在しないことを確認してください。並列ジョブが複数ある場合、データをダンプすることはできません。
• シーケンスの移行は、シーケンスの作成とレジューム値の設定という2つのステップで構成されています。レジューム値はデータのエクスポート時に生成されます。また、すべてのテーブルデータがインポートされた直後に、ターゲットのYugabyteDBデータベースにこれらのレジューム値は設定されます。PostgreSQLの場合、移行対象テーブルに紐づけられている、または、テーブルが所有するシーケンスのみが移行時に復元されます。
• ソースデータベース上のテーブルの行サイズが大きすぎて、デフォルトのRPCメッセージサイズを超えている場合、インポートデータは「ERROR: Sending too long RPC message…」というエラーで失敗します。そのため、行サイズが大きいテーブルは、該当箇所を削除してから個別に移行する必要があります。

データのインポート

データをエクスポートできたら、次はターゲットデータベースにデータをインポートします。

yb-voyager import data --config-file ~/offline-migration.yaml

進行状況を確認したい場合は、yb-voyager import data statusを実行してください。

デフォルトでは、yb-voyagerは複数の接続を使用して並列にデータをインポートします。並列度はクラスタのリソース使用状況に基づいて判断されます。

yb-voyagerは、データダンプファイル(EXPORT_DIR/data)をより小さなバッチに分割します。yb-voyagerは、ターゲットのYugabyteDBデータベースクラスタのすべてのノードが使用されるように、バッチを同時に取り込みます。このフェーズは、データインポート中にyb-voyagerが終了した場合でも再開できるように設計されています。再開後、データのインポートは処理が中断された地点から続行されます。

注意事項

データインポートの際は、以下の点に注意してください。

• 大規模データセットをインポートする場合は、ターミナルセッションが終了してもインポート処理が中断されないように、screenセッションでimport dataを実行してください。
• yb-voyagerのimport dataコマンドがデータ取り込み完了前に終了した場合は、同じ引数で再度実行すれば、データインポート処理が再開されます。

データインポート後のスキーマ調整

ソースデータベースにNOT VALID制約がある場合は、データインポート後に制約を作成するコマンドを実行する必要があります。

yb-voyager finalize-schema-post-data-import --config-file ~/offline-migration.yaml

マイグレーションの検証

スキーマとデータのインポートが完了したら、データが正しく移行されていることを確認します。
ソースデータベースとターゲットデータベース(YugabyteDB)の両方で検証用クエリを手動で実行して確認を行います。
例えば、各テーブルの行数を確認するクエリを実行して行数がそろっているかどうかの確認を行ってください。

マイグレーションの終了

データが正しく移行されていることを確認できたら、移行する際に作成されたディレクトリ・データをクリーンアップします。
yb-voyager end migration コマンドで、クリーンアップを実行します。

yb-voyager end migration --config-file ~/offline-migration.yaml

必要であれば、移行に使用したybvoyagerユーザの削除も行ってください。
yb-voyagerで移行を実施すると、移行されたすべてのオブジェクトはybvoyagerユーザが所有している状態となります。
オブジェクトの所有者を別のユーザに変更してから、ybvoyagerユーザを削除してください。

終わりに

本稿ではYugabyteDBへのマイグレーション支援ツール YugabyteDB Voyagerの使用方法を紹介しました。
YugabyteDBはPostgreSQL互換データベースであるとはいえ、アーキテクチャが異なりますので、移行する際はスキーマ定義の修正が必要になります。
YugabyteDB Voyagerは、スキーマ定義の互換性の評価から実施できますので、マイグレーションを行う際の強力なツールとなります。
YugabyteDBへの移行を検討している方は、ぜひYugabyteDB Voyagerをご活用ください。

参考

YugabyteDB Voyager 公式ドキュメント

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 の導入をご検討ください。

さらに Kafka から取り出したメッセージに何らかの処理を行い再度 Kafka に書き込む、という処理を行うにあたっては Offset Commit もトランザクションに含めることができます。

この記事ではトランザクションを用いて送信したメッセージが後段で読まれるまでの流れを説明し、さらに Offset Commit をトランザクション内で行う際の流れについても説明します。

Kafka バージョンは 4.1.0 を用います。

トランザクションでメッセージを送る流れ

メッセージ送信だけでなく Offset Commit も一つのトランザクションにまとめられるのが Kafka のトランザクションの特徴ですが、まずトランザクションを用いて単純にメッセージを送る流れから説明します。

トランザクションを使用してメッセージを送信する際の大まかな流れは以下の通りです (すべて正常に送信できた場合)。

1. トランザクションを初期化
2. トランザクションを開始
3. メッセージを送信 (ここでは送信先は Topic A)
4. トランザクションを Commit

このように大まかな流れはデータベースのトランザクションと同様です。そして各ステップでそれぞれ以下のメソッドが対応します。

1. トランザクションを初期化 (initTransactions メソッド)
2. トランザクションを開始 (beginTransaction メソッド)
3. メッセージを送信 (send メソッド)
4. トランザクションを Commit (commitTransaction メソッド)

また送信中に例外が起きた場合などは abortTransaction メソッドによりトランザクションを Abort します。これらはすべて Producer のメソッドです。

トランザクションの挙動

ここからは各メソッドがどのように動作するかを説明します。

1. トランザクションの初期化 (initTransactions)

まずトランザクションを利用する前に initTransactions を呼び出します。このメソッドでは Transaction Coordinator に InitProducerId リクエストを送信してトランザクション初期化の処理を行います。InitProducerId リクエストには TransactionalID が含まれています。これは Producer のパラメータで、トランザクションを識別できるようにクラスタ内で一意になるよう設定します。初期化処理ではこの ID をもとに Transaction Coordinator から Producer ID を取得します。initTransactions は Producer 起動時に 1 回実行する必要があります。

2. トランザクションの開始 (beginTransaction)

次に beginTransaction メソッドによってトランザクションを開始します。このメソッドでは Transaction Coordinator にリクエストを送るわけではなく Producer 内部の状態を変更することでトランザクションを開始します。

3. メッセージを送信 (send)

メッセージの送信は通常の送信と同様 send メソッドを用います。基本的には通常の送信と同じ挙動なのですが、Broker はトランザクション中の Produce リクエストを受け取るとメッセージの書き込みの前に (未実施であれば) AddPartitionsToTxn というリクエストを Transaction Coordinator に送ります。このリクエストでは書き込み先の Topic と Partition を Transaction Coordinator に知らせ、__transaction_state というトランザクション管理用内部 Topic に記録します。これによってどの Partition がトランザクション中なのか記録することができます。

4. トランザクションを Commit/Abort (commitTransaction/abortTransaction)

必要なメッセージ送信が完了したら commitTransaction によってトランザクションを確定させます。commitTransaction ではトランザクションを Commit する旨を添えて EndTxn リクエストを Transaction coordinator に送ります。Transaction coordinator がリクエストを受け取るとまず __transaction_state に Commit する旨を記録します。さらに AddPartitionsToTxn によって記録されている Partition に対して Commit したことを示すメッセージを送ります。このメッセージは Control Batch と呼ばれる、トランザクションの終了を示す特別なメッセージです。Control Batch の送信は commitTransaction とは非同期で行われます。

トランザクションを Abort するには abortTransaction を用います。abortTransaction ではトランザクションを Abort する旨を添えて EndTxn リクエストを送り、関連する Partition に Abort したことを示す Control Batch を送ります。

Commit / Abort がされた状態の Partition は下図のようになっています。Control Batch も通常のメッセージと同じように記録されます。

トランザクションで送信したメッセージの読み出し

次にメッセージを読み出す際にトランザクション中のメッセージや Abort したメッセージをどのように扱うかについて説明します。

すでに述べたように、トランザクションの Commit / Abort は Control Batch によって行うのでトランザクション中のメッセージも Partition 内には記録されています。また Abort したメッセージも Partition 内には残っています。これらのメッセージをどのように扱うかは Consumer の設定である isolation.level によって決まります。

isolation.level には read_uncommitted (デフォルト値) あるいは read_committed を設定することができます。read_uncommitted の場合、poll メソッドはトランザクション中かどうかや Abort されているかに関わらずすべてのメッセージを取得することができます。

次に read_committed の場合ですが、この説明のためには Last Stable Offset (LSO) について説明する必要があります。LSO はトランザクションが未確定の Offset のうち一番小さい Offset のこと (下図では Offset 6) です。これより前の Offset はすべて確定していることになり、Stable Offsets といいます。逆にこれより後の Offset の領域では確定と未確定が混在していることになります。混在しうるのは同じ Partition に複数の Producer がトランザクションでメッセージを送信する場合です。read_committed の場合、poll メソッドは Stable Offsets のメッセージのみ取得することができます。さらに Abort されたメッセージを取り除いた上でユーザーに返します。

このように、トランザクションを使って送信したメッセージを読み出す際は isolation.level を read_committed にすることで Commit 済みのメッセージのみ読むことができます。

トランザクションと Offset Commit

冒頭で述べたように、Offset Commit をトランザクションに含められる点が Kafka のトランザクションの特徴です。この仕組みは、Kafka から取得したメッセージに何らかの処理を行い、再度 Kafka に書き込むような処理で利用されます。

この例では以下の流れで処理が進みます。

1. クライアント AP が Topic A からメッセージを取得
2. 取得したメッセージを AP で処理し、その結果を Topic A’ に送信
3. すべての処理結果送信が完了したら Topic A の Offset Commit

ここで Offset Commit がトランザクションに入らない場合を考えてみましょう。処理結果の送信がアトミックにできたとしても Offset Commit に失敗した場合メッセージの取得からやり直すことになり、処理結果が二重に記録されてしまいます。Offset Commit がトランザクションに入れば、Offset Commit に失敗した時に Abort することができます。

このような利点があるため、Kafka から取得したメッセージに何らかの処理を行い、再度 Kafka に書き込むという処理では Offset Commit をトランザクション内で行います。

Offset Commit をトランザクション内で行う際の挙動

Kafka ではトランザクション内で Offset Commit をするために Producer 側で sendOffsetsToTransaction というメソッドが用意されています。全体の流れで見るとトランザクションを Commit する前に sendOffsetsToTransaction をすることになります。

1. トランザクションを初期化 (initTransactions メソッド)
2. Topic A からメッセージを取り出す (Consumer が poll メソッドで取得)
3. トランザクションを開始 (beginTransaction メソッド)
4. 処理結果のメッセージを Topic A’ に送信 (send メソッド)
5. Topic A について Offset Commit (sendOffsetsToTransaction メソッド)
6. トランザクションを Commit (commitTransaction メソッド)

sendOffsetsToTransaction では TxnOffsetCommit リクエストを Consumer Group Coordinator に送ります。Offset Commit のやり方自体は通常の Consumer から行うものと同じで、__consumer_offsets という内部 Topic へ Offset Commit の情報が記録されます。異なるのは内部 Topic への記録の前に (未実施であれば) AddPartitionsToTxn リクエストが送信される点です。send と同様に、この操作によってトランザクションに含まれる Partition の情報が __transaction_state に記録されます。

Offset Commit 情報の Commit (あるいは Abort) も、__consumer_offsets の対応する Partition に Control Batch を送ることによって記録されます。

終わりに

Kafka でトランザクションを用いてメッセージを送信し確定させるまでの挙動と、トランザクションで送信したメッセージを読み出す際の挙動について解説しました。さらに Offset Commit をトランザクション内で行う際の挙動についても解説しました。

Kafka のトランザクションで Offset Commit を行う場合、本来 Consumer から行うものを Producer から行うため混乱しますが、単にメッセージを送るのみであれば使う流れはデータベースのトランザクションと同じようなものです。メッセージを送るのみの流れ、Offset Commit もする場合の流れと段階的に理解するのがよいでしょう。

notice: High CPU load detected
info: New throttle mode
debug: New job limit is 1

このログを初めて見たとき、「クラスタに異常が発生したのではないか」と不安に感じる方もいるかもしれません。しかし結論から言うと、これらのログは障害ではありません。クラスタノードの負荷が高くなったため、Pacemaker の 負荷保護機構 (スロットリング) が正常に動作したことを示すログです。

本記事では、Pacemaker の運用で頻繁に遭遇する負荷スロットリングについて、ログの意味を読み解きながら分かりやすく解説します。なお、本記事は Pacemaker 3.0.1 を前提としています。

負荷スロットリングとは何か

Pacemaker の負荷スロットリングとは、ノードの負荷が高くなった際にリソースアクション (start / stop / monitor など) の同時実行数を自動的に減らす安全機構です。Pacemaker はクラスタの状態を維持するために、リソースの起動や停止、監視など多くの処理を常に実行しています。これらは通常、並列に実行されることで迅速なフェイルオーバーや復旧を実現しています。

しかし、ノードがすでに高負荷状態のときに大量のリソース操作を同時実行すると、状況がさらに悪化する可能性があります。monitor のタイムアウトやフェイルオーバーの誤発生、さらには STONITH の誤発動などが連鎖的に発生し、クラスタ全体が不安定な状態に陥ることがあります。

このような事態を防ぐために、Pacemaker は自らの動作を意図的に減速させます。これがスロットリングです。

通常時の並列制御の仕組み

Pacemaker のリソースアクションは、通常時でも無制限に並列実行されるわけではありません。次の 2 つのパラメータで制御されています。

• node-action-limit（ノード単位）
• batch-limit（クラスタ全体）

node-action-limit

node-action-limit は、ノード単位で同時実行できるアクション数の上限を決めるパラメータです。デフォルト値は 0 (自動) であり、次の式で自動計算されます。

node-action-limit = CPUコア数 × 2

たとえば 4 コアのサーバであれば、最大 8 個のリソース操作を同時に実行できます。この設計により、通常時は効率よくリソース操作を処理できるようになっています。

batch-limit

batch-limit はクラスタ全体での同時実行数を制御します。node-action-limit が「各ノード単位の上限」であるのに対し、batch-limit は「クラスタ全体で同時に実行できるアクション数の上限」です。デフォルト値は 0（自動）で、Pacemaker がクラスタの状態や負荷状況を見ながら動的に調整します。

では、ノードが高負荷になった場合はどうなるのでしょうか。ここから動的スロットリングについて見ていきます。

代表的な負荷制御ログ

Pacemaker は、ノード負荷に応じたスロットリングが発生すると、次のようなログを出力します。

ここでは debug ログを有効化した場合の出力例を示します。

debug: Current load is 1.110000 across 4 core(s)
notice: High CPU load detected: 8.040000
info: New throttle mode: high load (was medium)
debug: Node node1 has high load and supports at most 8 jobs; new job limit 1

以降では、これらのログがそれぞれ何を意味しているのかを順番に解説していきます。

Current load (現在のノード負荷)

debug: Current load is 1.110000 across 4 core(s)

このログは、Pacemaker が現在のノード負荷をどのように認識しているかを示しています。

Pacemaker が負荷判定に使用している指標は load average です。ここで表示されている「Current load」は、/proc/loadavg の先頭フィールドである 1 分平均の load average を示しています。

High CPU load detected (高負荷の検出)

notice: High CPU load detected: 8.040000

このメッセージは、load average が Pacemaker の定義するしきい値を超えたことを示しています。

しきい値は load-threshold (デフォルト 80%) を基準に、CPU コア数から自動的に計算されます。Pacemaker は load average に対して、low / medium / high の 3 段階のしきい値を次の式で算出します。

low    = load-threshold × CPUコア数 × 1.2
medium = load-threshold × CPUコア数 × 1.6
high   = load-threshold × CPUコア数 × 2.0

例えば CPU 4 コア、load-threshold = 80% の場合、各段階のしきい値は次のようになります。

low    = 0.8 × 4 × 1.2 = 3.84
medium = 0.8 × 4 × 1.6 = 5.12
high   = 0.8 × 4 × 2.0 = 6.40

4 コア環境では、load average が 6.4 を超えた時点で High 判定となります。そのため、ログに表示されている 8.04 は、Pacemaker が明確に「高負荷」と判断した状態であることを意味します。

New throttle mode (スロットルモードの遷移)

高負荷が検出されると、Pacemaker はスロットルモードを変更します。

info: New throttle mode: high load (was medium)

このログは、CPU 負荷の段階に応じて、Pacemaker が並列実行数を制御するスロットルモードを medium から high に変更したことを示しています。Pacemaker は高負荷時に自らのアクション発行がさらに負荷を悪化させることを防ぐため、ジョブの同時実行数を段階的に制限します。

なお、古いバージョンではスロットルモードがビット表記で表示されることがあります。

スロットルモードが頻繁に変動している場合は、CPU 負荷が継続的に高い状態にある可能性があります。その場合は ps や top などを用いて高負荷の原因となっているプロセスを特定する必要があります。

New job limit is 1 の意味

debug: Node node1 has high load and supports at most 8 jobs; new job limit 1

このログは、ノードの高負荷を検知した結果、Pacemaker が同時実行できるジョブ数を制限したことを示しています。

通常時、Pacemaker は CPU コア数 × 2 のジョブを同時に実行できます。例えば 4 コアのノードであれば、デフォルトでは最大 8 ジョブを並列実行できます。負荷の上昇に応じて同時実行数は段階的に引き下げられ、high モード に到達すると最終的に 1 まで縮小されます。

つまりこのログは、Pacemaker がクラスタの安定性を優先し、意図的に並列処理を最小化した状態を示しています。

動作検証

stress-ng を使用して CPU 負荷を段階的に上げると、スロットルモードがどのように遷移するかを確認できます。ここでは、その挙動をログから読み取ります。

以下のログから分かるように、負荷の上昇に伴いスロットルモードは low → medium → high と段階的に遷移し、それに合わせて job limit が 8 → 4 → 2 → 1 と減少していきます。
これは Pacemaker が想定どおりに負荷保護を実施していることを示しています。

debug: Current load is 0.020000 across 4 core(s)
debug: Current load is 0.070000 across 4 core(s)
debug: Current load is 0.240000 across 4 core(s)
debug: Current load is 1.110000 across 4 core(s)
debug: Noticeable CPU load detected: 4.750000
debug: Current load is 4.750000 across 4 core(s)
info: New throttle mode: low load (was negligible)
debug: Node node1 has low load and supports at most 8 jobs; new job limit 4
info: Moderate CPU load detected: 6.060000
debug: Current load is 6.060000 across 4 core(s)
info: New throttle mode: medium load (was low)
debug: Node node1 has medium load and supports at most 8 jobs; new job limit 2
notice: High CPU load detected: 8.040000
debug: Current load is 8.040000 across 4 core(s)
info: New throttle mode: high load (was medium)
debug: Node node1 has high load and supports at most 8 jobs; new job limit 1
notice: High CPU load detected: 9.860000
debug: Current load is 9.860000 across 4 core(s)
notice: High CPU load detected: 11.480000
debug: Current load is 11.480000 across 4 core(s)

おわりに

今回は、Pacemaker の負荷スロットリングの動作について、ログの意味や挙動を中心に解説しました。

「High CPU load detected」や「New throttle mode」といったメッセージは、障害ではなく、クラスタを安定させるための自己防衛機構が正常に動作していることを示しています。ただし、この状態が頻繁に発生する場合は、ノードに継続的な高負荷が発生している可能性があります。CPU 使用率や実行中プロセスを確認し、負荷の原因を特定・改善することが重要です。

本記事では、スプリットブレイン対策の中でも、2 ノードクラスタにおけるクォーラム確立を支援する「クォーラムデバイス」に焦点を当て、その仕組みと基本的な使い方について紹介します。

クォーラムデバイスの仕組み

クォーラムデバイスは、ノード間通信が切断された際に、どのノード (またはパーティション) がクラスタの運用を継続すべきかを判断するための外部投票ノードです。

偶数ノードで構成されたクラスタでは、ネットワーク分断時に投票数が同数となり、クォーラム (過半数) が成立しないという問題があります。特に2ノードクラスタでは、インターコネクトが切断されると双方が相手を障害と誤認し、スプリットブレイン状態に陥るリスクが高くなります。

このような構成では、クラスタノードとは別に調停役となるクォーラムデバイスを追加することで、クラスタ全体の投票数が奇数となり、過半数による多数決が成立します。その結果、スプリットブレイン発生時でも、どちらのノードがクラスタを継続すべきかを適切に判断できるようになります。

2ノードクラスタの場合、通常は各ノードが1票ずつを持ちますが、クォーラムデバイスを追加すると合計3票となります。ネットワーク分断が発生した際には、クォーラムデバイスの投票を含めた多数決により、過半数を得たノードのみがクラスタ管理を継続できます。これにより、両ノードが同時にリソースを稼働させる事態を防止できます。

偶数ノード構成、特に2ノードクラスタではスプリットブレインのリスクが高いため、クォーラムデバイスの利用が推奨されます。

クォーラムデバイスを利用したクラスタ構成

以下は、クォーラムデバイスを利用したクラスタ構成です。

クォーラムデバイスを利用する場合、クラスタノードには corosync-qdevice をインストールし、調停役となるサーバには corosync-qnetd をインストールします。corosync-qnetd デーモンはクラスタ外部で動作し、投票を行います。分断時には corosync-qnetd の判定結果に基づき、過半数を得たノードのみがクラスタを維持し、過半数を得られなかったノードはクラスタサービスを停止します。

corosync-qnetd の判定アルゴリズム

corosync-qnetd は、以下の判定アルゴリズムに対応しています。

• ffsplit (fifty-fifty split)：デフォルトのアルゴリズムです。アクティブなノード数が最も多いパーティションに 1 票を与えます。クラスタが同数（1:1）に分断された場合は、tie_breaker の設定に基づいて投票先を決定します。デフォルトでは、最も小さな node ID を含むパーティションに 1 票を与えます。
• lms (last-man-standing)：corosync-qnetd サーバと通信できるノードが 1 台のみになった場合、そのノードに 1 票を与えます。

クォーラムデバイス構成時の注意点

クォーラムデバイスを構成する際には、以下の点を考慮する必要があります。

• クォーラムデバイスはクラスタノードとは別のサーバで動作させる必要があります。既存のクラスタノード上で実行しないでください。
• 可能であれば、クォーラムデバイスを Corosync が使用するネットワークとは異なるネットワークに配置します。
• 複数のクラスタで 1 つのクォーラムデバイスを共有できますが、1 つのクラスタに複数のクォーラムデバイスを構成することはできません。

検証環境と前提条件

本記事では、クォーラムデバイスを利用した 2 ノードクラスタ構成で動作検証を行います。

クラスタ構成およびクォーラムデバイスは以下になります。

今回は検証目的で RHEL クローン OS の Rocky Linux 環境を用いて検証を行います。Rocky Linux では Red Hat High Availability Add-On 相当のパッケージが highavailability リポジトリに含まれているため、今回はそちらのリポジトリを利用してインストールします。バージョン情報は以下になります。

すべてのクラスタノードおよびクォーラムデバイスとして動作するノードにおいて、/etc/hosts にホスト名と IP アドレスを設定します。

# vi /etc/hosts
(以下を追加)
192.168.100.101 node1
192.168.100.102 node2
192.168.100.100 qdevice

Pacemaker のインストールおよびクラスタの初期設定

1. Pacemaker をインストールします。

各クラスタノードで highavailability リポジトリを有効にし、Pacemaker 関連パッケージをインストールします。

(node1、node2 で実行)
# dnf install -y --enablerepo=highavailability pacemaker pcs

※ RHEL 環境を利用している場合は、Red Hat 社によって提供される Red Hat High Availability Add-On のパッケージを利用してインストールしてください。詳細についてはこちらを参照してください。

2. firewalld デーモンが起動している場合は、クラスタ通信に必要なポートを許可するように以下のコマンドを実行します。

(node1、node2 で実行)
# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --reload

3. 両ノードで hacluster ユーザのパスワードを設定します。

(node1、node2で実行)
# passwd hacluster
Changing password for user hacluster.
New password: (haclusterユーザのパスワードを入力)
Retype new password: (haclusterユーザのパスワードを入力)
passwd: all authentication tokens updated successfully.

4. 両ノードで以下のコマンドを実行し、pcsd の自動起動を有効化します。

(node1、node2 で実行)
# systemctl start pcsd.service
# systemctl enable pcsd.service

5. いずれかのノードからクラスタを構成するノードに対して、hacluster ユーザの認証を行います。

(node1 または node2 のいずれかで実行)
# pcs host auth node1 node2 -u hacluster
Password: (haclusterユーザのパスワードを入力)
node1: Authorized
node2: Authorized

6. クラスタを作成します。クラスタの名前を test_cluster とします。

(node1 または node2 のいずれかで実行)
# pcs cluster setup test_cluster node1 addr=192.168.100.101 node2 addr=192.168.100.102
Destroying cluster on hosts: 'node1', 'node2'...
node1: Successfully destroyed cluster
node2: Successfully destroyed cluster
Requesting remove 'pcsd settings' from 'node1', 'node2'
node1: successful removal of the file 'pcsd settings'
node2: successful removal of the file 'pcsd settings'
Sending 'corosync authkey', 'pacemaker authkey' to 'node1', 'node2'
node1: successful distribution of the file 'corosync authkey'
node1: successful distribution of the file 'pacemaker authkey'
node2: successful distribution of the file 'corosync authkey'
node2: successful distribution of the file 'pacemaker authkey'
Sending 'corosync.conf' to 'node1', 'node2'
node1: successful distribution of the file 'corosync.conf'
node2: successful distribution of the file 'corosync.conf'
Cluster has been successfully set up.

7. クラスタを起動します。

(node1 または node2 のいずれかで実行)
# pcs cluster start --all

pcs status コマンドを使用して、作成したクラスタのステータスを表示します。node1、node2 が Online になっていることを確認します。

(node1 または node2 のいずれかで実行)
# pcs status
Cluster name: test_cluster
...
Node List:
  * Online: [ node1 node2 ]

8. クラスタを安全に運用するために、フェンシングの設定が必要になりますが、今回はクォーラムデバイスを検証することを目的としているため、以下のコマンドを実行し、フェンシングを無効にします。

(node1 または node2 のいずれかで実行)
# pcs property set stonith-enabled=false

9. 検証用の Dummy リソースを作成します。

(node1 または node2 のいずれかで実行)
# pcs resource create Dummy ocf:heartbeat:Dummy

リソースが作成されていることを確認します。

(node1 または node2 のいずれかで実行)
# pcs status
Cluster name: test_cluster
...
Full List of Resources:
* Dummy (ocf:heartbeat:Dummy): Started node1

以上で、Pacemaker クラスタの初期設定は完了です。

クォーラムデバイスを使わない場合の動作確認

ここでは、クォーラムデバイスを使用しない状態で、2 ノード間のインターコネクト通信を切断した場合の挙動を確認します。

まず、疑似障害を起こすため、node1 と node2 間のインターコネクト通信を切断します。

しばらく待ってから pcs status コマンドを実行し、クラスタの状態を確認します。すると、両ノードがそれぞれ DC (Designated Controller) として選出され、それぞれのノード上でリソースが起動していることが確認できます。

(node1 で実行) 
[root@node1 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node1 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
...
Node List:
  * Online: [ node1 ]
  * OFFLINE: [ node2 ]

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Started node1

(node2 で実行) 
[root@node2 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node2 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
...
Node List:
  * Online: [ node2 ]
  * OFFLINE: [ node1 ]

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Started node2

これは、両ノードが自身を稼働系と誤認識している状態であり、典型的なスプリットブレイン状態です。

クォーラムデバイスのインストールおよび設定

ここでは、既存のクラスタ (node1、node2) にクォーラムデバイスを追加し、スプリットブレイン防止について動作検証を通して効果を検証します。

クォーラムデバイスのインストール

1. 既存のクラスタノード node1 と node2 に corosync-qdevice をインストールします。

(node1、node2 で実行)
# dnf install -y --enablerepo=highavailability corosync-qdevice

2. クォーラムデバイスとして使用されるノード qdevice に pcs および corosync-qnetd をインストールします。

(qdevice で実行)
[root@qdevice ~]# dnf install -y --enablerepo=highavailability pcs corosync-qnetd

3. qdevice 上で pcsd サービスを起動し、自動起動の設定を行います。

(qdevice で実行)
[root@qdevice ~]# systemctl start pcsd.service
[root@qdevice ~]# systemctl enable pcsd.service

4. firewalld デーモンが起動している場合は、クラスタで必要なポートを有効化するように以下のコマンドを実行します。

(qdevice で実行)
[root@qdevice ~]# firewall-cmd --permanent --add-service=high-availability
[root@qdevice ~]# firewall-cmd --reload

クォーラムデバイスの設定

ここでは、既存のクラスタにクォーラムデバイスを追加する手順を記載します。

1. クォーラムデバイスモデル net を指定し、クォーラムデバイスのセットアップおよび起動を行います。また、システム起動時にクォーラムデバイスが起動するように設定します。

(qdevice で実行) 
[root@qdevice:~]# pcs qdevice setup model net --enable --start
Quorum device 'net' initialized
quorum device enabled
Starting quorum device...
quorum device started

起動後、pcs qdevice status net --full を実行し、クォーラムデバイスの状態を確認します。

(qdevice で実行)
[root@qdevice ~]# pcs qdevice status net --full
QNetd address:                  *:5403
TLS:                            Supported (client certificate required)
Connected clients:              0
Connected clusters:             0
Maximum send/receive size:      32768/32768 bytes

2. クラスタノードの pcs がクォーラムデバイス qdevice にアクセスできるように、hacluster ユーザの認証を行います。

(node1 または node2 のいずれかで実行)
# pcs host auth qdevice -u hacluster
Password: (hacluster ユーザのパスワードを入力)
qdevice: Authorized

3. クォーラムデバイスをクラスタに追加します。

クォーラムデバイスを追加する前に、後で比較するために、クォーラムデバイスの現在の設定と状況を確認できます。
このコマンドの出力から、クラスタがクォーラムデバイスを使用しておらず、各ノードの Qdevice メンバーシップのステータスが NR (Not Registered：登録されていない) であることが分かります。

[root@node1 ~]# pcs quorum config
[root@node1 ~]# pcs quorum status
Quorum information
------------------
Date:            Sun Feb 2 11:39:03 2026
Quorum provider: corosync_votequorum
Nodes:           2
Node ID:         1
Ring ID:         1.1d
Quorate:         Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           1
Flags:            2Node Quorate WaitForAll

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    NR      node1 (local)
         2          1    NR      node2

以下のコマンドを実行し、クォーラムデバイスをクラスタに追加します。host にクォーラムデバイスとして動作するノードのホスト名、algorithm に使用するアルゴリズム (ffsplit) を指定します。

(node1 または node2 のいずれかで実行)
# pcs quorum device add model net host=qdevice algorithm=ffsplit
Setting up qdevice certificates on nodes...
node1: Succeeded
node2: Succeeded
Enabling corosync-qdevice...
node1: not enabling corosync-qdevice: corosync is not enabled
node2: not enabling corosync-qdevice: corosync is not enabled
Sending updated corosync.conf to nodes...
node2: Succeeded
node1: Succeeded
node1: Corosync configuration reloaded
Starting corosync-qdevice...
node2: corosync-qdevice started
node1: corosync-qdevice started

上記コマンドを実行後、クォーラムデバイスの設定を確認するには、pcs quorum config を実行します。

(node1 または node2 のいずれかで実行)
# pcs quorum config
Device:
  votes: 1
  Model: net
    algorithm: ffsplit
    host: qdevice

4. クラスタノード側からクォーラムデバイスの状態を確認します。

クォーラムデバイスをクラスタに追加した後、まずはクラスタノード側から、クォーラムデバイスが正しく認識・動作しているかを確認します。

(node1 または node2 のいずれかで実行)
# pcs quorum status
Quorum information
------------------
Date:             Sun Feb  2 11:45:38 2026
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          1
Ring ID:          1.1d
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW node1 (local)
         2          1    A,V,NMW node2
         0          1            Qdevice

この Membership information は、現在のクォーラム判定に参加しているメンバー (投票者) 一覧を表しています。Qdevice が 1 vote を持つメンバーとして参加していることが分かります。

なお、A,V,NMW は votequorum におけるノード状態フラグであり、それぞれの意味は次のとおりです。

• A/NA
  • A (Active)：クォーラムデバイスがそのノードに対して有効な状態
  • NA (Not Active)：クォーラムデバイスがそのノードに対して無効な状態
• V/NV
  • V (Voting)：クォーラムデバイスがそのノードへ投票を与えている
  • NV (Not Voting)：クォーラムデバイスがそのノードに投票を与えていない
• MW/NMW
  • MW (Master Wins)：master_wins フラグが有効
  • NMW (Not Master Wins)：master_wins フラグが無効 (デフォルト)

続いて、pcs quorum device status コマンドを使って、クォーラムデバイスとの接続状態やアルゴリズム設定を確認します。

(node1 または node2 のいずれかで実行)
[root@node1 ~]# pcs quorum device status
Qdevice information
-------------------
Model:                  Net
Node ID:                1
Configured node list:
      0 Node ID = 1
      1 Node ID = 2
Membership node list:   1, 2

Qdevice-net information
----------------------
Cluster name:           test_cluster
QNetd host:             qdevice:5403
Algorithm:              Fifty-Fifty split
Tie-breaker:            Node with lowest node ID
State:                  Connected

Qdevice-net information の結果から、判定アルゴリズムと決定ルールを確認できます。

• Algorithm: Fifty-Fifty split は、クラスタが同数に分断された場合（2 ノードクラスタでは 1:1 の分断）に適用される判定アルゴリズムです。
• Tie-breaker: Node with lowest node ID は、分断時に最も小さな node ID を含むパーティションを primary component（quorum を持つ側）として選択する決定ルールを示しています。

5. 次に、クォーラムデバイス側で、corosync-qnetd デーモンの状態を確認します。

以下のコマンドを実行します。

(qdevice サーバで実行)
[root@qdevice:~]# pcs qdevice status net --full
QNetd address:                  *:5403
TLS:                            Supported (client certificate required)
Connected clients:              2
Connected clusters:             1
Maximum send/receive size:      32768/32768 bytes
Cluster "test_cluster":
    Algorithm:          Fifty-Fifty split (KAP Tie-breaker)
    Tie-breaker:        Node with lowest node ID
    Node ID 1:
        Client address:         ::ffff:192.168.100.101:33624
        HB interval:            8000ms
        Configured node list:   1, 2
        Ring ID:                1.1d
        Membership node list:   1, 2
        Heuristics:             Undefined (membership: Undefined, regular: Undefined)
        TLS active:             Yes (client certificate verified)
        Vote:                   No change (ACK)
    Node ID 2:
        Client address:         ::ffff:192.168.100.102:32998
        HB interval:            8000ms
        Configured node list:   1, 2
        Ring ID:                1.1d
        Membership node list:   1, 2
        Heuristics:             Undefined (membership: Undefined, regular: Undefined)
        TLS active:             Yes (client certificate verified)
        Vote:                   ACK (ACK)

両ノードとも、同一の Membership node list、正常な ACK 応答となっており、qnetd から見てもクラスタは健全な状態であることが確認できます。

クォーラムデバイスを使ったクラスタの動作確認

前の検証では、クォーラムデバイスを使用しない 2 ノードクラスタにおいて、ノード間のネットワークを切断すると、両ノードがそれぞれ DC となり、リソースを起動してしまう (いわゆるスプリットブレイン状態) ことを確認しました。

ここでは、クォーラムデバイスを導入した場合に、同じ障害を発生させたときの挙動がどのように変わるのかを確認します。

正常時の状態確認

まずは、ネットワーク切断前の状態を確認します。

[root@node1 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
* Stack: corosync (Pacemaker is running)
* Current DC: node1 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
* Last updated: Mon Feb 2 13:51:22 2026 on node1
* Last change: Mon Feb 2 13:36:39 2026 by root via root on node1
* 2 nodes configured
* 1 resource instance configured

Node List:
* Online: [ node1 node2 ]

Full List of Resources:
* Dummy (ocf:heartbeat:Dummy): Started node1

Quorum 情報を確認すると、Qdevice が投票に参加していることが分かります。

[root@node1:~]# pcs quorum status
Quorum information
------------------
Date:             Mon Feb  2 13:55:20 2026
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          1
Ring ID:          1.26
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW node1 (local)
         2          1    A,V,NMW node2
         0          1            Qdevice

ノード間ネットワークの切断

次に、疑似障害として node1 と node2 間のインターコネクト通信を切断します。（Qdevice との通信は維持された状態）

障害発生後の状態確認

node1 と node2 間のネットワークを切断した後、それぞれのノードで pcs status を実行し、クラスタの状態を確認します。

[root@node1 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node1 (version 3.0.1-3.el10-b1a23a6) - partition with quorum
  * Last updated: Mon Feb  2 15:14:59 2026 on node1
  * Last change:  Mon Feb  2 15:14:13 2026 by root via root on node1
  * 2 nodes configured
  * 1 resource instance configured

Node List:
  * Online: [ node1 ]
  * OFFLINE: [ node2 ]

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Started node1

node1 は クォーラムデバイスからの投票を含めて quorum を維持しており、引き続き DC として選出され、リソースを起動した状態で稼働しています。

[root@node2 ~]# pcs status
Cluster name: test_cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: node2 (version 3.0.1-3.el10-b1a23a6) - partition WITHOUT quorum
  * Last updated: Mon Feb  2 15:15:04 2026 on node2
  * Last change:  Mon Feb  2 15:14:14 2026 by root via root on node1
  * 2 nodes configured
  * 1 resource instance configured

Node List:
  * Online: [ node2 ]
  * OFFLINE: [ node1 ]

Full List of Resources:
  * Dummy       (ocf:heartbeat:Dummy):   Stopped

node2 はクラスタ内では単独ノードとなり、クォーラムを満たせない状態 (partition WITHOUT quorum) となっています。その結果、DC にはなっているものの、quorum を持たないため、リソースは起動されない、という状態になっています。

クォーラム状態の確認

次に、node1 側で pcs quorum status を実行し、クォーラム状態を確認します。

[root@node1 /]# pcs quorum status
Quorum information
------------------
Date:             Mon Feb  2 15:16:14 2026
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          1
Ring ID:          1.86
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      2
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW node1 (local)
         0          1            Qdevice

この結果から分かる通り、node1 と Qdevice がそれぞれ 1 vote を保持し、合計 2 votes（quorum＝2）となるため、node1 側では quorum が維持されています。クォーラムデバイスは、デフォルト設定では存続しているノードのうち、最も小さな node ID を持つノードを含むパーティションを選択します。今回の構成では node1 が選択され、node2 側は quorum を失う結果となりました。

ログの確認

node2 側のログを確認すると、quorum 喪失に伴う挙動が明確に分かります。

(node2ログ)
Feb 2 15:14:48 node2 pacemaker-controld[4354]: notice: Node node1 state is now lost
Feb 2 15:14:48 node2 corosync[4330]: [QUORUM] This node is within the non-primary component and will NOT provide any services.

このログは、このノードは non-primary component (quorum を持たない側) に属しており、サービスを提供してはならない、ことを示しています。

続く Pacemaker のログでも、quorum 喪失によりリソース管理が抑止されていることが分かります。

(node2ログ)
Feb 2 15:14:49 node2 pacemaker-schedulerd[4353]: warning: Fencing and resource management disabled due to lack of quorum
Feb 2 15:14:49 node2 pacemaker-schedulerd[4353]: notice: Actions: Start Dummy ( node2 ) due to no quorum (blocked)

おわりに

本記事では、2 ノードクラスタにおけるスプリットブレイン対策として、クォーラムデバイスの仕組みと設定方法、そして実際の動作検証結果について解説しました。

クォーラムデバイスを導入しない場合、ノード間のネットワーク分断時に双方が自身を正当なクラスタと判断し、同時にリソースを起動してしまう可能性があります。一方で、クォーラムデバイスを追加することで投票数が奇数となり、外部の調停役による判定が加わることで、過半数を得た側のみがサービスを継続できるようになります。これにより、2 ノードクラスタ特有のスプリットブレインリスクを大きく低減できます。

特に、コストや設計上の理由から 2 ノード構成を採用せざるを得ない環境や、環境要件や構成上の制約により電源制御を用いたフェンシングを採用しない場合には、クォーラムデバイスは有効な補完策となります。

本記事が、2 ノードクラスタの設計やスプリットブレイン対策を検討されている方の参考になれば幸いです。

一方で、冗長化によって単一障害点は解消できるものの、クラスタノード間の通信が途絶えた場合には「スプリットブレイン」状態に陥るリスクが残ります。スプリットブレインが発生すると、複数のノードが同時に稼働系として振る舞い、IP アドレスの競合やファイルシステムの二重マウントなどが発生する可能性があります。最悪の場合、データ破損といった深刻な障害につながる恐れもあります。

そのため、クラスタ構成を安定して運用するうえで、スプリットブレイン対策は欠かせないポイントです。

本記事では、Pacemaker/Corosync クラスタで広く利用されているスプリットブレイン対策の仕組みについて解説します。

スプリットブレインとは

スプリットブレインとは、クラスタを構成するノード間の通信が途絶えた際に、各ノードが互いの状態を正しく認識できなくなり、複数のノードが同時に稼働系として動作してしまう状態を指します。

通常、クラスタではノード同士が定期的にハートビート通信を行い、相互監視を行っています。しかし、ネットワーク障害などにより通信が分断されると、各ノードは相手を「障害」と誤認する可能性があります。この状態では、同一サービスやリソースが複数ノードで同時に起動されるため、IP  アドレスの競合、ファイルシステムの二重マウント、共有データへの同時書き込み、などが発生する可能性があります。

スプリットブレイン対策

Pacemaker/Corosync クラスタでは、スプリットブレインを防止するために複数の仕組みが用意されています。

Stonith によるフェンシング

STONITH (Shoot The Other Node In The Head) は、クラスタ環境で発生し得るスプリットブレインを防止するためのフェンシング手法です。ノード間の通信が途絶えた場合に、インターコネクト (クラスタ通信用ネットワーク) とは独立した経路を用いて問題のあるノードを強制的に停止または再起動させることで、データ破壊やサービスの二重起動を防ぎます。具体的には、IPMI などのハードウェア制御ボードや、共有ストレージを介した制御を利用して、異常が発生したノードを停止/再起動させます。

具体的には、以下のような仕組みが利用されます。

• • IPMI などのハードウェア制御ボード
  • 仮想化基盤の API
  • 共有ストレージを利用した制御 (SBD など)

  
  

  Pacemaker/Corosync を利用した HA クラスタにおいて、STONITH は最も確実で推奨されるスプリットブレイン対策です。

  リソースの排他制御

  リソースの排他制御により、複数ノードでの同時起動を防止する方法もあります。sfex や VIPCheck は、排他制御を実現するリソースエージェントです。

  sfex は共有ディスクを使った排他制御を実現するリソースエージェントとなります。稼働系ノードが共有ディスク上に定期的に書き込みを行うことで排他状態を維持し、ノード間通信が途絶えた場合に、両系が同時に稼働系となることを防止します。

  VIPCheck は仮想 IP 状態をチェックすることで排他制御を実現します。共有ディスクが利用できない環境でも、リソースの二重起動を抑止できます。

  なお、sfex および VIPCheck は Linux-HA Japan が提供するリソースエージェントであり、RHEL HA Add-on の標準パッケージには含まれていません。

  クォーラムによる多数決制御

  クォーラムとは、クラスタ処理を継続するために必要な最低限の投票数のことを指します。スプリットブレイン対策として広く使われている一般的な手法です。

  一般的に、3台以上のノードでクラスタを構成し、過半数を獲得したパーティションのみがクラスタを継続できる仕組みです。過半数を満たさない場合はクォーラムを喪失し、no-quorum-policy の設定に従ってリソース停止やフェンシングが実行されます。

  

  Pacemaker における no-quorum-policy の各設定値の動作は以下の通りです。

  • stop (デフォルト)
    クォーラムを喪失したノード上のすべてのリソースを停止します。
  • freeze
    現在動作しているリソースはそのまま維持しますが、新規起動や再配置は行いません。
  • ignore
    クォーラム喪失を無視し、通常どおりリソース管理を継続します。
  • demote
    Master/Slave (Promotable) リソースが存在する場合、Master を Slave に降格します。
  • suicide
    クォーラムを喪失したノードをフェンシングします。

  クォーラムデバイス

  クォーラムデバイスは、ノード間通信が切断された際に、どのノード (またはパーティション) がクラスタの運用を継続すべきかを判断するための外部投票ノードです。特に偶数ノードで構成されたクラスタでは、ネットワーク分断時に投票数が同数となり、クォーラム (過半数) が成立しないという問題があります。なかでも2ノードクラスタでは、インターコネクトが切断されると双方が相手を障害と誤認し、スプリットブレイン状態に陥るリスクが高まります。

  このような構成では、クラスタノードとは別に調停役となるクォーラムデバイスを追加することで、クラスタ全体の投票数が奇数となり、過半数による多数決が成立します。その結果、スプリットブレイン発生時でも、どちらのノードがクラスタを継続すべきかを適切に判断できるようになります。

  2ノードクラスタの場合、通常は各ノードが1票ずつを持ちますが、クォーラムデバイスを追加すると合計3票となります。ネットワーク分断が発生した際には、クォーラムデバイスの投票を含めた多数決により、過半数を得たノードのみがクラスタ管理を継続できます。これにより、両ノードが同時にリソースを稼働させる事態を防止できます。

  

  クォーラムデバイスを利用する場合、クラスタノードには corosync-qdevice をインストールし、調停役となるサーバには corosync-qnetd をインストールします。corosync-qnetd デーモンはクラスタ外部で動作し、投票を行います。分断時には corosync-qnetd の判定結果に基づき、過半数を得たノードのみがクラスタを維持し、過半数を得られなかったノードはクラスタサービスを停止します。

  偶数ノード構成、特に2ノードクラスタではスプリットブレインのリスクが高いため、クォーラムデバイスの利用が推奨されます。

  クォーラムデバイスの具体的な設定方法や、ネットワーク分断時の挙動を含む詳細な動作確認については、こちらの記事にて詳しく解説していますので、あわせてご参照ください。

  おわりに

  本記事では、スプリットブレイン対策として広く利用される以下の仕組みについて解説しました。

  • STONITH によるフェンシング
  • リソースの排他制御
  • クォーラムによる多数決制御
  • クォーラムデバイス

  Pacemaker には多数のフェンスエージェントが用意されており、物理サーバ、仮想化基盤、共有ディスク環境など、それぞれの構成に応じたフェンシング方式を選択できます。HA クラスタにおいては、フェンシングの実装が最も確実なスプリットブレイン対策といえます。

  一方で、環境要件や構成上の制約により電源制御を用いたフェンシングを採用しない場合には、クォーラム制御やクォーラムデバイスの利用によって多数決の仕組みを補強する方法があります。特に2ノードクラスタでは、クォーラムデバイスを追加することで投票数を奇数化し、分断時の判断を明確にできます。

  HA クラスタでは、冗長化するだけでは不十分で、障害時の挙動まで考えた設計が欠かせません。本記事が、より安全で堅牢なクラスタ構築の参考になれば幸いです。

この記事は SRA Advent Calendar 2025 の20日目の記事です。

Apache Kafka（以下 Kafka）には送達保証のための機能がいくつかあります。 この記事ではその中でも送達が重複するのを防止するための機能である Idempotent Producer について解説します。

Idempotent Producer は Kafka のバージョン 0.11.0.0 からある機能です。この記事ではバージョン 4.1.0 を元に解説します。

Kafka について

Kafka はストリーミング処理を実現するための OSS です。

Kafka では Producer と呼ばれるクライアントが Broker と呼ばれるサーバにデータを送信します。Broker は複数台で Kafka クラスタを構成します。Kafka ではやり取りする一つ一つのデータを Message と呼びます。 そして Consumer と呼ばれるクライアントが Broker からデータを読み出し処理、活用します。

今回紹介する Idempotent Producer は Broker に重複した Message が送られてきた時にそれを排除する機能です。 ではどのように重複は発生し、またそれはどのように排除されるのでしょうか。

Producer の自動リトライ機能

Producer から Broker に送られる Message に重複が発生するのは Producer の自動リトライ機能によるものです。まずこちらについて説明します。

Producer は Message を送ったあと Broker 側から送信が成功したかについての応答として Ack を受け取ります。この Ack をもとに Producer 側で判断して自動で Message 送信をリトライするのが自動リトライ機能です。 以下の図では送信の失敗を正しく検知し再送しています。このように自動リトライ機能は Message を確実に送るために重要な機能です。

自動リトライ機能は Producer の retries という設定値によって制御できます。 送信失敗時、Producer はこの値の回数だけ再送を試みます（0に設定すると自動再送を行いません）。ただし致命的なエラーが起こった時や delivery.timeout.ms というタイムアウト超過時などはそれ以上再送しません。 その場合はユーザー処理で再送することになりますが、そのような再送は Producer による自動リトライではないので区別されます。

さて、以上が自動リトライ機能の概要ですが、この仕組みでは以下の図のように送信には成功したのに Ack が受け取れず再送してしまう可能性があります。重複はこのようにして発生します。

Idempotent Producer（重複排除機能付きの Producer）

自動リトライによって Message が重複して記録されてしまうのを防ぐのが Idempotent Producer の機能です。次はこちらについて説明します。

この機能では Producer は各 Message に1ずつ増加するシーケンス番号を自動で割り当て、Producer ID とともに送信します。 こうすることで Broker 側では、同じ Producer から同じ Message が来たことを検知します。 以下の図のように、Broker はそれを検知した場合重複している Message を Broker 側に記録しません。 さらに、これだけでは Producer は送信が成功したか分からず再送し続けてしまうため、Broker 側は送信成功の Ack を返します。こうすることで Broker 側では Message は重複しませんし、Producer 側で再送し続けることもありません。

Idempotent Producer の重複排除で注意すべきは、検知できるのは自動リトライによる問題という点です。例えば「Producer に障害があって再起動した」という場合は元の Producer とは別の Producer として Broker は認識するので重複があっても気付けません。 また、「自動リトライでは送りきれなかったのでユーザー処理で再送する」という場合も元の Message とは別の Message として Broker は認識するので重複に気付けません。

また Idempotent Producer を有効にするには設定値が以下の条件を満たしている必要があります。デフォルトの設定ではこれらは満たされているので、Idempotent Producer はデフォルトで有効です。

重複排除のソースコード

最後に、Message の重複を検知し排除している部分を Kafka 4.1.0 のソースコードで見てみましょう。 重複の確認は UnifiedLog の append() メソッド内で行っています。このメソッドは送られてきた Message の記録をし、 記録の結果（メソッド内では appendInfo という名前）を返すメソッドです。以下はそこからの抜粋です。

// now that we have valid records, offsets assigned, and timestamps updated, we need to
// validate the idempotent/transactional state of the producers and collect some metadata
AnalyzeAndValidateProducerStateResult result = analyzeAndValidateProducerState(
        logOffsetMetadata, validRecords, origin, verificationGuard);

if (result.maybeDuplicate.isPresent()) {
    BatchMetadata duplicate = result.maybeDuplicate.get();
    appendInfo.setFirstOffset(duplicate.firstOffset());
    appendInfo.setLastOffset(duplicate.lastOffset);
    appendInfo.setLogAppendTime(duplicate.timestamp);
    appendInfo.setLogStartOffset(logStartOffset);
} else {
    // Append the records, and increment the local log end offset immediately after the append because a

analyzeAndValidateProducerState() メソッド内で重複の確認をしており、その結果を result として受け取っています。その結果で result.maybeDuplicate.isPresent() が True だと重複があることが分かります。続く if 文では重複があるか判定していますが、重複がない場合は else 節に存在する Message 記録の処理が行われ、appendInfo に値がセットされます。 重複がある場合は else 節に入らないため Message の記録は行いません。これによって重複は排除されます。また、記録はしませんが appendInfo に値をセットし正常に Message の記録が行われたときと同じ状態にします。このようにすることで Producer には正常に Message が記録されていることが伝わります。

おわりに

Idempotent Producer の仕組みについて解説しました。 重複を排除するというありがたい機能なので、仕組みを理解し適切に活用しましょう。

バージョン18の主要な拡張

PostgreSQL 18 の主な拡張点としては以下があります。

• 非同期 I/O
• B-tree インデックスのスキップスキャン
• プランナ改善（WHERE 句内に OR 条件がある場合の最適化、ほか）
• GIN インデックスの並列作成
• 大量のテーブルアクセス時のロック処理の改善
• 組み込み照合順序 pg_unicode_fast
• メジャーバージョンアップ時のプランナ統計情報の移行・チェック処理の並列化オプション/–swap オプションの追加
• 仮想生成列の追加
• 更新系 DML の RETURNING 句へ OLD, NEW の追加
• UUID v7 関数の追加
• 非決定論的な照合順序利用時のLIKE句のサポート
• CASEFOLD 関数の追加
• 各種制約の追加（WITHOUT OVERLAPS、ほか）
• ラージオブジェクトに対するデフォルト権限設定のサポート
• TLS v1.3 暗号スイートの追加
• postgres_fdw、dblink への SCRAM 認証のパススルーオプションの追加
• プランナ統計情報のダンプ／リストア
• EXPLAIN 文の強化
• pg_stat_all_tables への VACUUM、ANALYZE 総実行時間の追加
• 接続単位での I/O・WAL 利用量の取得
• 論理レプリケーション時の書き込み衝突の情報詳細化

バージョン18への移行/互換性のない変更点

1. initdbがデフォルトでチェックサム有効になりました。 (Greg Sabino Mullane) (18)

これを無効にするための新たなオプション --no-data-checksums が追加されました。pg_upgrade を使う場合に、新旧データベースクラスタでチェックサムの有無を一致させるため、チェックサム無効の旧データベースクラスタに本オプションを指定する必要があります。

§

2. タイムゾーン省略形（GMT、JSTなど）の処理が変更されました。 (Tom Lane) (18)

日付時刻データの処理に際して、timezone_abbreviations設定よりも、IANA時間帯データベース（tzdata）に基づく現在セッションのタイムゾーンの省略形を優先するようになりました。これまでは timezone_abbreviations設定を優先して、解釈が行なわれていました。

タイムゾーン省略形を含んだ日付時刻をあらわす文字列を読み込ませるときに、バージョン間で結果の差異が発生する可能性があります。

(実行例)
17.x では「ERROR:  invalid input syntax for type timestamp with time zone」となる

db1=# SET timezone TO 'Asia/Tokyo';
db1=# SELECT 'Wed Jan 01 00:00:00 1000 LMT'::timestamptz;
         timestamptz
------------------------------
 1000-01-01 00:00:00+09:18:59
(1 row)

§

3. MD5による認証およびパスワード格納の方式が非推奨になりました。 (Nathan Bossart) (18)

md5方式はバージョン18.x 時点では使用可能ですが、今後のメジャーバージョンで廃止される予定です。

md5方式を使う場合、CREATE ROLEやALTER ROLE などのコマンドでWARNING が出力されるようになります。これは新たな設定項目md5_password_warningsをoff にすることで抑止できます。

§

4. VACUUMとANALYZEが継承子テーブルを処理するようになりました。 (Michael Harris) (18)

新たなオプションONLYを使うと従来の動作（子テーブルについては処理しない）にできます。

§

5. CSVファイルを読むときに、COPY FROM が「\.」をファイル終端マーカーと扱わないようになりました。 (Daniel Verite, Tom Lane) (18)

psqlでSTDINからCSVファイルを読むときには、引続きファイル終端マーカー（EOFマーカー）として扱います。以前のバージョンのpsqlからPostgreSQL 18のサーバに接続して「\copy」を実行するときに非互換の問題に遭遇するかもしれません。

加えて、本バージョンから「\.」を単独行として書くことが必須となりました。以前は行末に書く方法が認められていました。

§ §

6. UNLOGGEDパーティションテーブルが禁止されました。 (Michael Paquier) (18)

以前は ALTER TABLE SET [UN]LOGGED を実行できましたが何の効果もありませんでした。パーティションテーブル（親テーブル）自体はデータを持ちませんし、パーティション（子テーブル）が自動でUNLOGGEDになることもありませんでした。

これからはパーティションテーブルをUNLOGGEDにするコマンドはエラーになります。パーティションをUNLOGGEDにすることは引続き可能です。

§

7. AFTERトリガを、トリガイベントがキューに入った時点で有効なロールで、実行するようになりました。 (Laurenz Albe) (18)

これまでは、トリガ実行時（例えばCOMMIT時）に有効なロールで実行されました。特に、トリガイベント発生時とトリガ実行時の間でロールの変更が有る場合に、振る舞いが変わります。

§

8. GRANT/REVOKEコマンドで RULE権限が廃止されました。 (Fujii Masao) (18)

機能としてはPostgreSQL 8.2の時点で無効になっていて、RULE権限をGRANT/REVOKEしても何の効果もありませんでした。テーブルにRULE を付与できるのは所有者とスーパーユーザのみです。

§

9. システムビューpg_backend_memory_contextsのparent列が削除されました。 (Melih Mutlu) (18)

pg_backend_memory_contextsに親コンテキストの連なりを示すpath列が加わったため、これは不要になりました。

§

10. システムビューpg_backend_memory_contextsのlevel列と、pg_log_backend_memory_contexts() 関数で、番号が1から始まるようになりました。 (Melih Mutlu, Atsushi Torikoshi, David Rowley, Fujii Masao) (18)

これまでは0から始まる番号でした。

§ § §

11. 全文検索で設定ファイルや辞書ファイルを読むときに、常にlibc を使うのではなく、データベースクラスタのデフォルトの照合順序プロバイダを使うようになりました。 (Peter Eisentraut) (18)

libc以外の照合順序プロバイダ（icu やbuiltin）をデフォルトとしているデータベースクラスタでは、いくつかの全文検索の関数とpg_trgm拡張でLC_CTYPEによる文字の処理が変わってきます。

pg_upgradeで本バージョンにアップグレードする場合、全文検索やpg_trgmに関するインデックスは、バージョンアップ後に全て再作成することが推奨されます。

§

変更点

サーバ

オプティマイザ

1. 不要なテーブルの自己結合が自動的に除去されるようになりました。 (Andrey Lepikhov, Alexander Kuzmenkov, Alexander Korotkov, Alena Rybakina) (18)

この最適化は、設定パラメータenable_self_join_eliminationを使用して無効にすることができます。

§

2. WHERE句における一部のIN (VALUES ...)を、オプティマイザがより適切な統計情報を活用できるようにx = ANY...へ変換するようになりました。 (Alena Rybakina, Andrei Lepikhov) (18)

この変換は特定の条件（定数値で構成され、1列のみを含む VALUES リストなど）に該当する場合に限り適用されます。

（実行例）
db1=# CREATE TABLE tbl (a INT);
db1=# INSERT INTO tbl VALUES (2);
db1=# EXPLAIN SELECT * FROM tbl WHERE a IN (VALUES (1), (2), (3));
                     QUERY PLAN
-----------------------------------------------------
 Seq Scan on tbl  (cost=0.00..45.06 rows=38 width=4)
   Filter: (a = ANY ('{1,2,3}'::integer[]))
(2 rows)

§

3. OR句が配列に変換され、インデックス処理が高速化されるようになりました。 (Alexander Korotkov, Andrey Lepikhov) (18)

§

4. INTERSECT、EXCEPT、ウィンドウ集約関数、ビューの列の別名の処理がそれぞれ高速化されました。 (Tom Lane, David Rowley) (18)

§ § § §

5. SELECT DISTINCTにおいて、ソート処理を回避するためにキーの順序が内部的に並び替えられるようになりました。 (Richard Guo) (18)

この最適化は、enable_distinct_reorderingを使って無効にすることもできます。

§

6. 他の列に関数的に従属する列は、GROUP BY句から自動的に除外されるようになりました。 (Zhang Mingli, Jian He, David Rowley) (18)

GROUP BY句に、あるテーブルの一意インデックスを構成するすべての列と、それ以外の列が含まれている場合、その「それ以外の列」は冗長とみなされ、グルーピングの対象から除外されるようになりました。この動作は、これまでも 遅延不可な主キーに対しては適用されていましたが、今回からより広く適用されるようになりました。

§

7. GROUPING SETSの一部のHAVING句が、WHERE句にプッシュダウンされるようになりました。 (Richard Guo) (18)

これにより、より早い段階での行のフィルタリングが可能になりました。また、本リリースではGROUPING SETSを使用した一部のクエリで、以前は誤った結果が返されることがありましたが、修正されました。特に、GROUPING SETSとDISTINCT ONの併用、あるいはORDER BYとの併用において、NULLの扱いに起因する誤った結果が発生していた問題が解消されています。

（実行例）

(17.xでは以下)
db1=# SELECT DISTINCT ON (a, b) a, b
FROM (VALUES (1, 1), (2, 2)) AS t(a, b) WHERE a = b
GROUP BY GROUPING SETS ((a, b), (a));
 a | b
---+---
 1 | 1
 2 | 2
(2 rows)

(18では以下）
 a | b
---+---
 1 | 1
 1 |
 2 | 2
 2 |
(4 rows)

(17.xでは以下。ORDER BYでNULLを含む列の扱いが不十分で、誤った順序が返される)
db1=# SELECT a, b FROM (VALUES (1, 1),(2, 2)) AS t(a, b) WHERE a = b
GROUP BY CUBE (a, (a, b)) ORDER BY b, a;
 a | b
---+---
 1 | 1
 1 | 1
 1 |
 2 | 2
 2 | 2
 2 |
   |
(7 rows)

(18では以下）
 a | b
---+---
 1 | 1
 1 | 1
 2 | 2
 2 | 2
 1 |
 2 |
   |
(7 rows)

§ § § §

8. generate_series()におけるnumeric型やtimestamp型の値に対する行数の見積もりが改善されました。 (David Rowley, Song Jinzhou) (18)

§ §これまでtimestamp型やnumeric型では、たとえ入力が定数であっても常にデフォルトの1000行と見積もられていましたが、本リリース以降は入力値に基づいて実際の行数を正確に推定できるようになりました。

9. オプティマイザがRight Semi Joinプランを使用できるようになりました。 (Richard Guo) (18)

セミジョインは、少なくとも1件の一致が存在するかどうかを判定する目的で使用されます。

§

10. マージ結合でインクリメンタルソートが使用できるようになりました。 (Richard Guo) (18)

§

11. 多数のパーティションにアクセスする問合せの実行プラン作成において、効率が改善されました。 (Ashutosh Bapat, Yuya Watari, David Rowley) (18)

これまではプラン作成に際して同値クラスの導出句が線形探索されており、対象のテーブル数やパーティション数が多い問合せでプラン作成時間が増大しました。

探索にハッシュテーブルを利用する等の高速化が適用されました。

§ §

12. より多くのケースでパーティション単位の結合ができるようになりました。また、メモリ使用量も削減されました。 (Richard Guo, Tom Lane, Ashutosh Bapat) (18)

これまでは、パーティション単位の結合（partitionwise join）を使用できるかどうかの判断が、問合せで明示的に記述された結合条件に基づいて行われていて、実際は可能であるのに適用されないことがありました。これからは、同値クラスに基づき判断されます。

また、パーティションの組み合わせごとの結合で確保されるメモリを各結合の完了後に解放するようになりました。

§ §

13. パーティションテーブルへの問合せで、プラン作成時のコスト推定が改善されました。 (Nikita Malakhov, Andrei Lepikhov) (18)

結果として、これまでよりもIndex Scan、および、パラメータ化Nested Loopが選択されやすくなっています。

§

14. SQL言語の関数のプランキャッシュが改善されました。 (Alexander Pyhalov, Tom Lane) (18)

これまでは、SQL関数内で作成した実行プランは問合せが終了すると全て破棄されていました。今回の変更で、SQL関数に対してもPostgreSQLのプランキャッシュ基盤を利用できるようになりました。

付随して、SQL関数の戻り値は関数内の最後の文によって生成されるという規則が厳格化されました。これまでは最後のSQL文が「DO INSTEAD NOTHING」で実行されなかった場合に手前の問い合わせ結果が返されることがありましたが、この挙動は廃止されました。

また、下記のように関数内でDDL（データ定義言語）を実行すると、関数内の後続のSQL文に反映されるようになりました。

db1=# CREATE TEMP TABLE t14 (x int); -- 関数定義用に1回だけ事前作成
db1=# CREATE FUNCTION f14() RETURNS void LANGUAGE SQL AS $$
        CREATE TEMP TABLE IF NOT EXISTS t14 (x int);
        INSERT INTO t14 VALUES (1); $$;
（→ この関数はバージョン17.x以前だと実行できない）

§ § §

15. プランナで機能無効化の処理が改善されました。 (Robert Haas) (18)

enable_seqscanなど、実行プランで特定方式を有効/無効化する設定パラメータ群は、これまでは無効化する方式のプランノードに大きなコスト値(100億)を加算して、選択されないようにしていました。

本改善でコスト値を加えるのではなく無効であることを別途管理するようになりました。これにより巨大なコスト値が生じる実行プランでも無効化指定が確実に働きます。

インデックス

1. btreeインデックスのスキップスキャンに対応しました。 (Peter Geoghegan) (18)

スキップスキャンは、複数列のインデックスを範囲検索する際に、範囲全体のリーフページを走査するのではなく、不要な領域を飛ばして効率的に検索する手法です。

これにより、インデックスに含まれる最初の方の列に検索条件がなくて、以降の列に有用な検索条件がある場合に、インデックスが使われやすくなります。

§ §

2. パーティションキーやマテリアライズドビューの同時リフレッシュ用に、btree以外のアクセスメソッドのユニークインデックスが使用可能になりました。 (Mark Dilger) (18)

引続き、使用するインデックスタイプは等価性（「=」演算子）をサポートしていなければなりません。

§ §

3. GINインデックスの並列作成が可能になりました。 (Tomas Vondra, Matthias van de Meent) (18)

17.xまでは並列作成に対応していたのはbtreeとBRINインデックスのみでした。

§

4. GiSTおよびbtreeインデックスアクセスメソッドにソートサポート関数が追加されて、範囲型に対するインデックス作成が高速化されました。 (Bernd Helmle) (18)

特に範囲型へのGiSTインデックス作成で性能向上が期待できます。

§

性能一般

1. 非同期I/Oサブシステムが追加されました。 (Andres Freund, Thomas Munro, Nazir Bilal Yavuz, Melanie Plageman) (18)

これにより、バックエンドは複数の読み取り要求をキューにまとめて処理できるようになり、シーケンシャルスキャン、ビットマップヒープスキャン、バキューム処理などがより効率的に実行できます。この機能は新たな設定パラメータio_methodによりデフォルトで有効化されており、制御用にio_combine_limitおよびio_max_combine_limitが追加されました。

また、fadvise()システムコールをサポートしないシステムであってもeffective_io_concurrencyやmaintenance_io_concurrencyに0より大きい値を設定して効果を得ることができるようになりました。

新たなシステムビューpg_aiosから非同期I/Oに使用されているファイルハンドルの状況を確認できます。

§ § § § § § § § § § §

2. 多数のリレーションにアクセスするクエリのロック性能が改善されました。 (Tomas Vondra) (18)

PostgreSQLではテーブル等を参照するだけで最も弱いACCESS SHAREテーブルロックが発生します。このような弱いロックを簡易的に高速に行う仕組みがこれまでも用意されていましたが、1つのセッションにつき固定的に16個の要素（テーブルやインデックス）しか扱えませんでした。そのため、多数のテーブルにアクセスする問い合わせは、ロック処理が負担になっていました。典型的には大きなパーティションテーブルへの問い合わせが該当します。PostgreSQL 18 から、この上限数が固定的なものではなくなり、設定max_locks_per_transactionで与えられるようになりました。

§

3. ハッシュ結合とGROUP BYのパフォーマンスが向上され、メモリ使用量が削減されました。 (David Rowley, Jeff Davis) (18)

加えて、EXCEPT演算子でのハッシュセット処理や、サブプラン値のハッシュ検索もパフォーマンスが向上されました。

§ § § § §

4. 通常のVACUUMでもすべてが可視なページ上のタプルをFREEZEできるようなりました。 (Melanie Plageman) (18)

この変更により、 後続のテーブル全体へのFREEZEの作業を軽減できます。FREEZEの積極度は、設定パラメータvacuum_max_eager_freeze_failure_rateによって制御できます。この設定はサーバ全体またはテーブル単位で指定できます。

§ §

5. VACUUMコマンド実行時のファイルの末尾切り詰めを制御するサーバ変数vacuum_truncateが追加されました。 (Nathan Bossart, Gurjeet Singh) (18)

従来は同名のパラメータで切り詰めを行うかをストレージレベルでのみ制御可能でしたが、vacuum_truncateの設定でVACUUM実行時に切り詰めるか否かを指定できるようになりました。

§

6. effective_io_concurrencyとmaintenance_io_concurrencyのデフォルト値が16 に引き上げられました。 (Melanie Plageman) (18)

従来のデフォルト値では現代のハードウェアにおけるI/O並列性を十分に活かせませんでした。今回の変更により、クエリやメンテナンス作業が利用可能なI/O並列度をより効果的に活用できるようになりました。

§ §

モニタリング

1. サーバ変数log_connectionsのログの粒度を指定できるようになりました。 (Melanie Plageman) (18)

従来はboolean値で接続ログの有無のみを制御していましたが、今回の変更により、より詳細なログ出力の粒度を指定できるようになりました。従来のboolean値も引き続きサポートされます。

§

2. log_connectionsに接続段階の処理時間を報告するオプションが追加されました。 (Melanie Plageman) (18)

今回の変更により、log_connectionsに新しいオプションsetup_durationsが追加され、クライアント接続の各段階で要した時間をログ出力できるようになりました。接続処理の性能やタイミングを詳細に把握可能になりました。

§

3. log_line_prefixにクライアントが接続したサーバIPアドレスを出力できる%Lエスケープが追加されました。 (Greg Sabino Mullane) (18)

§

4. ロック取得失敗をログに出力するサーバ変数log_lock_failuresが追加されました。 (Yuki Seino, Fujii Masao) (18)

SELECT...NOWAITがロック取得に失敗した場合の情報をログに出力できるようになりました。これにより、ロック失敗の原因を把握しやすくなりました。

§ §

5. pg_stat_all_tablesにVACUUM/ANALYZEの実行時間を報告するカラムが追加されました。 (Sami Imseih) (18)

pg_stat_all_tablesおよびその派生ビューが修正され、手動および自動のVACUUMとANALYZEに費やされた時間を表示できるようになりました。

(追加されたカラムの一覧)

- total_vacuum_time
- total_autovacuum_time
- total_analyze_time
- total_autoanalyze_time

§

6. VACUUMとANALYZEに遅延時間を報告する機能が追加されました。 (Bertrand Drouvot, Nathan Bossart) (18)

この情報は、サーバログ、システムビューpg_stat_progress_vacuumおよびpg_stat_progress_analyze、VERBOSEモード時のVACUUMとANALYZEの出力にあらわれます。これを報告させるには設定パラメータtrack_cost_delay_timingを有効にします。

§ §

7. ANALYZE VERBOSEの出力にWAL、CPU使用、平均読み書きレート(MB/s)の統計が追加されました。 (Anthonin Bonnefoy) (18)

（出力例 - 特に追加された部分）
db1=# ANALYZE VERBOSE t32;
（中略）
INFO:  finished analyzing table "db1.public.t32"
avg read rate: 26.042 MB/s, avg write rate: 15.625 MB/s
buffer usage: 169 hits, 10 reads, 6 dirtied
WAL usage: 7 records, 5 full page images, 30023 bytes, 0 buffers full
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s

§ §

8. VACUUM/ANALYZE (VERBOSE)と自動バキュームのログ出力に、WALバッファがいっぱいになった回数も記録されるようになりました。 (Bertrand Drouvot) (18)

§

9. バックエンドごとのI/O統計のレポート機能が追加されました。 (Bertrand Drouvot) (18)

統計はpg_stat_get_backend_io()経由でアクセス可能です。バックエンドごとのI/O統計はpg_stat_reset_backend_stats()でクリア可能です。

§ §

10. pg_stat_ioビューにI/Oアクティビティをバイト単位で報告する列が追加されました。 (Nazir Bilal Yavuz) (18)

追加された列は read_bytes、write_bytes、extend_bytesです。常にBLCKSZに等しかったop_bytes列は削除されました。

§

11. pg_stat_ioビューの出力にWALのI/Oアクティビティについての行が追加されました。 (Nazir Bilal Yavuz, Bertrand Drouvot, Michael Paquier) (18)

これにはWAL receiverのアクティビティと、その書き込みに対する待機イベントも含まれます。

§ § §

12. 設定パラメータtrack_wal_io_timingで制御する、WAL I/O所要時間の追跡を参照できる場所がpg_stat_walビューからpg_stat_ioビューに変更されました。 (Bertrand Drouvot) (18)

§

13. pg_stat_walビューからwal_write、wal_sync、wal_write_time、wal_sync_time列が削除されました。 (Bertrand Drouvot) (18)

同じ情報はpg_stat_ioビューで参照できます。

§ §


14. バックエンドごとのWAL統計を返すpg_stat_get_backend_wal()関数が追加されました。 (Bertrand Drouvot) (18)

この統計はpg_stat_reset_backend_stats()関数でクリアできます。

§

15. PGDATA/pg_wal/summariesディレクトリの内容を具体的に一覧表示するpg_ls_summariesdir()関数が追加されました。 (Yushi Ogiwara) (18)

上記のPGDATAはデータベースクラスタディレクトリを意味します。

§

16. pg_stat_checkpointerビューに、実際に実行したチェックポイントの回数を示すnum_done列が追加されました。 (Anton A. Melnikov) (18)

既存のnum_timedおよびnum_requested列は、実際に実行したものだけでなくスキップされたチェックポイントもカウントしています。追加したnum_doneではスキップされたものはカウントせず、実行したチェックポイントのみカウントします。

§

17. pg_stat_checkpointerビューに、SLRUバッファの書き込み回数を示すslru_written列が追加されました。 (Nitin Jadhav) (18)

また、チェックポイント完了時に出力されるサーバログのメッセージも変更され、共有バッファとSLRUバッファの書き込み件数がそれぞれ個別に報告されるようになりました。なお、以前のpg_stat_checkpointerビューでは、チェックポイント完了時に出力されるサーバログとは異なる数のバッファ書き込みを出力することがありましたが、これはpg_stat_checkpointerビューはSLRUバッファの書き込みをカウントしていないためでした。

§

18. pg_stat_databaseビューに、並列クエリのワーカーの情報を示す列が追加されました。 (Benoit Lobreau) (18)

新たに追加された列は、起動する予定だった並列ワーカー数を示すparallel_workers_to_launchと、実際に起動された並列ワーカー数を示すparallel_workers_launchedです。

§

19. クエリIDの計算時、定数リスト内のすべての値ではなく、先頭と末尾の定数のみを考慮するようになりました。 (Dmitry Dolgov, Sami Imseih) (18)

クエリIDは例えば、pg_stat_statementsで利用されます。以前はリストの要素数が違うと異なるクエリIDが割り当てられていましたが、通常同じIDが割り当てられることが望ましいため、今回の変更が加わりました。

§ §

20. クエリIDの計算方法が調整され、同じリレーション名を使用するクエリは、スキーマが異なっても同一クエリのグループとして扱われるようになりました。 (Michael Paquier, Sami Imseih) (18)

異なるスキーマにある同名テーブルが異なる列を持つ場合であっても、クエリが同じであれば同一クエリのグループとして扱われます。

以前はクエリIDの計算にOID(オブジェクト識別子)を利用していましたが、これにより例えば同名のテーブルの作成と削除を繰り返して使用した場合にも、それらのテーブルに対する同じクエリにそれぞれ別のクエリIDが割り振られていました。これは通常ユーザが期待する動作ではなかったため、この調整が加わりました。

§

21. pg_backend_memory_contextsビューにtype列が追加されました。 (David Rowley) (18)

§

22. pg_backend_memory_contextsビューにpath列が追加されました。 (Melih Mutlu) (18)

これにより、メモリコンテキストの親子関係が正確に把握できるようになりました。

§

権限

1. データベースのアクセス権限の詳細を取得する関数pg_get_acl()が追加されました。 (Joel Jacobson) (18)

この関数は、カタログを参照せずに、データベースオブジェクトの権限を確認する際に有用です。

§ §

2. ラージオブジェクトの権限を確認する関数has_largeobject_privilege()が追加されました。 (Yugo Nagata) (18)

§

3. ALTER DEFAULT PRIVILEGES文でラージオブジェクトのデフォルト権限を設定できるようになりました。 (Takatsuka Haruka, Yugo Nagata, Laurenz Albe) (18)

これまでもGRANT文、REVOKE文で権限指定ができましたが、ラージオブジェクト1個ごとに行う必要がありました。

§

4. ロールpg_signal_autovacuum_workerが追加されました。 (Kirill Reshke) (18)

スーパーユーザー権限を持たないユーザーでも、このロールがあれば自動バキュームを実行するプロセスにシグナルを送信することができるようになりました。

§

サーバ設定

1. OAuth認証方式をサポートしました。 (Jacob Champion, Daniel Gustafsson, Thomas Munro) (18)

これにより、pg_hba.confにoauth認証方式、libpq APIのOAuthオプション、トークン検証ライブラリをロードするためのサーバ変数oauth_validator_libraries、そしてコンパイル時に必要なライブラリを追加するためのconfigureコマンドのフラグ--with-libcurl が追加されました。

§

2. サーバ変数ssl_tls13_ciphersを追加し、コロンで区切られた複数のTLSv1.3暗号スイートを指定できるようになりました。 (Erica Zhang, Daniel Gustafsson) (18)

§

3. サーバ変数ssl_groupsのデフォルトにCurve25519を含むように変更しました。 (Daniel Gustafsson, Jacob Champion) (18)

§

4. サーバ変数ssl_ecdh_curveの名前をssl_groupsに変更し、コロンで区切られた複数のECDH曲線を指定できるようになりました。 (Erica Zhang, Daniel Gustafsson) (18)

以前の変数名も引き続き機能します。

§

5. クエリのキャンセル要求を256ビットのキーで実行可能になりました。 (Heikki Linnakangas, Jelte Fennema-Nio) (18)

これによりブルートフォース攻撃が成功する可能性が低くなりました。256ビットのキーは、サーバとクライアントが、このリリースで導入された、ワイヤプロトコルバージョン3.2 をサポートしている場合にのみ可能です。それ以外の場合は、従来どおり4バイトのキーが利用されます。

§ §

6. サーバ変数autovacuum_worker_slotsが追加され、自動バキュームを実行するバックグラウンドプロセスの最大数を指定できるようになりました。 (Nathan Bossart) (18)

この変数が導入されたことで、autovacuum_max_workersをサーバを再起動せずに、この最大数まで変更できます。

§

7. 自動バキュームのトリガとなるデッドタプルの固定数を指定できるようになりました。 (Nathan Bossart, Frédéric Yhuel) (18)

サーバ変数はautovacuum_vacuum_max_thresholdです。autovacuum_vacuum_threshold、autovacuum_vacuum_scale_factorを利用した従来の閾値設定では、行数の多いテーブルのバキューム頻度が低くなる問題がありましたが、この変数により改善が見込めます。引き続きパーセンテージ指定もトリガに使用できます。

§

8. サーバ変数max_files_per_processがカウントする対象プロセスが変更され、バックエンドプロセスによって開かれたファイルのみを制限するようになりました。 (Andres Freund) (18)

以前は、postmasterによって開かれたファイルもこの制限にカウントされていました。

§

9. 必要なセマフォの数を報告するサーバ変数num_os_semaphoresが追加されました。 (Nathan Bossart) (18)

max_connectionsなどの設定値に基づいて必要なセマフォの数を計算します。これにより必要なOSの設定値を簡単に把握することが可能になりました。以前は、ドキュメントに記載の式を利用する必要がありましたが、新しくセマフォが必要なコンポーネントが追加された場合などにドキュメントの更新がされていない場合などがあり、ドキュメントに従っても必要数を正しく計算できないことがありました。

§

10. 新たな設定パラメータextension_control_pathが追加されました。これにより拡張のコントロールファイル(.control)を置くパスを複数指定できます。 (Peter Eisentraut, Matheus Alcantara) (18)

§ §

ストリーミングレプリケーションとリカバリ

1. 新たな設定パラメータidle_replication_slot_timeoutでアクティブでないレプリケーションスロットを自動的に無効化できるようになりました。 (Nisha Moond, Bharath Rupireddy) (18)

タイムアウトになったレプリケーションスロットは、pg_replication_slotビューでwal_statusが「lost」になってWALの保持が行なわれなくなり、invalidation_reasonに「idle_timeout」と理由が示されます。

§

2. 設定パラメータmax_active_replication_originsが追加されました。有効なレプリケーションオリジンの最大数を制御します。 (Euler Taveira) (18)

これまではmax_replication_slots設定で最大数が規定されていましたが、バージョン18からレプリケーションスロットの最大数とは別個に設定できるようになりました。

§

論理レプリケーション

1. 論理レプリケーションで生成列の値を送出できるようになりました。 (Shubham Khanna, Vignesh C, Zhijie Hou, Shlok Kyal, Peter Smith) (18)

パブリケーションで列リストが指定されている場合には指定すれば生成列もレプリケーションされます。列リストが指定されていない場合に生成列を含めるかどうかは、パブリケーションの新たなオプションpublish_generated_columnsの指定に従います。なお、これらに対応するのはSTORED生成列のみで、仮想生成列（VIRTUAL生成列）は対象外です。

これまでは、論理レプリケーションでパブリッシャ側からの生成列の送出はサポートされておらず、サブスクライバ側で元となる列から計算させる構成にする必要がありました。

§ § § §

2. CREATE SUBSCRIPTIONのstreamingオプションのデフォルトがoffからparallelに変更されました。 (Vignesh C) (18)

§

3. ALTER SUBSCRIPTIONがレプリケーションスロットの2相コミット動作を変更できるようになりました。 (Hayato Kuroda, Ajin Cherian, Amit Kapila, Zhijie Hou) (18)

これまではCREATE SUBSCRIPTIONでtwo_phaseオプションを指定できましたが、後からは変更できませんでした。

§ §

4. 論理レプリケーションの変更を適用するときのコンフリクトをログ記録するようになりました。 (Zhijie Hou, Nisha Moond) (18)

また、pg_stat_subscription_statsビューの新たな列でも種別ごとにコンフリクト発生回数が報告されるようになりました。「confl_insert_exists」など、コンフリクトの種類ごとに「confl_」で始まる列がいくつか追加されています。

§ § § § §

ユーティリティコマンド

1. 仮想生成列（VIRTUAL生成列）がサポートされました。こちらが生成列のデフォルトになります。 (Peter Eisentraut, Jian He, Richard Guo, Dean Rasheed) (18)

仮想生成列は、その列が読まれたときに値を計算して生成します。列の値がテーブルのデータとして書き込まれることはありません。生成した値を書き込む動作をさせるには「STORED」オプションを指定してください。

§ § §

2. DMLコマンドのRETURNING句で「OLD」と「NEW」がサポートされました。 (Dean Rasheed) (18)

これまではRETURNING句は、INSERTとUPDATEに対しては新たな値のみを、DELETEに対しては古い値のみを、MERGEに対しては処理内容に応じた値を返していました。

新たなRETURNING句では、特別な別名OLD、NEWを用いて明示的に新旧の値を返すようになりました。識別子の衝突を避けるため、OLD、NEWの別名を変更することもできます。

（例）
db1=# UPDATE t1 SET v = 'A' WHERE id <= 3 RETURNING WITH (OLD AS o, NEW AS n)
        o.id AS old_id, o.v AS old_v, n.id AS new_id, AS n.v new_v;
 old_id |              old_v               | new_id | new_v
--------+----------------------------------+--------+-------
      1 | c4ca4238a0b923820dcc509a6f75849b |      1 | A
      2 | c81e728d9d4c2f636f067f89cc14862c |      2 | A
      3 | eccbc87e4b5ce2fe28308fd9f2a7baf3 |      3 | A
(3 rows)

§

3. ローカルデータベース上の既存テーブルをLIKE句で指定して、外部テーブルを作成できるようになりました。 (Zhang Mingli) (18)

これまではCREATE FOREIGN TABLEにLIKE句は使用できませんでした。リモートデータベースにpublic.t1があり、同定義のテーブルpublic.t1がローカルデータベースにあるとき、以下のように外部テーブルを作成できます。

db2=# CREATE FOREIGN TABLE ft1 ( LIKE public.t1 )
        SERVER sv1_db1 OPTIONS ( table_name 't1', schema_name 'public');

§

4. 非決定論的（deterministic = false）な照合順序において、LIKE演算子が利用可能になりました。 (Peter Eisentraut) (18)

§

5. 非決定論的（deterministic = false）な照合順序において、テキスト位置検索関数が利用可能になりました。 (Peter Eisentraut) (18)

これまでは「ERROR: nondeterministic collations are not supported for ...」というエラーが出ていました。利用可能になった関数は以下の通りです。

position()
strpos()
replace()
split_part()
string_to_array()
string_to_table()

§

6. 組み込みの照合順序プロバイダにロケール「PG_UNICODE_FAST」が追加されました。 (Jeff Davis) (18)

このロケールに対応する照合順序「pg_unicode_fast」は、ASCII以外の大文字小文字マッピングをサポートする一方、ソートは自然言語の辞書順ではなくコードポイント順です。

（initdbでこれを指定するときの例）
$ initdb --locale-provider=builtin --builtin-locale=PG_UNICODE_FAST -E UTF8 -D $PGDATA

§

7. VACUUMとANALYZEがパーティションテーブルをパーティション（子テーブル）抜きに処理できるようになりました。 (Michael Harris) (18)

新たなオプションONLYを指定して、そのような動作にすることができます。autovacuumはパーティション（子テーブル）のみを処理対象とするため、パーティションテーブル（親テーブル）だけに追加でANALYZEを行いたい場合に便利です。

ONLYでパーティションテーブルのみの VACUUM を指定した場合、何もしないという動作になります。

§

8. リレーション毎、および、列毎にプランナ統計を変更する関数が追加されました。 (Corey Huinker) (18)

追加された関数は以下の通りです。これらはプランナ統計情報のダンプ・リストアで使われます。

pg_restore_relation_stats()
pg_restore_attribute_stats()
pg_clear_relation_stats()
pg_clear_attribute_stats()

§ § §

9. ファイルコピーの方法を指定する設定パラメータfile_copy_methodが追加されました。 (Nazir Bilal Yavuz) (18)

この設定値は「CREATE DATABASE ... STRATEGY=FILE_COPY」コマンドと、「ALTER DATABASE ... SET TABLESPACE ...」コマンドで、ファイルをコピーするときの動作に影響します。OSが対応していれば、デフォルトのCOPYに替えてCLONEを指定することで高速化が狙えます。

§

制約

1. 範囲型や多重範囲型の列に対して、重なりを持たないという条件を、主キー制約、ユニークキー制約、外部キー制約に指定できるようになりました。 (Paul A. Jungwirth) (18)

これは「PRIMARY KEY」と「UNIQUE」に対しては新たな「WITHOUT OVERLAPS」句で、外部キー制約に対しては新たな「PERIOD」句で、指定します。いずれも対象とできるのは制約の最後の列です。

（外部キー制約の例）
db1=# CREATE EXTENSION btree_gist;
db1=# CREATE TABLE t77m (cid int, age_r int4range, 
        PRIMARY KEY (cid, age_r WITHOUT OVERLAPS));
db1=# CREATE TABLE t77t (id int PRIMARY KEY, cid int, age_r int4range, 
        FOREIGN KEY (cid, PERIOD age_r) REFERENCES t77m (cid, PERIOD age_r));
db1=# INSERT INTO t77m VALUES (1, '[0,6)'), (2, '[6,12)'), (3, '[12,)');
db1=# INSERT INTO t77t VALUES (100, 3, '[12,)');  -- 範囲が一致している場合
db1=# INSERT INTO t77t VALUES (101, 2, '[9,11)'); -- 範囲内に収まっている場合
db1=# INSERT INTO t77t VALUES (102, 1, '[,10)');  -- 範囲をはみ出している場合
ERROR:  insert or update on table "t77t" violates foreign key constraint "t77t_cid_age_r_fkey"
DETAIL:  Key (cid, age_r)=(1, (,10)) is not present in table "t77m".

§ §

2. チェック制約と外部キー制約で「NOT ENFORCED」を指定できるようになりました。 (Amul Sul) (18)

対応して、システムテーブルpg_constraintにconenforced列が加わりました。「NOT ENFORCED」であると制約が働かない動作になります。

§ §

3. 主キーと外部キーの関係において、両方とも決定論的照合順序であるか、同一の非決定論的照合順序であることが必要になりました。 (Peter Eisentraut) (18)

非互換の変更点と言えます。pg_dumpによるダンプのリストア（これはpg_upgrade内でも使われます）は、この条件を満たさないと失敗します。対処にはデータベースの定義変更が必要となります。

§

4. 「NOT NULL」指定がシステムテーブルpg_constraintに格納されるようになりました。 (Alvaro Herrera, Bernd Helmle) (18)

これからはNOT NULL制約が制約名を持つようになります。加えて、外部テーブルにもNOT NULL制約を指定できるようになりました。さらに、NOT NULL制約を新たなオプション「NO INHERIT」により、継承子テーブルで継承しないように指定できるようになりました。

§

5. ALTER TABLEでNOT NULL制約をNOT VALIDで作成して、データの検査を先送りできるようになりました。 (Rushabh Lathia, Jian He) (18)

§

6. 継承親テーブルのNOT NULL制約が継承対象かどうかを指定できるようになりました。 (Suraj Kharage, Alvaro Herrera) (18)

構文は下記になります。

ALTER TABLE ... ALTER CONSTRAINT ... [NO] INHERIT

§ §

7. パーティションテーブルで外部キー制約をNOT VALIDで設定できるようになりました。 (Amul Sul) (18)

§

8. パーティションテーブルにALTER TABLE .. DROP CONSTRAINT ..で制約を除去するときに、ONLYを指定できるようになりました。 (Alvaro Herrera) (18)

（以下を実行すると、t84p1にはNOT NULL制約が残ります）
db1=# CREATE TABLE t84 (id int, c text NOT NULL) PARTITION BY RANGE (id);
db1=# CREATE TABLE t84p1 PARTITION OF t84 FOR VALUES FROM (1) TO (101);
db1=# ALTER TABLE ONLY t84 DROP CONSTRAINT "t84_c_not_null";

§

COPY

1. COPY FROMで「REJECT_LIMIT」を指定できるようになりました。これで許容できるエラーの最大数を指定できます。 (Atsushi Torikoshi) (18)

これは「ON_ERROR = 'ignore'」の場合に使用できます。

§

2. COPY TOでマテリアライズドビューからコピーできるようになりました。 (Jian He) (18)

§

3. COPY FROMの「LOG_VERBOSITY」オプションの値に「silent」が追加されました。 (Atsushi Torikoshi) (18)

「ON_ERROR = 'ignore'」のとき、この値が指定されていると、エラーとなった入力行数をログ出力しません。

§

4. 外部テーブルに対するCOPY FREEZEが使用できなくなりました。 (Nathan Bossart) (18)

これまではエラーにはなりませんが「FREEZE」指定は無視されていました。これからはエラーになります。

§

EXPLAIN

1. EXPLAINでANALYZEオプションを指定した場合、BUFFERSオプションも自動的に有効化されるようになりました。 (Guillaume Lelarge, David Rowley) (18)

§

2. EXPLAINのWALオプション指定時の出力内容に、WALバッファが一杯になった回数が追加されました。 (Bertrand Drouvot) (18)

（出力例）
db1=# CREATE TABLE t90 (c text);
db1=# EXPLAIN (ANALYZE, WAL, COSTS off, BUFFERS off, TIMING off)
        INSERT INTO t90 SELECT md5(g::text) FROM generate_series(1, 300000) g;
                                QUERY PLAN
--------------------------------------------------------------------------
 Insert on t90 (actual rows=0.00 loops=1)
   WAL: records=300000 bytes=26400000 buffers full=689
   ->  Function Scan on generate_series g (actual rows=300000.00 loops=1)
 Planning Time: 0.085 ms
 Execution Time: 1953.013 ms
(5 rows)

§

3. EXPLAIN ANALYZEで、各インデックススキャンノードのインデックス参照回数が表示されるようになりました。 (Peter Geoghegan) (18)

§

4. EXPLAINで行数が小数まで出力されるようになりました。 (Ibrar Ahmed, Ilia Evdokimov, Robert Haas) (18)

loopsを伴う場合、1回あたりの行数を出力しますので小数も必要でした。たとえば、4回の繰り返しで合計11行を取得したなら「(actual rows=2.75 loops=4)」と出力されます。これまでは「(actual rows=3 loops=4)」となっていました。

§ §

5. EXPLAIN ANALYZEがプランノード「Material」と「Window Aggregate」、共通テーブル式（WITH句）などについて、内部で使用するタプルストアのメモリ使用量やディスクに書き出しの有無を報告するようになりました。 (David Rowley, Tatsuo Ishii) (18)

§ § § §

6. EXPLAINがプランノード「WindowAgg」について、ウィンドウ定義の詳細を報告するようになりました。 (Tom Lane) (18)

（実行例 - Window:の行が本バージョンから追加された）
db1=# CREATE TABLE t94 (id int, score float4);
db1=# INSERT INTO t94 SELECT g, random() FROM generate_series(1, 100) g;
db1=# explain SELECT id, avg(score) OVER w1 FROM t94
        WINDOW w1 AS (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING);
                                         QUERY PLAN                             
--------------------------------------------------------------------------------------------
 WindowAgg  (cost=5.36..7.07 rows=100 width=12)
   Window: w1 AS (ORDER BY id ROWS BETWEEN '1'::bigint PRECEDING AND '1'::bigint FOLLOWING)
   ->  Sort  (cost=5.32..5.57 rows=100 width=8)
         Sort Key: id
         ->  Seq Scan on t94  (cost=0.00..2.00 rows=100 width=8)
(5 rows)

§

7. EXPLAIN ANALYZEがプランノード「Parallel Bitmap Heap Scan」について、パラレルワーカーのキャッシュ統計を報告するようになりました。 (David Geier, Heikki Linnakangas, Donghang Lin, Alena Rybakina, David Rowley) (18)

（出力例 - 各ワーカーで「exact」と「lossy」のページ数が報告される)
db1=# explain (analyze, buffers off, costs off, timing off) 
        SELECT id FROM t95 WHERE c1 <= 2 AND c2 <= 2 AND c3 <= 2;
                                 QUERY PLAN
-----------------------------------------------------------------------------
 Gather (actual rows=11107.00 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Bitmap Heap Scan on t95 (actual rows=3702.33 loops=3)
         Recheck Cond: (c3 <= 2)
         Rows Removed by Index Recheck: 235532
         Filter: ((c1 <= 2) AND (c2 <= 2))
         Rows Removed by Filter: 55121
         Heap Blocks: exact=381 lossy=1707
         Worker 0:  Heap Blocks: exact=203 lossy=1830
         Worker 1:  Heap Blocks: exact=184 lossy=1101
         ->  Bitmap Index Scan on t95_c3_idx (actual rows=176471.00 loops=1)
               Index Cond: (c3 <= 2)
               Index Searches: 1
 Planning Time: 0.339 ms
 Execution Time: 155.347 ms
(16 rows)

§

8. EXPLAIN ANALYZEで無効にされたプランノードタイプが出力されるようになりました。 (Robert Haas, David Rowley, Laurenz Albe) (18)

以下のように設定で無効化されたプランノードタイプが、他に手段がないために選択された場合に「Disabled: true」が出力されます。

db1=# CREATE TABLE t96 (id int);
db1=# SET enable_seqscan TO off;
db1=# explain SELECT id FROM t96;
                      QUERY PLAN
-------------------------------------------------------
 Seq Scan on t96  (cost=0.00..35.50 rows=2550 width=4)
   Disabled: true
(2 rows)

§ § §

データ型

1. Unicodeの完全な大文字小文字のマッピングと変換がサポートされました。 (Jeff Davis) (18)

タイトルケースやその他の条件に応じたマッピング（文字の出現位置による違い）、単一文字から複数文字へマッピングへの対応が加わりました。

§ §

2. jsonbの「null」値を「NULL」としてスカラー型にキャストできるようになりました。 (Tom Lane) (18)

これまではエラーになりました。

（バージョン18の動作例）
db1=# SELECT 'null'::jsonb::int;
 int4
------

(1 row)

（バージョン17.xまでは以下のエラーになる）
ERROR:  cannot cast jsonb null to type integer

§

3. json_strip_nulls()およびjsonb_strip_nulls()関数に、配列内のnull要素も削除できるオプションパラメータが追加されました。 (Florents Tselai) (18)

§

4. 配列を最初の次元でソートする関数array_sort()が追加されました。 (Junwang Zhao, Jian He) (18)

（使用例）
db1=# SELECT array_sort('{{2,3,5},{1,2,3},{2,3,4},{1,10,5}}'::int[]);
             array_sort
------------------------------------
 {{1,2,3},{1,10,5},{2,3,4},{2,3,5}}
(1 row)

§

5. 配列の第1次元を反転する関数array_reverse()が追加されました。 (Aleksander Alekseev) (18)

(実行例)
db1=# SELECT array_reverse(ARRAY[[1,2],[3,4],[5,6]]);
    array_reverse
---------------------
 {{5,6},{3,4},{1,2}}
(1 row)

§

6. bytea型のバイト列を反転する関数reverse()が追加されました。 (Aleksander Alekseev) (18)

バイト列の順序を反転することで、ビッグエンディアンとリトルエンディアン変換を行うケースなどで役立ちます。

(実行例)
db1=# SELECT reverse('\xA1B2C3'::bytea);
 reverse
----------
 \xc3b2a1
(1 row)

§

7. 整数型とbytea型の間でのキャストを許可するようになりました。 (Aleksander Alekseev) (18)

整数値は2の補数表現のbytea値として保存されます。

(実行例)
db1=#  SELECT 1234::bytea;
   bytea
------------
 \x000004d2
(1 row)

db1=# SELECT '\x000004d2'::bytea::int4;
 int4
------
 1234
(1 row)

§

8. UnicodeデータのバージョンがUnicode 16.0.0に更新されました。 (Peter Eisentraut) (18)

§

9. エストニア語の全文検索におけるステミング機能が追加されました。 (Tom Lane) (18)

§

10. XMLのエラーコードがSQL標準により近づくよう改善されました。 (Tom Lane) (18)

これらのエラーはSQLSTATEを通じて報告されます。

§

関数

1. casefold()関数が追加され、より高度な大文字/小文字を区別しない照合が可能になりました。 (Jeff Davis) (18)

これにより、1文字が複数の大文字/小文字に対応する場合や、変換によって文字数が変わる場合でも、より正確な比較ができるようになりました。

§

2. 配列型や複合型に対しても、MIN()/MAX()集約関数を使用できるようになりました。 (Aleksander Alekseev, Marat Buharov) (18)

§ §

3. EXTRACT()関数にWEEKオプションが追加されました。 (Tom Lane) (18)

(実行例)
db1=# SELECT EXTRACT(WEEK FROM interval '2 weeks'),
EXTRACT(WEEK FROM interval '-15 days'),
EXTRACT(WEEK FROM date '2025-1-27');
 extract | extract | extract
---------+---------+---------
       2 |      -2 |       5
(1 row)

§

4. 負の値に対するEXTRACT(QUARTER ...)の出力が改善されました。 (Tom Lane) (18)

以前からQUARTERオプションはintervalでも使えていましたが、負のintervalに対しては奇妙な結果を返していました。

(実行例)
db1=# SELECT EXTRACT(QUARTER FROM interval '10 months'),
EXTRACT(QUARTER FROM interval '-10 months');
 extract | extract
---------+---------
       4 |      -4
(1 row)
(PG17以前だと奇妙な結果が返ってくる)
db1=# SELECT EXTRACT(QUARTER FROM INTERVAL '10 months'),
EXTRACT(QUARTER FROM INTERVAL '-10 months');
 extract | extract
---------+---------
       4 |      -2
(1 row)

§

5. 関数to_number()でローマ数字がサポートされました。 (Hunaid Sohail) (18)

（使用例）
db1=# SELECT to_number('XVIII', 'RN');
 to_number
-----------
        18
(1 row)

§

6. UUIDバージョン7を生成する関数uuidv7()が追加されました。 (Andrey Borodin) (18)

このUUID値は時間的にソート可能で、生成順の並びになります。

また、UUIDバージョン4を生成する関数gen_random_uuid()の別名として、関数uuidv4()も追加されました。

§

7. CRC（巡回冗長検査）の値を計算する関数crc32()、crc32c()が追加されました。 (Aleksander Alekseev) (18)

§

8. 算術関数としてガンマ関数gamma()、対数ガンマ関数lgamma()が追加されました。 (Dean Rasheed) (18)

§

9. PL/pgSQLで、名前付きカーソル引数に「=>」構文が使用可能となりました。 (Pavel Stehule) (18)

これまでは「:=」のみが使用可能でした。

「OPEN cur1 (p1 => 'A', p2 => 123);」や「FOR rec IN cur2(a1 => 't') LOOP」などと記述できます。

§

10. 正規表現関数で名前付き引数が使用可能になりました。 (Jian He) (18)

対象は以下の関数です。

regexp_match()
regexp_matches()
regexp_like()
regexp_replace()
regexp_count()
regexp_instr()
regexp_substr()
regexp_split_to_table()
regexp_split_to_array()

以下のように使用できます。

db1=# SELECT regexp_replace(string=>'hello world', pattern=>'o', replacement=>'0', flags=>'g');
 regexp_replace
----------------
 hell0 w0rld
(1 row)

§

libpq

1. マイナーバージョンを含む完全なプロトコルバージョン番号を報告する関数PQfullProtocolVersion()が追加されました。 (Jacob Champion, Jelte Fennema-Nio) (18)

§

2. 接続で使用するプロトコルバージョンの範囲を指定する、libpqの接続パラメータと環境変数が追加されました。 (Jelte Fennema-Nio) (18)

追加されたパラメータはmin_protocol_versionとmax_protocol_version、環境変数はPGMINPROTOCOLVERSIONとPGMAXPROTOCOLVERSIONです。

§ §

3. search_pathの変更をクライアントに報告するようになりました。 (Alexander Kukushkin, Jelte Fennema-Nio, Tomas Vondra) (18)

§ §

4. PQtrace()で認証処理を含む全てのメッセージタイプを出力するようになりました。 (Jelte Fennema-Nio) (18)

§ § § § §

5. SSL鍵についてのログを出力させる、libpq接続パラメータsslkeylogfileが追加されました。 (Abhishek Chanda, Daniel Gustafsson) (18)

§

6. いくつかのlibpq関数をシグネチャにint64_tを使うように修正しました。 (Thomas Munro) (18)

これらは非推奨となっているpg_int64を使っていました。

§

psql

1. psqlで名前付きプリペアドステートメントのパース、バインド、クローズができるようになりました。 (Anthonin Bonnefoy, Michael Paquier) (18)

新たなメタコマンド「\parse」「\bind_named」「\close_prepared」でこれを行うことができます。

（実行例)
db1=# SELECT $1 + 1, $2 || 'X'  \parse ps1

db1=# \bind_named ps1 100 'ABC'  \g
 ?column? | ?column?
----------+----------
      101 | ABCX
(1 row)

db1=# \close_prepared ps1

§

2. psql のメタコマンド（バックスラッシュコマンド）でパイプライン問合せの発行が可能になりました。 (Anthonin Bonnefoy) (18)

そのために以下のメタコマンドが追加されました。

\startpipeline
\syncpipeline
\sendpipeline
\endpipeline
\flushrequest
\flush
\getresults

§ § §

3. パイプライン状態をpsqlのプロンプトに付加できるようになりました。また、新たな変数で状態を確認できるようになりました。 (Anthonin Bonnefoy) (18)

新たなプロンプト文字は「%P」で、新たなpsql変数は「PIPELINE_SYNC_COUNT」、「PIPELINE_COMMAND_COUNT」、「PIPELINE_RESULT_COUNT」です。

§

4. 接続サービス名をpsqlプロンプトに付加できるようになり、また、psql変数から参照可能になりました。 (Michael Banck) (18)

新たなプロンプト文字は「%s」で、新たなpsql変数は「SERVICE」です。

§

5. psqlの一覧出力する全てのメタコマンドに、拡張表示モードを使うようにするオプション「x」が追加されました。 (Dean Rasheed) (18)

以下のように使用します。

db1=# \du
                             List of roles
 Role name |                         Attributes
-----------+------------------------------------------------------------
 foo       |
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS

db1=# \dux
List of roles
-[ RECORD 1 ]----------------------------------------------------------
Role name  | foo
Attributes |
-[ RECORD 2 ]----------------------------------------------------------
Role name  | postgres
Attributes | Superuser, Create role, Create DB, Replication, Bypass RLS

ただし、「\dx」は「インストールされている拡張一覧」の意味になるため、「\d」には付加できません。

§

6. psqlのメタコマンド\conninfoの出力が、1行の文字列ではなく表形式になり、より多くの情報を含むようになりました。 (Alvaro Herrera, Maiquel Grassi, Hunaid Sohail) (18)

db1=# \conninfo
     Connection Information
      Parameter       |  Value
----------------------+----------
 Database             | db1
 Client User          | postgres
 Socket Directory     | /tmp
 Server Port          | 5432
 Options              |
 Protocol Version     | 3.0
 Password Used        | false
 GSSAPI Authenticated | false
 Backend PID          | 340367
 SSL Connection       | false
 Superuser            | on
 Hot Standby          | off
(12 rows)

§

7. psqlのメタコマンド\df+、\do+、\dAo+、\dC+で関数のLEAKPROOF属性を出力に含めるようになりました。 (Yugo Nagata) (18)

§

8. psqlのメタコマンド「\dP+」で、パーティションテーブルの詳細情報としてアクセスメソッドを出力するようになりました。 (Justin Pryzby) (18)

§

9. psqlの拡張機能の一覧を出力するメタコマンドである\dxの出力にdefault_version列が追加されました。 (Magnus Hagander) (18)

§

10. \watchのデフォルトの待機時間を設定するためのpsql変数WATCH_INTERVALが追加されました。 (Daniel Gustafsson) (18)

§

サーバアプリケーション

1. initdbの動作が変更され、デフォルトでデータチェックサムが有効化されるようになりました。 (Greg Sabino Mullane) (18)

新たに追加されたオプション--no-data-checksumsを指定することで、チェックサムを無効にすることができます。

§ §

2. initdbに新たなオプション--no-sync-data-filesが追加され、ヒープファイルやインデックスファイルの同期（sync）を行わないようにすることが可能になりました。 (Nathan Bossart) (18)

このオプションは、同期をinitdbとは別の処理で実施するPostgreSQLのツールの内部で利用することを想定して追加されています。従来の--no-syncオプションも引き続き使用可能で、こちらはすべてのファイルの同期を行わないようにします。

§

3. vacuumdbにオプション--missing-stats-onlyが追加され、統計情報のうち、まだ収集されていないものだけを収集することが可能になりました。 (Corey Huinker, Nathan Bossart) (18)

このオプションはスーパーユーザーのみが実行でき、--analyze-onlyまたは--analyze-in-stagesオプションと併せて使用する必要があります。主にpg_upgrade実行後に不足している統計情報を補完する用途を想定して導入されました。

§ §

4. pg_combinebackupにオプション-k/--linkが追加され、ハードリンクを有効にすることが可能になりました。 (Israel Barth Rubio, Robert Haas) (18)

ただし、ハードリンクできるのは一部のファイルに限られており、生成されたバックアップをそれぞれ独立して使用する予定がある場合には、このオプションの使用は推奨されません。

このオプションは、入力ディレクトリが復元後に削除される一時的なステージング領域である場合に特に有効で、ファイルのコピーを省略して高速化が図れます。しかし、ハードリンクにより出力先の変更が入力ディレクトリにも影響するため、入力ディレクトリを再利用する可能性がある場合は危険であり、使用時には警告が表示されます。

§

5. pg_verifybackupにtarフォーマットのバックアップを検証できる機能が追加されました。 (Amul Sul) (18)

この機能は圧縮されたtarフォーマットのバックアップにも対応しています。ただし、WALの検証にはpg_waldumpを使用している関係で、WALがtarファイル内に格納されている場合はまだ検証できません。そのため、WALの検証をスキップする-nオプションを必ず指定する必要があります。

§

6. pg_rewindの--source-serverオプションでデータベース名が指定されている場合、そのデータベース名が--write-recovery-confの出力に使用されるようになりました。 (Masahiko Sawada) (18)

これにより、sync_replication_slotsが有効な環境でも、リワインド後のサーバが手動で設定ファイルを修正することなくプライマリサーバへ接続できるようになります。

§

7. pg_resetwalにオプション--char-signednessが追加され、デフォルトのcharの符号性を変更できるようになりました。 (Masahiko Sawada) (18)

このオプションは、pg_upgrade内部での利用を想定しており、手動での操作は想定していません。

§

pg_dump

1. pg_dumpに統計情報をダンプするための--statisticsオプションが追加されました。 (Jeff Davis) (18)

§ §

2. pg_dump、pg_dumpallにオプション--sequence-dataが追加されました。--no-dataなどシーケンスデータを除外するオプションが指定されている場合でも、シーケンスデータをダンプできます。 (Nathan Bossart) (18)

§ §

3. pg_dump、pg_dumpall、pg_restoreにオプション--statistics-only、--no-statistics、--no-data、--no-schemaが追加されました。 (Corey Huinker, Jeff Davis) (18)

§

4. pg_dump、pg_dumpall、pg_restoreにオプション--no-policiesが追加されました。このオプションで行レベルのセキュリティポリシー処理を無効にします。 (Nikolay Samokhvalov) (18)

これは異なるポリシーを持つシステムに移行する場合に便利です。

§

pg_upgrade

1. pg_upgrade でメジャーバージョンアップする際にプランナ統計情報を移行できるようになりました。ただし、拡張統計情報は移行されません。 (Corey Huinker, Jeff Davis, Nathan Bossart) (18)

統計情報を移行しない場合は、--no-statistics オプションを指定します。

§ § § §

2. pg_upgradeの--jobsオプションで並列実行数を指定することで、複数のデータベースを同時に処理できるようになりました。 (Nathan Bossart) (18)

§ § § § § § § § § § §

3. pg_upgradeにオプション--swapが追加されました。 (Nathan Bossart) (18)

このオプションでディレクトリ全体を入れ替えるので、大量にDB オブジェクトがある環境では従来の--copyや--link、--cloneオプションを使うよりも高速になることがあります。

§

4. pg_upgradeにオプション--set-char-signednessが追加されました。このオプションで新しいクラスタのデフォルトのchar型の符号つき/符号なし(signed/unsigned)を設定できます。 (Masahiko Sawada) (18)

これはPostgreSQL 18より前のクラスタのデフォルトのCPU符号が新しいクラスタと一致しない場合に対応できます。

§ §

論理レプリケーション

1. pg_createsubscriberにオプション--allが追加されました。このオプションで全てのデータベースの論理レプリカが作成されます。 (Shubham Khanna) (18)

§

2. pg_createsubscriberにオプション--cleanが追加されました。このオプションで現在はパブリケーションのみが削除できます。 (Shubham Khanna) (18)

§

3. pg_createsubscriberにオプション--enable-two-phaseが追加されました。このオプションでサブスクリプションの二相コミットを有効にします。 (Shubham Khanna) (18)

§

4. pg_recvlogicalに--enable-failoverオプションが追加され、フェイルオーバースロットを指定できるようになりました。 (Hayato Kuroda) (18)

これにより、pg_recvlogicalがフェイルオーバーオプションを有効にした状態で論理レプリケーションスロットを作成できるようになりました。本オプションは--create-slotオプションと一緒に使用します。

また、--two-phaseの同義語として--enable-two-phaseオプションが追加され、--two-phaseは非推奨となりました。

§

5. pg_recvlogicalの--drop-slotオプションが、--dbnameを指定しなくても動作するようになりました。 (Hayato Kuroda) (18)

§

ソースコード

1. インジェクションポイントの読み込みと実行が分離されました。 (Michael Paquier, Heikki Linnakangas) (18)

INJECTION_POINT_LOAD()マクロで、インジェクションポイントを作成するけれど実行しない、ということができるようになりました。作成したインジェクションポイントはINJECTION_POINT_CACHED()マクロで実行できます。

この分離は、メモリ割り当て不能なクリティカルセクションにインジェクションポイントを付加するときに有用です。

§ §

2. インジェクションポイントで実行時引数がサポートされました。 (Michael Paquier) (18)

§

3. IS_INJECTION_POINT_ATTACHED()マクロが追加されました。 (Heikki Linnakangas) (18)

これにより、通常のソースコード内でインジェクションポイントがアタッチされているかを検査するコードが書けます。

§

4. SIMD(Single Instruction Multiple Data)を使用することで、長いJSON文字列の処理性能が向上しました。 (David Rowley) (18)

特に、長いテキストプロパティを持つJSONオブジェクトで効果的です。

§

5. x86のAVX-512命令を使用することで、CRC32C計算が高速化されました。 (Raghuveer Devulapalli, Paul Amonson) (18)

§

6. popcount（整数のビットカウント）に対して、ARMのNeonおよびSVE CPU命令が追加されました。 (Chiranmoy Bhattacharya, Devanga Susmitha, Rama Malladi) (18)

§ §

7. numeric型の乗算および除算の処理速度が向上しました。 (Joel Jacobson, Dean Rasheed) (18)

§ § § §

8. configureオプションにNUMA対応を有効にする--with-libnumaが追加されました。 (Jakub Wartak, Bertrand Drouvot) (18)

NUMA対応状況は関数pg_numa_available()で確認できます。NUMA対応が有効である場合、システムビューpg_shmem_allocations_numaとpg_buffercache_numaで共有メモリのNUMAノード間での分布状況を確認できます。

§ § §

9. 非常に大きな式インデックスを可能にするために、システムテーブルpg_indexにTOASTテーブルが追加されました。 (Nathan Bossart) (18)

§

10. システムテーブルpg_attributeから、attcacheoff列が削除されました。 (David Rowley) (18)

§

11. システムテーブルpg_classから、relallfrozen列が追加されました。 (Melanie Plageman) (18)

§

12. インデックスアクセスメソッドのAPIルーチンに、amgettreeheight、amconsistentequality、amconsistentorderingが追加されました。 (Mark Dilger) (18)

amgettreeheightが新規追加で、amconsistentequalityとamconsistentorderingはamcancrosscompareを分割改名したものです。

§ §

13. GiSTのサポート関数stratnum()が追加されました。 (Paul A. Jungwirth) (18)

§

14. ビルドにおける「char」のデフォルトのCPU符号属性(signedかunsigned)が、コントロールデータに記録され、pg_controldataコマンドで出力されるようになりました。 (Masahiko Sawada) (18)

§

15. plpythonでPythonの「Limited API」のサポートが追加されました。 (Peter Eisentraut) (18)

Python 3.x のバージョン不一致によって発生する問題の防止に役立ちます。

§ §

16. サポートされるPythonの最小バージョンが3.6.8に変更されました。 (Jacob Champion) (18)

§

17. OpenSSL 1.1.1より古いバージョンがサポートされなくなりました。 (Daniel Gustafsson) (18)

§ §

18. LLVMを有効するために、LLVMバージョン14以降が必要となりました。 (Thomas Munro) (18)

§

19. 拡張が自分自身の名前とバージョンを報告できるように、PG_MODULE_MAGIC_EXTマクロが追加されました。 (Andrei Lepikhov) (18)

この情報は新たなpg_get_loaded_modules()関数を介して参照できます。

§

20. SPI_connect()/SPI_connect_ext()は常に成功（SPI_OK_CONNECT）を返すことが、文書化されました。 (Stepan Neretin) (18)

エラーは常にereport()を介して報告されます。

§

21. APIおよびABI互換性に関するドキュメントのセクションが追加されました。 (David Wheeler, Peter Eisentraut) (18)

§

22. ドキュメントでWindows上のMesonビルドが実験的という扱いではなくなりました。 (Aleksander Alekseev) (18)

§

23. configureオプションの「--disable-spinlocks」と「--disable-atomics」が削除されました。 (Thomas Munro) (18)

32ビットのアトミック操作は必須となりました。

§ §

24. HPPA/PA-RISCアーキテクチャのサポートが削除されました。 (Tom Lane) (18)

§

追加モジュール

1. 論理スナップショットを検査するpg_logicalinspect拡張が追加されました。 (Bertrand Drouvot) (18)

論理レプリケーション等で使われる$PGDATA/pg_logical/snapshots/以下の.snapファイルについて、情報を得る関数が提供されます。

§

2. EXPLAIN出力に詳細デバッグ情報等を追加するpg_overexplain拡張が追加されました。 (Robert Haas) (18)

§

3. postgres_fdwでpostgres_fdw_get_connections()関数の出力列が追加されました。 (Hayato Kuroda, Sagar Dilip Shedge) (18)

新しい出力列は以下の4つです。

used_in_xact       現在のトランザクションで使用されているか
closed             接続が閉じられているか
user_name          ユーザ名
remote_backend_pid リモートのバックエンドプロセスのPID

§ § § §

4. クライアントからのSCRAM認証をpostgres-fdwサーバに渡せるようになりました。 (Matheus Alcantara, Peter Eisentraut) (18)

これにより、postgres_fdwの認証情報をデータベースに格納しなくて済みます。これはuse_scram_passthrough接続オプションで有効になります。このとき、libpqで新しい接続パラメータlibpq_connect_scram_client_keyおよびlibpq_connect_scram_server_keyが使用されます。

§

5. クライアントからのSCRAM認証をdblinkに渡せるようになりました。 (Matheus Alcantara) (18)

§

6. file_fdwにon_errorオプションとlog_verbosityオプションが追加されました。 (Atsushi Torikoshi) (18)

on_errorオプションにignoreを指定することで入力ファイルの不正な行をスキップしてクエリを実行可能になりました。またlog_verbosityオプションでエラーや警告のログ出力の詳細度を指定できるようになりました。いずれのオプションも外部テーブルに対するSELECT、ANALYZE操作に適用されます。

§

7. file_fdwがスキップできるエラー行の上限数を制御するREJECT_LIMITオプションが追加されました。 (Atsushi Torikoshi) (18)

このオプションはon_errorオプションがignoreの時のみ有効になります。

§

8. passwordcheckモジュールにパスワードの最小の長さを指定できるmin_password_lengthパラメータが追加されました。 (Emanuele Musella, Maurizio Boriani) (18)

ユーザーが事前に暗号化されたパスワードを入力した場合は、このパラメータは無効となります。

§

9. pgbenchの結果出力で、失敗・試行・スキップしたトランザクションも報告するようになりました。 (Yugo Nagata) (18)

§

10. isn拡張に無効な検査数字の受け入れを制御するサーバ変数weakが追加されました。 (Viktor Holmberg) (18)

以前のweakは静的変数で、関数isn_weak()でのみ制御されていました。weakをGUCパラメータとしたことで、トランザクション単位での変更やRESET文でデフォルト値に戻すことが可能になりました。

§

11. btree_gist拡張のソートサポートが有効になり、Gistインデックスの構築が高速に行えるようになりました。 (Bernd Helmle, Andrey Borodin) (18)

§

12. amcheckモジュールにGINインデックスの整合性を検証する関数gin_index_check()が追加され、親子関係の一貫性と木構造のバランスをチェックできるようになりました。 (Grigory Kryachko, Heikki Linnakangas, Andrey Borodin) (18)

§

13. 未固定の共有バッファを追い出す関数pg_buffercache_evict_relation()と関数pg_buffercache_evict_all()が追加されました。 (Nazir Bilal Yavuz) (18)

関数pg_buffercache_evict_relation()は指定したリレーションの共有バッファをすべて追い出し、関数pg_buffercache_evict_all()は全共有バッファを一括で追い出すことができます。既存の関数pg_buffercache_evict()は、バッファがフラッシュされたかどうかの状態を返すようになりました。

§

14. 拡張モジュールが独自のEXPLAINオプションを登録・管理できるようにする機能が追加されました。 (Robert Haas, Sami Imseih) (18)

§ § §

15. 拡張機能がサーバの累積統計情報APIを利用できるようになりました。 (Michael Paquier) (18)

§ §

pg_stat_statements

1. pg_stat_statementsでCREATE TABLE ASおよびDECLAREを追跡できるようになりました。 (Anthonin Bonnefoy) (18)

これらの問合せに対してクエリIDが割り当てられるようになります。

§

2. pg_stat_statementsでSET文の値のパラメータ化が可能になりました。 (Greg Sabino Mullane, Michael Paquier) (18)

これまで指定値が異なるだけで別エントリになっていたものを集約できるため、データ量の膨張を減らします。

(実行例)
db1=# set enable_seqscan=false;
db1=# set enable_seqscan=true;
db1=# SELECT query, calls, rows FROM pg_stat_statements;
                       query                       | calls | rows
---------------------------------------------------+-------+------
 set enable_seqscan=$1                             |     2 |    0

(17.xでは以下)
db1=# SELECT query, calls, rows FROM pg_stat_statements;
                       query                       | calls | rows
---------------------------------------------------+-------+------
 set enable_seqscan=false                          |     1 |    0
 set enable_seqscan=true                           |     1 |    0

§

3. pg_stat_statementsに並列処理の動作を報告する列が追加されました。 (Guillaume Lelarge) (18)

追加された列は以下です。

  parallel_workers_to_launch : 実行計画のパラレルワーカー数
  parallel_workers_launched  : 実際に起動されたワーカー数

§

4. pg_stat_statementsにWALバッファが満杯になった回数を報告するwal_buffers_full列が追加されました。 (Bertrand Drouvot) (18)

§

pgcrypto

1. pgcryptoにハッシュアルゴリズムsha256cryptおよびsha512cryptが追加されました。 (Bernd Helmle) (18)

§

2. pgcryptoのAES暗号化/復号化にCFB(Cipher Feedback)モードが追加されました。 (Umar Hayat) (18)

暗号タイプに'aes-cfb'と指定して使用できます。

§

3. サーバのFIPSモードを報告する関数fips_mode()が追加されました。 (Daniel Gustafsson) (18)

FIPSモードとは米国の連邦情報処理標準に準拠した暗号化方式のみを使用する構成です。本関数はPostgreSQLから使用されているOpenSSLがFIPSモードであるかを返します。

§

4. pgcryptoに設定パラメータpgcrypto.builtin_crypto_enabledが追加され、組み込みの非FIPSモードの暗号化関数を無効化できるようになりました。 (Daniel Gustafsson, Joe Conway) (18)

これはFIPSモードの動作を保証するために役立ちます。

§

内部的には複数のデーモンプロセスがそれぞれ役割を担い、連携しながら動作しています。本記事では、Pacemaker/Corosync のプロセス構成とプロセス間のデータ処理の流れ、さらに状態遷移の仕組みについて解説します。

※バージョンによって挙動が異なる場合があるため、本記事では Pacemaker 2.1 を前提としています。

Pacemaker/Corosync のプロセス構成

Pacemaker の内部では、複数のデーモンプロセスが役割を分担し、クラスタ全体の監視、制御、リソース管理を行います。一方、Corosync はクラスタを構成するノード間の通信や死活監視、クォーラム管理を担当するプロセスです。両者が連携することで、障害が発生した場合でもサービスを継続できる、高可用性クラスタを実現できます。

主要なプロセスの役割は以下のとおりです。

pacemakerd

Pacemaker クラスタ全体の管理を担う親デーモンであり、以下の各サブデーモンプロセスの起動・監視を行い、異常時は再起動します。

pacemaker-based

クラスタの設定や状態情報を保持する CIB (Cluster Information Base、詳細は後述) を管理するプロセスです。CIB は XML 形式で構造化されており、クラスタ設定やリソースの構成、ノードの状態などが記録されています。pacemaker-based は CIB の読み書きを行い、常に最新の情報を反映させるとともに、複数ノード間で内容が一致するよう同期処理を行い、クラスタ全体の一貫性を維持します。

pacemaker-attrd

クラスタノードやリソースに関する動的属性情報 (稼働状況、フェイルカウントなど) を管理するプロセスです。pacemaker-attrd は各ノードから収集した属性情報を保持し、必要に応じてクラスタ全体に伝達します。

pacemaker-schedulerd

CIB の情報をもとに、どのノードでどのリソースを動かすかを決定するプロセスです。フェイルオーバー時のリソース配置計画もここで決定されます。

pacemaker-controld

Pacemaker クラスタにおける「調整役」を担うプロセスです。このプロセスは pacemaker-schedulerd が決定した計画に基づき、各ノード上の pacemaker-execd に対してリソースの起動、停止、監視を指示します。

pacemaker-execd

ローカルノード上でリソースエージェントの起動、停止、監視を実行するプロセスです。操作結果は pacemaker-controld に報告され、クラスタ全体の判断材料として利用されます。

pacemaker-fenced

障害を起こしたノードを強制的にリブートまたはシャットダウンするフェンシングを担当するプロセスです。データ破壊や二重書き込みなどの重大な障害を防ぐため、STONITH デバイスを操作して信頼できないノードをクラスタから隔離します。

なお、Pacemaker 2.0 系ではプロセス名が変更されました。ただし、機能自体は従来と同じです。旧プロセス名との対応関係を以下の表に示します。

CIB (Cluster Information Base) とは

Pacemaker では、各プロセスが CIB を中心に情報を共有・同期することで、クラスタ全体の一貫性を保っています。

CIB は XML 形式で管理されるクラスタ情報のデータベースであり、クラスタの構成や各リソースの状態を記録します。CIB には、クラスタの状態変化に応じてリアルタイムで更新される動的な情報が保持されており、クラスタ全体の整合性を維持するうえで重要な役割を担っています。各ノード上の pacemaker-based プロセスが CIB を管理し、更新や同期を行うことで、pacemaker-schedulerd は常に最新の情報に基づいてリソースの配置やフェイルオーバーの判断を行うことができます。

CIB の構造は主に以下のセクションで構成されています。

<cib crm_feature_set="3.19.6" ...>
  <configuration>
    <!-- クラスタ設定（リソース定義、制約、ノード設定など） -->
  </configuration>
  <status>
    <!-- 実行中のリソースの状態やノードの状態 -->
  </status>
</cib>

プロセス間データ処理の流れと状態遷移の仕組み

Pacemaker では、複数のサブデーモンが連携してクラスタを制御します。その中心的役割を担う pacemaker-controld は、クラスタの「頭脳」として動作し、ノードの参加・離脱、リソースの起動・停止、フェイルオーバーなど、クラスタ内で発生する各種イベントに応じて内部状態を遷移させつつ、クラスタ全体を制御します。

代表的な状態は次のとおりです。

次に、一例として 起動時および障害発生時における状態遷移の流れについて解説します。

起動時の状態遷移

クラスタの起動時、Pacemaker の各サブデーモンは協調しながら、ノード間でメンバーシップを確立し、リソース配置を決定します。このプロセスは段階的に進み、各状態で必要な初期化や情報収集、計算処理が行われた上で、最終的にクラスタは安定状態に到達します。

起動
│  
│  親デーモン pacemakerd が起動し、各サブデーモンをを順次起動
│  (controld, schedulerd, execd, based, attrd, fenced)
│
▼
S_STARTING (初期化開始)
│
│  自ノード (node1) の状態を unknown → member に更新
│  CIB 読み込み、Corosync 接続
│  他ノードの参加を待機
│
▼
S_PENDING (待機)
│
│  node2 の参加を検知
│  DC 選挙開始
│
▼
S_ELECTION (DC選挙)
│
│  投票の結果、node1 が DC に選出
│
▼
S_INTEGRATION (ノード統合)
│
│  JOIN 要求を受け入れ、node2 をクラスタに統合
|
▼
S_FINALIZE_JOIN (JOIN確定)
│ 
│  クラスタメンバーシップを確定
│  
│  * pacemaker-based
│     JOIN が完了したノード情報を CIB に反映
│  
▼
S_POLICY_ENGINE
│
│  * pacemaker-schedulerd
│     DC (node1) が決定後、リソース配置計算を開始
│     クラスタ全体のリソースの起動／配置プランを生成
│     計算結果を pacemaker-controld に渡す
│
▼
S_TRANSITION_ENGINE
│
│  * pacemaker-execd
│     pacemaker-controld の指示に従って start/stop/monitor を実行
│     成否を pacemaker-controld にフィードバック
│
│  * pacemaker-controld
│     リソース操作の成功を確認
│
▼
S_IDLE (安定状態)
│
│  リソース操作がすべて正常終了
│  クラスタは安定状態に遷移
│

障害発生時の状態遷移

クラスタ稼働中にリソース障害やノード障害が発生した場合、Pacemaker はそのイベントを検知し、自動的に回復処理を行います。障害発生時は、クラスタが持つ最新の CIB 情報に基づいて、フェイルオーバーや再起動などのアクションを決定し、適切に実行します。

S_IDLE (安定状態)
│
│  クラスタは安定稼働中
│  * pacemaker-execd (node1)
│     VIP_monitor_10000 が定期的に実行される
│     結果: 失敗 (rc=7, not running)
│     この結果を pacemaker-controld に返却
│  
│  * pacemaker-controld (node1)
│     monitor 失敗を検知
│     CIB 更新要求を pacemaker-based に送信
│  
│  * pacemaker-based (node1)
│     CIB 更新要求を処理
│     CIB をディスクに書き込み
│
│  * pacemaker-attrd (node1)
│     属性を更新：
│        ・last-failure-VIP#monitor_10000[node1] = 1756193718
│        ・fail-count-VIP#monitor_10000[node1] = 1
│     CIB に反映
│
▼
S_POLICY_ENGINE (リソース配置計算)
│
│  * pacemaker-schedulerd (node1)
│     CIB の変更を検知し、リソース配置計算を再実行
│     migration-threshold=1 のため node1 での再起動不可と判断
│     VIP を node2 へ移動する決定
│     Transition 10（遷移グラフ）を生成：
│       ・VIP_stop on node1
│       ・VIP_start on node2
│       ・VIP_monitor_10000 on node2 (recurring)
│
▼
S_TRANSITION_ENGINE (アクション実行)
│
│  * pacemaker-controld (node1)
│     pacemaker-schedulerd から受け取った Transition 10 を順次実行
│     まず pacemaker-execd (node1) に VIP_stop を要求
│  
│  * pacemaker-execd (node1)
│     VIP_stop を実行し、結果を pacemaker-controld に返却
│
│  * pacemaker-controld (node1)
│     次に node2 に VIP_start を指示
│
│  * pacemaker-execd (node2)
│     VIP_start を実行
│     VIP_monitor_10000 を開始
│     結果を pacemaker-controld (node2) に返却
│
▼
S_IDLE (安定状態復帰)
│
│  VIP が node2 上で正常稼働開始
│  monitor 監視も復帰
│  クラスタは再び安定状態へ移行
│

おわりに

今回は、Pacemaker/Corosync のプロセス構成と、pacemaker-controld を中心とした状態遷移の仕組みについて解説しました。

Pacemaker は複数のデーモンプロセスが協調して動作しており、CIB を中心とした情報共有や状態遷移の制御を正しく理解することで、クラスタの挙動をより深く把握できます。これにより、トラブルシューティングやクラスタ構成の最適化を行う際に大いに役立つでしょう。