確かに、手元で試したら、スタンバイ昇格してもlogical walsenderの再起動などなく、ロジカルレプリケーションがそのまま続行されたっぽい！ #pg16
— Fujii Masao (@fujii_masao) June 23, 2023
以下は、PostgreSQL 16の新機能であるストリーミングレプリケーションのスタンバイ側からのロジカルレプリケーションについて、上記ツイートで試した手順の整理です。
前提として、検証手順では、以下のデータベースクラスタのディレクトリ名とポート番号で3つのPostgreSQLインスタンスを同一環境上で起動します。
| 項番 | データベースクラスタのディレクトリ名 | ポート番号 | インスタンスの用途 |
|---|---|---|---|
| 1 | pri | 5432 | ストリーミングレプリケーションのプライマリ |
| 2 | sby | 5433 | ストリーミングレプリケーションのスタンバイ、かつ、ロジカルレプリケーションのパブリケーション側 |
| 3 | sub | 5434 | ロジカルレプリケーションのサブスクリプション側 |
検証手順
ストリーミングレプリケーションのプライマリについて、データベースクラスタを作成して、起動します。ロジカルレプリケーションを使うために、wal_levelはlogicalに設定します。
$ initdb -D pri --locale=C --encoding=UTF8
$ echo "wal_level = logical" >> pri/postgresql.conf
$ pg_ctl -D pri start
ストリーミングレプリケーションのスタンバイについて、プライマリのバックアップから起動します。
$ pg_basebackup -D sby -R
$ echo "port = 5433" >> sby/postgresql.conf
$ pg_ctl -D sby start
ロジカルレプリケーションのサブスクリプション側について、データベースクラスタを作成して、起動します。
$ initdb -D sub --locale=C --encoding=UTF8
$ echo "port = 5434" >> sub/postgresql.conf
$ pg_ctl -D sub start
今回の検証では、pgbenchのテーブル4つをロジカルレプリケーションします。pgbenchの初期データをプライマリで作成して、そのテーブルをロジカルレプリケーションするためのパブリケーションを作成します。これらの初期データとパブリケーションは、ストリーミングレプリケーションによりスタンバイに自動的に複製されます。
$ pgbench -i -s 10 -p 5432
$ psql -p 5432 -c "CREATE PUBLICATION pgbench_pub FOR TABLE pgbench_accounts, pgbench_branches, pgbench_tellers, pgbench_history"
サブスクリプション側では、初期データなしでpgbenchのテーブルだけ作成して、スタンバイからロジカルレプリケーションされるようにport=5433を指定してサブスクリプションを作成します。
$ pgbench -i -Itp -p 5434
$ psql -p 5434 -c "CREATE SUBSCRIPTION pgbench_sub CONNECTION 'port=5433' PUBLICATION pgbench_pub"
上記のCREATE SUBSCRIPTIONが長時間完了しない場合は、プライマリに対してCHECKPOINTなどの更新コマンドを実行することで完了することがあります。
$ psql -p 5432 -c "CHECKPOINT"
プライマリに対してpgbenchで10トランザクションを走らせ、pgbench_historyの10トランザクション分のレコードがサブスクリプション側にロジカルレプリケーションされていること(レコード件数が10件であること)を確認します。これで、スタンバイからのロジカルレプリケーションのセットアップが完了しました。
$ pgbench -p 5432 -t 10
$ psql -p 5434 -c "SELECT count(*) FROM pgbench_history"
スタンバイ昇格のロジカルレプリケーションへの影響を調査するため、ロジカルレプリケーションの「スタンバイ(昇格後は新プライマリ)上のwalsenderプロセスのPID」と「サブスクリプション上のlogical replication workerプロセスのPID」を確認します。
$ psql -p 5433 -c "SELECT * FROM pg_stat_replication"
$ psql -p 5434 -c "SELECT * FROM pg_stat_activity WHERE backend_type = 'logical replication worker'"
スタンバイを新プライマリに昇格させます。
$ pg_ctl -D sby promote
再度、ロジカルレプリケーションの「新プライマリ(昇格前は旧スタンバイ)上のwalsenderプロセスのPID」と「サブスクリプション上のlogical replication workerプロセスのPID」を確認します。前回と今回で各プロセスのPIDに変更がなければ、スタンバイ昇格によって各プロセスが再起動されることはなかったと確認できます。
$ psql -p 5433 -c "SELECT * FROM pg_stat_replication"
$ psql -p 5434 -c "SELECT * FROM pg_stat_activity WHERE backend_type = 'logical replication worker'"
プライマリに対してpgbenchで20トランザクションを走らせ、pgbench_historyの20トランザクション分のレコードがサブスクリプション側にロジカルレプリケーションされていること(レコード件数が20件であること)を確認します。これにより、スタンバイ昇格後も問題なくロジカルレプリケーションが動作していることを確認します。
$ pgbench -p 5433 -t 20
$ psql -p 5434 -c "SELECT count(*) FROM pgbench_history"