なお、PostgreSQLのロジカルレプリケーション自体についての基本的な解説は、以下の記事を参考にしてください。

• ロジカルレプリケーションの紹介 (1)
• ロジカルレプリケーションの紹介 (2)
• ロジカルレプリケーションの紹介 (3)

ロジカルレプリケーションによるアップグレードの概要

ロジカルレプリケーションを利用することで、異なるメジャーバージョン間でデータを同期しながら新しい環境を構築することが可能です。新旧データベースを並行稼働させ、最終的に接続先を切り替えることで、数秒程度のダウンタイムで移行を実現できます。

上記イメージはロジカルレプリケーションを用いたバージョンアップのアーキテクチャイメージです。

対応バージョンとしては、Publisher（旧バージョンのデータベース）は PostgreSQL 10 以上である必要があります。例えば PostgreSQL 13 から 16 へのアップグレードは可能ですが、9.6 からの移行には対応していません。

全体の流れは以下のとおりです。これらの手順について詳しく解説します。
ロジカルレプリケーションはデータベース単位で構成されるため、各データベースごとに個別に設定・同期を行います。

1. 旧バージョンのデータベースを稼働させたまま、新バージョンのデータベースクラスタを initdb で構築し起動する

以下の手順を、対象となるすべてのデータベースに対して実施します。

2. 旧バージョンの各データベースで全テーブルを対象としたパブリケーションを作成
3. 新バージョン側に移行するデータベースを作成
4. 旧バージョンの各データベースから pg_dump -s でスキーマ定義の SQL を取得して新バージョンの各データベースにリストア
5. 新バージョンの各データベースでサブスクリプションを作成

すべてのデータベースでサブスクリプション作成および同期が完了した後、
以下の作業を実施します。

6. 旧バージョンのデータベースクラスタへの更新処理を停止する
7. 各データベースで pg_stat_subscription を確認し、LSN の一致を確認する
8. 同期完了後、シーケンス位置やラージオブジェクトなどロジカルレプリケーションで同期されないデータを各データベースで手動同期する
9. アプリケーションの接続先を切り替える

ロジカルレプリケーションによるアップグレードの注意点

ロジカルレプリケーションでは、テーブルの行データに対する変更がサブスクライバへ同期されます。一方で、行データ以外の更新情報は同期されません。

そのため、以下のようなオブジェクトは別途作成または移行する必要があります。

• テーブルやスキーマの定義
• ビューおよびマテリアライズドビューの定義
• パーティションテーブルや外部テーブルの定義
• シーケンスの現在値
• ラージオブジェクト
• 拡張機能
• UNLOGGED TABLE
• ロール

特にスキーマ、テーブル定義についてはロジカルレプリケーションでは同期されず、サブスクライバ側で定義されていない状態でロジカルレプリケーションを行うと伝播先のテーブルがないとしてレプリケーションに失敗します。よってスキーマ、テーブル定義については pg_dump を用いて定義の SQL を取得して新バージョンのデータベースで実行するなどして事前にリストアしておく必要があります。今回紹介する手順では pg_dump に -s  オプションを付与して実行し、各 DDL を取得してロジカルレプリケーション前に新バージョンのデータベースで実行するようにします。

またその他にも拡張機能やロールなどもロジカルレプリケーションでレプリケーションされないため必要に応じて別途リストアする必要があります。

アップグレード手順

旧バージョンデータベースのロジカルレプリケーションのセットアップ

今回使用する環境は以下の通りで、PostgreSQL 14 から PostgreSQL 18 に移行します。

まず最初に旧バージョンのデータベースを稼働させたまま新データベースクラスタを構築し、旧バージョンでロジカルレプリケーションの有効化とパブリケーションを作成を行います。

#新しいバージョンのデータベースクラスタを作成して起動
$ /usr/local/pgsql18/bin/initdb -D /var/lib/pgsql/18
[postgres@server1 ~]$ /usr/local/pgsql18/bin/pg_ctl -D /var/lib/pgsql/18 -o "-p 5433" start

ロジカルレプリケーションではパブリッシャの wal_level は logical である必要があります。ロジカルレプリケーションとは別にストリーミングレプリケーションを利用している場合は既に使用しているレプリケーションスロット数に今回のロジカルレプリケーション用に必要なスロット数を加えた値を max_replication_slots に設定してください。複数のデータベースを新バージョンへ移行する場合は、旧バージョン側でデータベースの数分レプリケーションスロットを作成しますのでその分のスロット数も max_replication_slots に乗じてください。

またパブリッシャから WAL 情報を送信する walsender プロセスの上限を決定する max_wal_senders もレプリケーション接続される数を超えるように設定してください。設定後にサーバーを再起動して設定を反映します。

# ロジカルレプリケーションを利用できるよう旧バージョンの postgresql.conf を編集して再起動
[postgres@server1 ~]$ vi /var/lib/pgsql/14/postgresql.conf
wal_level = logical
#max_replication_slots = 10
#max_wal_senders = 10
[postgres@server1 ~]$ /usr/local/pgsql14/bin/pg_ctl -D /var/lib/pgsql/14 -o "-p 5432" restart

再起動後、今回のレプリケーションの動作確認用に、旧バージョンのデータベースに users テーブルを作成します。

[postgres@server1 ~]$ /usr/local/pgsql14/bin/psql -p 5432
psql (14.22)
Type "help" for help.

postgres=# CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT
);
CREATE TABLE
postgres=# INSERT INTO users(name) VALUES ('taro');
INSERT 0 1
postgres=# INSERT INTO users(name) VALUES ('jiro');
INSERT 0 1
postgres=# \d
List of relations
Schema | Name         | Type     | Owner
-------+--------------+----------+----------
public |    users     |  table   | postgres
public | users_id_seq | sequence | postgres
(2 rows)

postgres=# SELECT * FROM users;
id | name
---+------
1  | taro
2  | jiro
(2 rows)

その後パブリケーションを作成します。パブリケーションの対象を FOR ALL TABLES とし、すべてのテーブルを同期対象にするようにします。複数データベースを移行する場合はデータベースごとにパブリケーションを作成してください。

postgres=# CREATE PUBLICATION pub_all FOR ALL TABLES;

# 他データベースも必要であれば同様に作成する
db2=# CREATE PUBLICATION pub_all_2 FOR ALL TABLES;

旧バージョンデータベースの pg_hba.conf  設定

旧バージョン側  pg_hba.conf には、新バージョンデータベースからのレプリケーション接続を許可する設定を追加します。論理レプリケーションでは、サブスクライバからパブリッシャへ接続してデータ取得を行うため、replication 権限を持つ接続許可が必要です。

# サブスクライバからのレプリケーション接続を許可
host replication postgres 0.0.0.0/0 trust

新バージョンに移行するデータベースとスキーマを移行

ロジカルレプリケーションではテーブルデータのみが同期対象となり、ロール、データベース、スキーマ定義などは自動的には同期されません。そのため、ロジカルレプリケーションを開始する前にこれらを新バージョン側へ移行しておく必要があります。

まずはロールやテーブルスペースなどのグローバルオブジェクトを移行します。

# グローバルオブジェクトをダンプ・リストア
[postgres@server1 ~]$ /usr/local/pgsql18/bin/pg_dumpall -g | /usr/local/pgsql18/bin/psql -p 5433

次に新バージョンの各データベースに pg_dump -s -C でスキーマ定義を旧バージョンのデータベースからリストアしたのちにサブスクリプションを作成してテーブルデータを同期します。注意点でも述べた通りロジカルレプリケーションではスキーマやテーブル定義といった DDL までは同期されないので別途に pg_dump によって手動でリストアしておく必要があります。

pg_dump, psql は -d で対象データベースを指定します。データベースを複数移行する場合はデータベースごとに pg_dump, psql を実施し、-d で指定するデータベースを変更してください。

pg_dump の結果を psql で実行した後に \d でリレーションを確認すると旧バージョンで作成した users テーブルやシーケンスがコピーされていることが分かります。

[postgres@server1 ~]$ /usr/local/pgsql18/bin/pg_dump -p 5432 -s -C -d postgres |  /usr/local/pgsql18/bin/psql -p 5433
[postgres@server1 ~]$ /usr/local/pgsql18/bin/psql -p 5433
psql (18.3)
Type "help" for help.
postgres=# \d
List of relations
Schema | Name         | Type     | Owner
-------+--------------+----------+----------
public | users        |  table   | postgres
public | users_id_seq | sequence | postgres
(2 rows)

新バージョンの各データベースでのサブスクリプションのセットアップ

次に旧バージョンの各データベースで作成したパブリケーションに対してサブスクリプションを作成します。サブスクリプションは移行するデータベースごとに作成し、CONNECTION の引数内の dbname や PUBLICATION でしているパブリケーション名は適宜変更してください。

その後テーブルの中身を SELECT するとテーブルデータが同期されていることが分かります。

postgres=# CREATE SUBSCRIPTION sub_all
CONNECTION 'host=localhost port=5432 dbname=postgres'
PUBLICATION pub_all;
NOTICE: created replication slot "sub_all" on publisher
CREATE SUBSCRIPTION
postgres=# SELECT * FROM users;
id | name
---+------
1  | taro
2  | jiro
(2 rows)

旧バージョンの各データベースへの更新を停止して同期の完了を待ち、シーケンス位置を揃える

サブスクリプション作成後、旧バージョンの各データベースへの更新を一時停止します。これによって旧バージョン側の LSN を止め、新バージョン側の LSN が追い付ける状態にします。

更新処理停止後、新バージョン各データベースごとに pg_stat_subscription 内を確認して received_lsn と latest_end_lsn が一致していることが確認できれば同期は完了です。received_lsn はパブリッシャから受け取った WAL 位置を、latest_end_lsn はパブリッシャから受け取った WAL をサブスクライバで適用し、その完了をパブリッシャに報告した位置を示します。

postgres=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid                 | 16395
subname               | sub_all
worker_type           | apply
pid                   | 3457
leader_pid            |
relid                 |
received_lsn          | 0/1718270
last_msg_send_time    | 2026-04-27 15:33:53.961503+09
last_msg_receipt_time | 2026-04-27 15:33:53.961586+09
latest_end_lsn        | 0/1718270
latest_end_time       | 2026-04-27 15:33:53.961503+09

その後シーケンス位置を手動で同期します。ロジカルレプリケーションではシーケンス位置はレプリケーションされず、また pg_dump -s でもシーケンス位置を設定する SQL は出力されません。そのためシーケンスの位置は手動で揃える必要があります。

新バージョン側でシーケンスを調整する前の時点ではシーケンスの開始値が初期値である 1 のままとなっています。そのため、新バージョンのデータベース側で INSERT を実行すると、すでにテーブルに存在する id=1 の行と重複し、ユニーク制約違反が発生します。

postgres=# SELECT currval('users_id_seq');
ERROR: currval of sequence "users_id_seq" is not yet defined in this session
postgres=# INSERT INTO users(name) VALUES ('saburo');
ERROR: duplicate key value violates unique constraint "users_pkey"
DETAIL: Key (id)=(1) already exists.

シーケンス位置は pg_dump の出力に含まれる setval の SQL を新バージョン側の各データベースで実行して反映します。-d オプションの引数もデータベースごとに適宜変更してください。

[postgres@server1 ~]$ pg_dump -p 5432 -d postgres > dump.sql
[postgres@server1 ~]$ cat dump.sql
(省略)

--
-- Name: users_id_seq; Type: SEQUENCE SET; Schema: public; Owner: postgres
--

SELECT pg_catalog.setval('public.users_id_seq', 2, true);

[postgres@server1 ~]$ /usr/local/pgsql18/bin/psql -p 5433
psql (18.3)
Type "help" for help.
postgres=# SELECT pg_catalog.setval('public.users_id_seq', 2, true);

その他ラージオブジェクトや拡張機能など、WAL 書き出されずロジカルレプリケーションの対象外となっているものについても手動で同期を行います。これによって旧バージョンと新バージョンの同期は完了です。

同期完了後アプリケーションの接続先を新バージョンのデータベースに切り替える

すべてのデータベースの同期完了後にアプリケーションの接続先を切り替えます。

新バージョンの各データベースのサブスクリプションを無効化、マテリアライズドビューをすべて REFRESH したのちに、新バージョン側のpg_hba.conf にアプリケーションからの接続の認証情報を記述し、アプリケーションの接続先を切り替えればアップグレードは完了です。

# サブスクリプションを無効化
postgres=# ALTER SUBSCRIPTION sub_all DISABLE;

# マテリアライズドビューがあれば REFRESH
postgres=# REFRESH MATERIALIZED VIEW my_mv;

# pg_hba.conf にアプリケーションからの接続の認証情報を記載(環境に合わせて適宜記載)
host all application 0.0.0.0/0 trust

まとめ

ロジカルレプリケーションを用いた PostgreSQL のメジャーアップグレードは、適切に設計・運用することで、サービス停止時間を最小限に抑えた安全な移行を実現できます。ただし、データ以外の要素は自動的には同期されないため、スキーマ、シーケンス位置などを含めた包括的な準備が不可欠です。

事前検証と十分な計画を行うことで、本番環境においても安定したアップグレードを実施できます。

検証環境

対象とする PostgreSQL のバージョンは12、サーバやユーザの名前などについては、1 回目と同様に下記の通りです。

• パブリッシャとなる PostgreSQL のサーバ名を first_server、データベース名を first
• サブスクライバとなる PostgreSQL のデータベース名を second
• ロジカルレプリケーション用のユーザ名を logi_user

そのため、

• first=# で始まる SQL はパブリッシャで実行するコマンド
• second=# で始まる SQL はサブスクライバで実行するコマンド

となります。

コンフリクトの解消

まずは、ロジカルレプリケーションで発生するコンフリクトについて紹介します。

パブリッシャからサブスクライバにレプリケーションされるデータ操作が、サブスクライバ上でデータ一意制約エラーなどによって、正しくレプリケーションされない場合があります。
この事象がコンフリクトと呼ばれます。

具体的にどのような挙動となるのかを以下で確認していきます。

パブリッシャの first_to_second テーブルにはデータが 1 件登録されています。
主キーは id です。

first=# SELECT * FROM first_to_second;
 id |    val
----+------------
  1 | from_first
(1 行)

サブスクライバの first_to_second テーブルにはデータが 2 件登録されています。

second=# SELECT * FROM first_to_second;
 id |       val
----+------------------
  1 | from_first
  2 | insert_by_second
(2 行)

この状態で、パブリッシャにデータを 1 件追加します。

first=# INSERT INTO first_to_second VALUES (2, 'from_first');
INSERT 0 1

first=# SELECT * FROM first_to_second;
 id |    val
----+------------
  1 | from_first
  2 | from_first
(2 行)

追加されました。
サブスクライバでどうなったかを確認します。

second=# SELECT * FROM first_to_second;
 id |       val
----+------------------
  1 | from_first
  2 | insert_by_second
(2 行)

サブスクライバでは、すでに id = 2 のレコードが存在していたため、コンフリクトが発生し、データが追加されませんでした。
サブスクライバ側のログを確認すると、以下のようなログが出力されます。

2022-04-08 13:13:35.662 JST [8075](err_code=23505) ERROR: duplicate key value violates unique constraint "first_to_second_pkey"
2022-04-08 13:13:35.662 JST [8075](err_code=23505) DETAIL: Key (id)=(2) already exists.

コンフリクトを解消する方法は 2 通りあります。

1. pg_replication_origin_advance 関数を使って、コンフリクトしているトランザクションをスキップする。
2. コンフリクトしないようにタプルデータを修正する。

1 の方法では、pg_replication_origin_advance 関数の引数に、レプリケーションの開始点としたい LSN を指定します。
誤った LSN を指定してしまいますと、レプリケーションさせたいトランザクションまでスキップされる可能性がありますので、LSN の指定は注意深く行ってください。

今回は 2 の方法で解消します。

サブスクライバで id = 2 のデータを削除します。

second=# DELETE FROM first_to_second WHERE id = 2;
DELETE 1

second=# SELECT * FROM first_to_second;
 id |    val
----+------------
  1 | from_first
  2 | from_first
(2 行)

無事にコンフリクトが解消され、パブリッシャで行ったデータ追加が反映されました。

以上が、ロジカルレプリケーションでのコンフリクトと、その解消方法です。

パブリッシャまたはサブスクライバでスキーマ変更を実施したことによるエラー

次に、テーブルのスキーマを変更したことにより発生するエラーを紹介します。

最初にロジカルレプリケーション用の logi_schema スキーマを作成し、テーブルをそのスキーマに移動します。

first=# CREATE SCHEMA logi_schema AUTHORIZATION logi_user;
CREATE SCHEMA

first=# ALTER TABLE first_to_second SET SCHEMA logi_schema;
ALTER TABLE

テーブルのスキーマ移動に伴い、パブリケーションに追加するテーブルにもスキーマを指定します。

first=# ALTER PUBLICATION pb_first_to_second SET TABLE logi_schema.first_to_second;
ALTER PUBLICATION

スキーマを変更した first_to_second テーブルに id = 2 のデータを追加して挙動を確認します。

first=# INSERT INTO logi_schema.first_to_second VALUES (2, 'from_logi_schema_first');
INSERT 0 1

サブスクライバ側ではデータが追加されませんでした。

second=# SELECT * FROM first_to_second;
 id |    val
----+------------
  1 | from_first
(1 行)

これは、サブスクライバ側で出力される下記ログのとおり、サブスクライバ側で first_to_second が logi_schema スキーマに存在していないことが原因です。

2022-04-08 13:28:43.874 JST [8705](err_code=55000) ERROR: logical replication target relation "logi_schema.first_to_second" does not exist

サブスクライバ側でも、logi_schema スキーマを作成し、first_to_second テーブルを移動させます。

second=# CREATE SCHEMA logi_schema AUTHORIZATION logi_user;
CREATE SCHEMA

second=# ALTER TABLE first_to_second SET SCHEMA logi_schema;
ALTER TABLE

改めて、サブスクライバでデータを確認します。

second=# SELECT * FROM logi_schema.first_to_second;
 id |          val
----+------------------------
  1 | from_first
  2 | from_logi_schema_first
(2 行)

エラーが解消されたことで、パブリッシャのデータ追加がサブスクライバに反映されました。

サブスクリプションの作成や削除時に発生するエラー

サブスクリプションを作成または削除する際にも、いくつかのエラーが発生する可能性がありますので、紹介いたします。

レプリケーションスロットの重複エラー

サブスクリプションの作成時に、パブリッシャにレプリケーションスロットを作成されます。
作成しようとするレプリケーションスロット名と同名のレプリケーションスロットが、すでにパブリッシャに存在する場合、下記のようなエラーが発生します。

second=# CREATE SUBSCRIPTION logical_sub CONNECTION 'host=192.168.33.10 port=5432 user=logi_user dbname=first' PUBLICATION logical_pub;
ERROR:  could not create replication slot "logical_sub": ERROR:  replication slot "logical_sub" already exists

このエラーが発生した場合には、レプリケーションスロット名が重複しないように、サブスクリプション作成時にレプリケーションスロット名を指定する必要があります。
レプリケーションスロット名の指定については、第 1 回目の記事を参考にしてください。

レプリケーションスロットの削除エラー

サブスクライバがパブリッシャに接続できていない状態で、サブスクリプションを削除しようとすると、下記のようなエラーが発生します。

second=# DROP SUBSCRIPTION sb_prefectures_products_fkey;
ERROR:  could not connect to publisher when attempting to drop the replication slot "sb_prefectures_products_fkey"
DETAIL:  The error was: could not connect to server: Connection refused
        Is the server running on host "first_server" (192.168.33.10) and accepting
        TCP/IP connections on port 5432?
HINT:  Use ALTER SUBSCRIPTION ... SET (slot_name = NONE) to disassociate the subscription from the slot.

これはパブリッシャに作成したレプリケーションスロットを削除できないために、サブスクリプションの削除がエラーとなりました。
この場合には、

• サブスクライバとパブリッシャが正しく接続された状態にする
• （ログメッセージ内の「HINT」にもあるように）サブスクリプションのレプリケーションスロットを NONE に変更する

上記いずれかの対応を行うことで、サブスクリプションを削除できるようになります。

レプリケーションスロットがパブリッシャに存在しないエラー

パブリッシャにレプリケーションスロットが存在しない状態で、サブスクリプションを削除しようとした場合には、下記のようなエラーが出力されます。

second=# DROP subscription logical_sub;
ERROR:  could not drop the replication slot "logical_sub_slot" on publisher
DETAIL:  The error was: ERROR:  replication slot "logical_sub_slot" does not exist

この場合にも、サブスクリプションのレプリケーションスロットを NONE に変更する必要があります。

サブスクリプションのレプリケーションスロットを NONE に変更する

サブスクリプションのレプリケーションスロットを変更する際に、サブスクリプションが、有効（ENABLE）状態ですと、下記のようなエラーが発生します。

second=# ALTER SUBSCRIPTION logical_sub SET (slot_name = NONE);
ERROR:  cannot set slot_name = NONE for enabled subscription

サブスクリプションを、無効（DISABLED）状態にすることで、レプリケーションスロットを変更できるようになります。

second=# ALTER SUBSCRIPTION logical_sub DISABLE;
ALTER SUBSCRIPTION

second=# ALTER SUBSCRIPTION logical_sub SET (slot_name = NONE);
ALTER SUBSCRIPTION

変更後にもロジカルレプリケーションを続ける場合には、忘れずにサブスクリプションを有効（ENABLE）状態に戻してください。

ロジカルレプリケーションが行われない場合に出力されるエラーについて

ここからは、ロジカルレプリケーションが正しく機能していない場合に出力されるエラーメッセージと、その対応方法について紹介します。

エラーメッセージ「could not receive data from WAL stream」について

レプリケーションの遅延や停滞が発生に伴い、サブスクライバ側に「could not receive data from WAL stream」というログメッセージが出力される場合があります。
これはサブスクライバで行っている WAL ストリーム受信でのネットワーク接続が切断されたことを表すメッセージです。
サブスクライバの OS レベルで正しくネットワーク接続できていない場合に発生します。
OS ログにネットワークに関するエラーメッセージが出力されていないか、ネットワーク環境に障害が発生していないかなどを確認してください。

エラーメッセージ「could not connect to the publisher」について

レプリケーションの遅延や停滞が発生に伴い、サブスクライバ側に「could not connect to the publisher」というログメッセージが出力される場合があります。
これはサブスクライバからパブリッシャに接続できないことを表すメッセージです。
パブリッシャの PostgreSQL が停止していないかを確認し、停止していないのであれば正しく接続できるかどうかを確認してください。

警告メッセージ「out of logical replication worker slots」について

ロジカルレプリケーションを開始した際に、サブスクライバに「out of logical replication worker slots」というログメッセージが出力される場合があります。
これは、ロジカルレプリケーションを行うためのワーカーの数が、設定値 max_logical_replication_workers を超えていることを表すメッセージです。
1 つのサブスクリプションで 2 つのワーカーが作成されるため、max_logical_replication_workers の設定を「サブスクリプションの数 x 2」以上にする必要があります。

エラーメッセージ「permission denied for table 《テーブル名》」について

ロジカルレプリケーションを開始した際に「permission denied for table 《テーブル名》」というログメッセージが出力される場合があります。
これは、サブスクリプションの作成時に指定したユーザが、該当テーブルに対してデータ操作を行うための権限が足りないことを表しています。
この場合には、データ操作を行うための権限を付与することで、正常にデータ操作がレプリケーションされるようになります。

おわりに

今回はロジカルレプリケーションで起こりうるコンフリクトや、エラーなどについて紹介いたしました。
まだまだロジカルレプリケーションの詳細な部分については紹介しきれていませんが、3 回に渡ってロジカルレプリケーションの概要や基本的な運用方法などを紹介いたしました。
本紹介記事の内容が PostgreSQL でロジカルレプリケーションを運用する際の手助けになれば幸いです。

検証環境

対象とする PostgreSQL のバージョンは12、サーバやユーザの名前などについては、1 回目と同様に下記の通りです。

• パブリッシャとなる PostgreSQL のサーバ名を first_server、データベース名を first
• サブスクライバとなる PostgreSQL のデータベース名を second
• ロジカルレプリケーション用のユーザ名を logi_user

そのため、

• first=# で始まる SQL はパブリッシャで実行するコマンド
• second=# で始まる SQL はサブスクライバで実行するコマンド

となります。

サブスクライバでトリガ起動

パブリッシャよりデータ操作がレプリケーションされたことを契機にトリガを起動する方法について紹介します。

以下では

• トリガ関数によって情報を書き込まれるテーブル
• データ変更トリガに登録するトリガ関数
• サブスクライバがデータを受け取ったときに起動するデータ変更トリガ

の 3 つを作成して、サブスクライバがデータを受け取った際に、トリガ起動する挙動を確認します。

時刻を記録するテーブルの作成

まずはトリガ発火時に、その時刻を記録するテーブルをサブスクライバに作成します。

second=# CREATE TABLE logical_table_history (id integer PRIMARY KEY, ope_type char(1), ope_timestamp timestamp);
CREATE TABLE

トリガ関数の作成

次に、トリガ発火時に実行する FUNCTION をサブスクライバに作成します。
戻り値を TRIGGER 型にすることで、データ変更トリガの発火時に実行されるトリガ関数として作成できます。

second=# CREATE OR REPLACE FUNCTION register_logical_table_history()
second=# RETURNS trigger AS $$
second=# BEGIN
second=#     IF NEW.id IS NULL THEN
second=#         -- DELETE 操作
second=#         UPDATE public.logical_table_history SET ope_type = substr(TG_OP, 1, 1), ope_timestamp = now() WHERE id = OLD.id;
second=#     ELSE
second=#         -- INSERT または UPDATE 操作
second=#         INSERT INTO public.logical_table_history VALUES (NEW.id, substr(TG_OP, 1, 1), now())
second=#         ON CONFLICT ON CONSTRAINT logical_table_history_pkey
second=#         DO UPDATE SET ope_type = substr(TG_OP, 1, 1), ope_timestamp = now();
second=#     END IF;
second=#     RETURN NULL;
second=# END;
second=# $$ LANGUAGE plpgsql;
CREATE FUNCTION

データ変更トリガの作成

続けて、サブスクライバに作成したトリガ関数を実行するためのデータ変更トリガを作成します。

ロジカルレプリケーションでは行レベル（FOR EACH ROW)のトリガのみサポートされていますので、契機として設定できる操作に TRUNCATE を含めることはできません。
関数呼び出しを行うタイミングを指定する BEFORE / AFTER については、制約はなく、どちらもサポートされています。

今回作成するトリガは、AFTER を指定し、契機となる操作を INSERT、UPDATE、DELETE としています。

second=# CREATE TRIGGER logical_table_trigger AFTER INSERT OR UPDATE OR DELETE ON logical_table FOR EACH ROW EXECUTE PROCEDURE register_logical_table_history();
CREATE TRIGGER

ちなみに、TRUNCATE を含めると、下記のようなエラーが発生します。

second=# CREATE TRIGGER logical_table_trigger AFTER TRUNCATE ON logical_table FOR EACH ROW EXECUTE PROCEDURE register_logical_table_history();
ERROR:  TRUNCATE FOR EACH ROW triggers are not supported

サブスクライバのテーブルに対して、ENABLE REPLICA TRIGGER の指定

ロジカルレプリケーションがデータ操作を適用するセッションは session_replication_role が replica となります。
そのため、ロジカルレプリケーションによるデータ操作時にトリガを発火させたい場合には、サブスクライバのテーブルに対して ENABLE REPLICA TRIGGER の指定を行う必要があります。

second=# ALTER TABLE logical_table ENABLE REPLICA TRIGGER logical_table_trigger;
ALTER TABLE

パブリッシャでデータ挿入

以上の対応を行うことで、サブスクライバがデータを受け取った際に、トリガを発火させて、トリガ関数を実行できるようになりました。

準備ができましたので、実際にパブリッシャ側でデータを挿入して動作を確認します。

first=# INSERT INTO logical_table VALUES (1, 1, 'trigger_test');
INSERT 0 1

サブスクライバ側でデータの状態を確認します。

second=# SELECT * FROM logical_table;
 id | no |     data
----+----+--------------
  1 |  1 | trigger_test
(1 行)

second=# SELECT * FROM logical_table_history;
 id | ope_type |       ope_timestamp
----+----------+----------------------------
  1 | I        | 2022-03-31 15:13:57.637665
(1 行)

データ操作を契機としたトリガ関数の実行により、logical_table_history テーブルにデータ操作の履歴が記録されたことを確認できました。

カスケードレプリケーションの設定

ロジカルレプリケーションは、サブスクライバから更に別のサブスクライバへレプリケーションさせることも可能です。

first → second → third という構成でロジカルレプリケーションを構成します。

first データベースにパブリケーションを作成します

すべてのテーブルを対象としたパブリケーションを作成します、

first=# CREATE PUBLICATION pb_logical_first FOR ALL TABLES;
CREATE PUBLICATION

second データベースにパブリケーションとサブスクリプションを作成します

second データベースでも同様にすべてのテーブルを対象としたパブリケーションを作成します。

second=# CREATE PUBLICATION pb_logical_second FOR ALL TABLES;
CREATE PUBLICATION

次に、first からデータ操作をサブスクライブするためのサブスクリプションを作成します。

second=# CREATE SUBSCRIPTION sb_logical_second CONNECTION 'host=first_server port=5432 user=logi_user dbname=first' PUBLICATION pb_logical_first;
CREATE SUBSCRIPTION

third データベースにサブスクリプションを作成します

second からデータ操作をサブスクライブするためのサブスクリプションを作成します。

third=# CREATE SUBSCRIPTION sb_logical_third CONNECTION 'host=second_server port=5432 user=logi_user dbname=second' PUBLICATION pb_logical_second;
CREATE SUBSCRIPTION

first データベースのテーブルにデータを追加します

パブリケーション、サブスクリプションをそれぞれ作成できましたので、first データベースの logical_table テーブルにデータを追加します。

first=# INSERT INTO logical_table VALUES (1, 1, 'from_first');
INSERT 0 1

first=# SELECT * FROM logical_table;
 id | no |   data
----+----+-----------
  1 |  1 | from_first
(1 行)

second データベースにデータ操作がレプリケーションされているかを確認します。

second=# SELECT * FROM logical_table;
 id | no |   data
----+----+-----------
  1 |  1 | from_first
(1 行)

first データベースでのデータ操作が、second データベースにレプリケーションされたことを確認できました。

次に、third データベースにデータがレプリケーションされているかを確認します。

third=# SELECT * FROM logical_table;
 id | no |   data
----+----+-----------
  1 |  1 | from_first
(1 行)

first で行ったデータ操作が、second を通じて third にレプリケーションされたことを確認できました。

カスケードレプリケーション時の注意点

どこかのデータベースが機能停止になった場合、そのデータベースからカスケードされているデータベース以降に、データ操作がレプリケーションされなくなります。

たとえば、今回の例でいいますと、second データベースが停止した場合、third データベースにもデータ操作がレプリケーションされなくなることにご注意ください。
その場合には、third データベースに作成した second データベースからデータ操作を受け取るサブスクリプションを削除し、新しく first データベースからデータ操作を受け取るサブスクリプションを作成する、などの対応が必要となります。

双方向レプリケーション

今度は、双方向のレプリケーションについて確認します。
first から second へのレプリケーションと、second から first へのレプリケーションを行う環境を構築します。

first データベースの環境構築

first データベースに、ロジカルレプリケーションを行うためのテーブル、パブリケーション、サブスクリプションをそれぞれ作成します。

first=# CREATE TABLE first_to_second (id INTEGER PRIMARY KEY, val TEXT);
CREATE TABLE

first=# CREATE TABLE second_to_first (id INTEGER PRIMARY KEY, val TEXT);
CREATE TABLE

first=# CREATE PUBLICATION pb_first_to_second FOR TABLE first_to_second;
CREATE PUBLICATION

first=# CREATE SUBSCRIPTION sb_second_to_first CONNECTION 'host=second_server port=5432 user=logi_user dbname=second' PUBLICATION pb_second_to_first;
CREATE SUBSCRIPTION

second データベースの環境構築

second データベースにも同様にテーブル、パブリケーション、サブスクリプションをそれぞれ作成します。

second=# CREATE TABLE first_to_second (id INTEGER PRIMARY KEY, val TEXT);
CREATE TABLE

second=# CREATE TABLE second_to_first (id INTEGER PRIMARY KEY, val TEXT);
CREATE TABLE

second=# CREATE PUBLICATION pb_second_to_first FOR TABLE second_to_first;
CREATE PUBLICATION

second=# CREATE SUBSCRIPTION sb_first_to_second CONNECTION 'host=first_server port=5432 user=logi_user dbname=first' PUBLICATION pb_first_to_second;
CREATE SUBSCRIPTION

レプリケーションの確認

first データベースおよび second データベースで、ロジカルレプリケーションを行う準備ができました。

first データベース側でデータを追加して挙動を確認します。

first=# INSERT INTO first_to_second VALUES (1, 'from_first');
INSERT 0 1

second データベースにレプリケーションされているかを確認します。

second=# SELECT * FROM first_to_second;
 id |    val
----+------------
  1 | from_first
(1 行)

無事にレプリケーションされました。
今度は、second データベース側でデータを追加します。

second=# INSERT INTO second_to_first VALUES (1, 'from_second');
INSERT 0 1

first データベースにレプリケーションされているかを確認します。

first=# SELECT * FROM second_to_first;
 id |     val
----+-------------
  1 | from_second
(1 行)

無事にレプリケーションされました。

ストリーミングレプリケーションでは、一方向のレプリケーションしかできませんでしたが、ロジカルレプリケーションでは双方向のレプリケーションを実現できます。
ただし、同じテーブルに対して（マルチマスタのような）双方向のレプリケーションは行えませんので、ご注意ください。

ロジカルレプリケーションが正常に動作しているかの監視方法

ロジカルレプリケーションが正常に動作しているかを確認する方法をご紹介します。

ロジカルレプリケーションが正常に動作しているかは、パブリッシャの「現在の WAL 書き込み位置」と、サブスクライバの「適用済み WAL の最終位置」を比較することで確認できます。

パブリッシャの現在の WAL 書き込み位置の確認

現在の WAL 書き込み位置は pg_current_wal_lsn 関数を実行することで確認できます。

first=# SELECT pg_current_wal_lsn();
 pg_current_wal_lsn
--------------------
 6/CD052A10
(1 行)

サブスクライバの「適用済み WAL の最終位置」の確認

サブスクライバの「適用済み WAL の最終位置」は

• パブリッシャの pg_stat_replication.replay_lsn
• サブスクライバの pg_stat_wal_receiver.received_lsn

のいずれかで確認できます。

今回はパブリッシャの pg_stat_replication.replay_lsn を確認します。

pg_stat_replication.replay_lsn が、サブスクライバに適用済み WAL の最終位置となります。

遅延が発生している場合には、replay_lag や flush_lag に遅延の時間が表示されます。replay_lag や flush_lag に値が表示されていない（NULL）なら、遅延は発生していないと判断できます。

pg_stat_replication にサブスクライバの情報が存在しない場合は、そもそもロジカルレプリケーションは正常に動作していません。

first=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 7400
usesysid         | 10
usename          | logi_user
application_name | sb_logical
client_addr      | 192.168.33.11
client_hostname  |
client_port      | 34358
backend_start    | 2022-03-31 16:27:44.879862+09
backend_xmin     |
state            | streaming
sent_lsn         | 6/CD052A10
write_lsn        | 6/CD052A10
flush_lsn        | 6/CD052A10
replay_lsn       | 6/CD052A10
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async
reply_time       | 2022-03-31 17:42:11.128553+09

今回の実行では、pg_stat_replication.replay_lsn と pg_current_wal_lsn 関数の結果が同一でしたので、遅延なくロジカルレプリケーションが行われていることが分かります。

ロジカルレプリケーションを運用する上での注意点

最後に、ロジカルレプリケーションを運用する上での注意点を紹介いたします。

pg_dump 時の注意点

pg_dump を行うユーザがスーパーユーザ権限を持っていない場合、サブスクリプションは pg_dump の対象となりません。
ロジカルレプリケーションが機能しているデータベースに対して pg_dump を行う場合、スーパーユーザ権限を持ったユーザで行う必要がありますので、ご注意ください。
以下で、実際にどのような挙動となるのかを紹介します。

非スーパーユーザで pg_dump 実行

非スーパーユーザで pg_dump を実行してみます。

$ pg_dump -d second -U logi_user > pg_dump_by_logi_user.dmp
pg_dump: 警告: 現在のユーザがスーパユーザではないため、サブスクリプションはダンプされません

非スーパーユーザでは、上記のような警告メッセージが表示され、出力されたダンプファイル内には、サブスクリプションが含まれません。

スーパーユーザで pg_dump 実行

今度はスーパーユーザで pg_dump を実行します。

-bash-4.2$ pg_dump -d second -U postgres > pg_dump_by_postgres.dmp
-bash-4.2$

スーパーユーザで実行すると警告なく pg_dump が完了し、ダンプファイルにサブスクリプションが含まれます。

パブリッシャにテーブルを追加した際の注意点

パブリッシャとサブスクライバがロジカルレプリケーションを機能している状態で、パブリッシャに新たにテーブルを追加しても、そのテーブルに対して行ったデータ操作はレプリケーションされないことにご注意ください。

サブスクライバ側でサブスクリプションのリフレッシュを行うことで、データ操作がレプリケーションされるようになります。

具体的な挙動を確認します。

まずパブリッシャで、すべてのテーブルを対象としたパブリケーションを作成します。

first=# CREATE PUBLICATION pb_all_table FOR ALL TABLES;
CREATE PUBLICATION

サブスクライバで、そのパブリケーションをサブスクライブするサブスクリプションを作成します。

second=# CREATE SUBSCRIPTION sb_all_table CONNECTION 'host=first_server port=5432 user=logi_user dbname=first' PUBLICATION pb_all_table;

これでロジカルレプリケーションが機能する状態となりました。

この状態で、パブリッシャで新たにテーブルを作成してデータを追加します。
ここでは add_table という名前のテーブルを作成しました。

first=# CREATE TABLE add_table (id INTEGER PRIMARY KEY, val TEXT);
CREATE TABLE

first=# INSERT INTO add_table VALUES (1, 'add');
INSERT 0 1

サブスクライバでも、同名のテーブルを作成し、データ操作がレプリケーションされるか確認します。

second=# CREATE TABLE add_table (id INTEGER PRIMARY KEY, val TEXT);
CREATE TABLE

second=# SELECT * FROM add_table;
 id | val
----+-----
(0 行)

予想どおり、新たに追加したテーブルに対しては、データ操作がレプリケーションされません。

この後、サブスクリプションをリフレッシュすることで、新たに追加したテーブルに対してもデータ操作がレプリケーションされるようになります。

second=# ALTER SUBSCRIPTION sb_all_table REFRESH PUBLICATION;
ALTER SUBSCRIPTION

second=# SELECT * FROM add_table;
 id | val
----+-----
  1 | add
(1 行)

無事に初期コピーが実行(※）され、データが同期されました。パブリッシャで行ったデータ操作も、レプリケーションされるようになっています。
このリフレッシュ操作は、CREATE SUBSCRIPTION または、最後にリフレッシュした後に、パブリケーションに追加されたテーブルが対象となります。
すでにレプリケーションが行われているテーブルに関しては、リフレッシュの対象とはならず、初期コピーは実行されません。

※オプションで、リフレッシュ時の初期コピーを行わないことも可能です。

外部キーで依存関係のあるテーブルに対する TRUNCATE を実施する場合の注意点

外部キーで依存関係があるテーブルに対して、TRUNCATE を実施した場合の挙動についても確認します。

パブリッシャのテーブルに対して TRUNCATE を実行した場合、サブスクライバにも TRUNCATE がレプリケーションされてデータが消去されます。
サブスクライバ側のテーブルに外部キーで依存関係があり、同一のサブスクリプションにその依存関係のテーブルが含まれていない場合、TRUNCATE は失敗します。

上記の説明を理解するために、実際に category（カテゴリ）、products（特産品） という 2 つのテーブルを用意して、外部キーで依存関係のあるテーブルに対する TRUNCATE の挙動を確認します。

パブリケーションの作成

products テーブルの category_no にはcategory テーブルの category_no を参照先とした外部キー制約が付与されていますが、category テーブルのみを対象としたパブリケーションを作成します。

first=# CREATE PUBLICATION pb_category FOR TABLE category;
CREATE PUBLICATION

サブスクリプションの作成

サブスクライバで、category テーブルのみをサブスクライブするサブスクリプションを作成します。

second=# CREATE SUBSCRIPTION sb_category CONNECTION 'host=first_server port=5432 user=logi_user dbname=first' PUBLICATION pb_category;
CREATE SUBSCRIPTION

TRUNCATE して挙動を確認

この状態でパブリッシャで category テーブルに対して TRUNCATE を行って挙動を検証します。

※category.category_no は products.category_no の依存先となっていますので、category テーブルに対する TRUNCATE は CASCADE をつけて実行します。

first=# TRUNCATE TABLE category CASCADE;
NOTICE: テーブル"products"へのカスケードを削除します
TRUNCATE TABLE

TRUNCATE が実行されましたので、データの内容を確認します。

first=# SELECT * FROM category;
 category_no | category_name
-------------+---------------
(0 行)

first=# SELECT * FROM products;
 products_no | products_name | category_no
-------------+---------------+-------------
(0 行)

パブリッシャでは問題なく category テーブルと、products テーブルが TRUNCATE されたことを確認できました。

次に、サブスクライバのテーブルの内容を確認します。

second=# SELECT * FROM category;
 category_no | category_name
-------------+---------------
           1 | 果物野菜
           2 | 魚介類海産物
           3 | 肉類乳製品
           4 | 郷土料理など
           5 | 工芸品民芸品
           6 | その他
(6 行)

second=# SELECT * FROM products;
 products_no | products_name | category_no
-------------+---------------+-------------
           1 | 夕張メロン    |           1
           2 | ジャガイモ    |           1
:
:
(128 行)

上記のように、サブスクライバ側では category および products テーブルは TRUNCATE されずにデータが存在しています。

これは、products テーブルがサブスクリプションに含まれていないので、category テーブルに連動して products テーブルを TRUNCATE できないことから、category テーブルへの TRUNCATE 自体が行われなかったためです。
この場合、products テーブルを category テーブルと同一のサブスクリプションに含めることで、パブリッシャで行った TRUNCATE がサブスクライバに正しくレプリケーションされるようになります。

おわりに

今回は、ロジカルレプリケーションの構成や注意点、ロジカルレプリケーションが機能しているかの確認方法を紹介いたしました。
パブリッシャとサブスクライバ間で単純にテーブルをレプリケーションするだけでなく、（ストリーミングレプリケーションと比べて）柔軟に構成できるのがロジカルレプリケーションの特徴です。
次回は、ロジカルレプリケーションで発生するコンフリクトやエラーについて紹介します。

本記事では、PostgreSQL 10 より導入された新たなレプリケーション方式「ロジカルレプリケーション」の概要、構築方法について紹介します。

ロジカルレプリケーションの概要

ロジカルレプリケーションとは

ロジカルレプリケーションは PostgreSQL 10 より導入されたレプリケーションの機能です。レプリケーション元となる PostgreSQL でパブリケーション（publication・発行者）を作成し、レプリケーション先となる PostgreSQL でサブスクリプション（subscription・購読者）を作成することで、レプリケーション機能が有効となります。また、レプリケーション元の PostgreSQL をパブリッシャ、レプリケーション先の PostgreSQL をサブスクライバと呼びます。まずはストリーミングレプリケーションとの違いを見ながらロジカルレプリケーションの概要をご説明いたします。

※本記事では PostgreSQL 12 を想定しています。

ロジカルレプリケーションとストリーミングレプリケーションの違い

ロジカルレプリケーションとストリーミングレプリケーションの違いは以下のとおりです。

(*1) PostgreSQL 10 では TRUNCATE はレプリケーションされませんので TRUNCATE の代わりに DELETE で削除する必要があります。
(*2) シーケンス、ラージオブジェクト、ビューなど。

ロジカルレプリケーションを活用できる状況

上記表でご確認いただいたように、下記のようなことを行いたい場合、ロジカルレプリケーションが役立つのではないかと考えられます。

• テーブル単位でのレプリケーションを行いたい
• メジャーバージョンが異なる PostgreSQL 間でのレプリケーションを行いたい
• サブスクライバ側でデータを受け取った際に、トリガを起動させたい
• ストリーミングレプリケーションで発生する「マスタの更新と、スタンバイの参照の競合」を回避したい

ロジカルレプリケーション環境の構築

実際にパブリケーションとサブスクリプションを作成して、ロジカルレプリケーションが動作する環境を構築していきます。

以降の解説内では

• パブリッシャとなる PostgreSQL のサーバ名を first_server、データベース名を first
• サブスクライバとなる PostgreSQL のデータベース名を second
• ロジカルレプリケーション用のユーザ名を logi_user

としています。

そのため、

• first=# で始まる SQL はパブリッシャで実行するコマンド
• second=# で始まる SQL はサブスクライバで実行するコマンド

となります。

postgresql.conf の設定

ロジカルレプリケーションを機能させるには、パブリッシャの wal_level が logical である必要があります。wal_level のデフォルト値は replica ですので、パブリッシャの postgresql.conf で下記のように wal_level を logical に変更します。

wal_level = 'logical'

その他、ロジカルレプリケーションに関連するパラメータは

• max_logical_replication_workers
• max_replication_slots
• max_sync_workers_per_subscription
• max_wal_senders
• max_worker_processes

があります。機能させたいロジカルレプリケーションの数によっては、上記パラメータの値を調整する必要があります。それぞれのパラメータに必要な設定値は下記マニュアルをご確認ください。

[ 参考マニュアル – 論理レプリケーション 構成設定 ]

pg_hba.conf の設定

サブスクライバの PostgreSQL からパブリッシャの PostgreSQL に接続できるように、パブリッシャの pg_hba.conf に設定を加えます。

host  first           logi_user           xxx.xxx.xxx.xxx/32      md5

パブリケーションの作成

レプリケーション元となるパブリッシャで、パブリケーションを作成します。パブリケーションには、1つのテーブルだけでなく、複数のテーブルを指定できますので、複数のテーブルをまとめてレプリケーションできます。また、オプションでロジカルレプリケーションの対象とする操作（INSERT、UPDATE、DELETE、TRUNCATE）を指定できます。たとえば、INSERT のみをレプリケーションさせることができます。

ただし、UPDATE と DELETE をレプリケーションするためには、パブリッシャのテーブルの REPLICA IDENTITY （行を一意に特定できるカラムの情報）の設定が必要となります。テーブルに主キーが存在する場合は自動的に REPLICA IDENTITY に主キーが設定されます。主キーが存在しないテーブルに REPLICA IDENTITY の指定（USING INDEX または FULL）がない場合、UPDATE および DELETE を実行した際に、実行エラーが発生しますのでご注意ください。

ロジカルレプリケーション用のテーブル作成

ロジカルレプリケーションを行うためのテーブル logical_table をパブリッシャに作成します。

first=# CREATE TABLE logical_table
        (id INTEGER PRIMARY KEY, no INTEGER , data TEXT);

パブリケーションの作成例

作成したテーブルに対して行った操作をサブスクライバに伝搬させるためのパブリケーションを作成します。パブリケーションの作成例を下記に記載します。

-- logical_table に対する操作を伝搬させるパブリケーションの作成
first=# CREATE PUBLICATION logical_pub FOR TABLE logical_table;

-- すべてのテーブルに対する操作を伝搬させるパブリケーションの作成
first=# CREATE PUBLICATION logical_pub_all_table FOR ALL TABLES;

-- logical_table に対する INSERT を伝搬させるパブリケーションの作成
first=# CREATE PUBLICATION logical_pub_insert_only
        FOR TABLE logical_table WITH (publish = 'insert');

-- パブリケーションの枠だけ作成
first=# CREATE PUBLICATION logical_pub_non_table ;

※各パラメータの詳細は下記マニュアルをご確認ください。

[ 参考マニュアル – CREATE PUBLICATION ]

パブリケーションの確認

pg_publication システムカタログを参照することで、作成されているパブリケーションを確認できます。

first=# SELECT * FROM pg_publication;

  oid  |    pubname    | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate
-------+---------------+----------+--------------+-----------+-----------+-----------+-------------
 16651 | logical_pub   |       10 | f            | t         | t         | t         | t
(1 行)

psql であればメタコマンド \dRp で確認できます。

first=# \dRp
                               パブリケーション一覧
    名前     |  所有者  | 全テーブル | Insert文 | Update文 | Delete文 | Truncate文
-------------+----------+------------+----------+----------+----------+------------
 logical_pub | postgres | f          | t        | t        | t        | t
(1 行)

パブリケーションとテーブルのマッピングを確認する

pg_publication_tables システムカタログで、パブリケーションとそれに含まれるテーブルのマッピングを確認できます。

first=# SELECT * FROM pg_publication_tables;

    pubname   | schemaname | tablename
--------------+------------+---------------
 logical_pub  | public     | logical_table
(1 行)

上記の出力から、logical_pub というパブリケーションに logical_table テーブルがマッピングされていることが分かります。

パブリケーションとテーブルのマッピングを、名称ではなく oid で確認するには pg_publication_rel システムカタログを参照します。

first=# select * from pg_publication_rel;
  oid  | prpubid | prrelid
-------+---------+---------
 16665 |   16664 |   16658
(1 行)

サブスクリプションの作成

パブリケーションを作成できたら、今度はパブリケーションから送られる更新情報を受け取るためのサブスクリプションをサブスクライバに作成します。

ロジカルレプリケーション用のテーブル作成

サブスクライバにもパブリッシャと同様のテーブルを作成します。これがロジカルレプリケーションの受け口になるテーブルです。

サブスクライバのテーブルは、パブリッシャのテーブルと

• スキーマ名
• テーブル名
• 列名

が同じである必要があります。サブスクライバのテーブル定義はパブリッシャのテーブルと完全に同一である必要はなく、サブスクライバのテーブル定義がパブリッシャのテーブル定義を内包しているのであれば、ロジカルレプリケーションが行われます。

下記の作成例では、パブリッシャのテーブル定義に加えて data2 カラムが存在しますが、id, no, data カラムがパブリッシャのテーブル定義と同一なためロジカルレプリケーションが行われます。

second=# CREATE TABLE logical_table
         (id INTEGER PRIMARY KEY, no INTEGER, data TEXT, data2 TEXT);

サブスクリプションの作成例

パブリッシャへの接続文字列などを指定して、サブスクリプションを作成します。サブスクリプションの作成例を下記に記載します。

-- パブリッシャの logical_pub パブリケーションに対する操作を受け取るための
-- サブスクリプションを作成
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub;

-- パブリッシャに作成するレプリケーションスロット名（slot_name）を指定して、
-- サブスクリプションを作成
-- (slot_name を指定しない場合、レプリケーションスロット名にはサブスクリプション名が設定されます)
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub WITH (slot_name = 'logical_sub_slot');

-- パブリッシャに通知するアプリケーション名（application_name）を指定して、
-- サブスクリプションを作成
-- (application_name を指定しない場合、アプリケーション名にはサブスクリプション名が設定されます)
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first application_name=logical_sub_app'
         PUBLICATION logical_pub;

-- コミットの同期モード（synchronous_commit）を指定して、サブスクリプションを作成
-- （postgresql.conf で設定した synchronous_commit よりも優先されます）
-- （synchronous_commit を指定しない場合、off が設定されます）
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub WITH (synchronous_commit = 'on');

※上記以外にも指定できるパラメータやオプションが存在します。詳細はマニュアルをご確認ください。

[ 参考マニュアル – CREATE SUBSCRIPTION ]

作成したサブスクリプションの確認

作成したサブスクリプションの情報は pg_subscription を参照することで確認できます。

second=# SELECT * FROM pg_subscription;

-[ RECORD 1 ]---+--------------------------------------------------------------------------------------------
oid             | 24704
subdbid         | 13266
subname         | logical_sub
subowner        | 10
subenabled      | t
subconninfo     | host=first_server port=5432 user=logi_user dbname=first application_name=logical_sub_app
subslotname     | logical_sub_slot
subsynccommit   | on
subpublications | {logical_pub}

psql であればメタコマンド \dRs で確認できます。

second=# \dRs
                サブスクリプション一覧
    名前     |  所有者  | 有効状態 | パブリケーション
-------------+----------+----------+------------------
 logical_sub | postgres | t        | {logical_pub}
(1 行)

サブスクリプションのレプリケーション状態は pg_stat_subscription を参照することで確認できます。

second=# SELECT * FROM pg_stat_subscription;

-[ RECORD 1 ]---------+------------------------------
subid                 | 24704
subname               | logical_sub
pid                   | 9374
relid                 |
received_lsn          | 6/B9064B18
last_msg_send_time    | 2020-10-14 16:43:37.585108+09
last_msg_receipt_time | 2020-10-14 16:43:37.586771+09
latest_end_lsn        | 6/B9064B18
latest_end_time       | 2020-10-14 16:43:37.585108+09

また、サブスクリプションとテーブルのマッピングは pg_subscription_rel で確認できます。

second=# SELECT * FROM pg_subscription_rel;

 srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+----------
   24704 |   24679 | d          |
(1 行)

上記のとおり、pg_subscription_rel の中にはテーブルの名前ではなく oid で情報が保持されています。パブリケーションと違い、現時点でマッピングの情報を名称で確認できるシステムカタログはないようです。サブスクリプションとテーブル名のマッピングは pg_subscription と pg_class を合わせて参照することで確認できます。

second=# SELECT
    pg_subscription.subname
  , pg_class.relname
  , pg_subscription_rel.srsubstate
  , pg_subscription_rel.srsublsn
FROM
  pg_subscription_rel
    INNER JOIN pg_subscription
            ON pg_subscription_rel.srsubid = pg_subscription.oid
    INNER JOIN pg_class
            ON pg_subscription_rel.srrelid = pg_class.oid
;

   subname   |    relname    | srsubstate | srsublsn
-------------+---------------+------------+----------
 logical_sub | logical_table | d          |
(1 行)

初期データコピー

サブスクリプションを作成した時点で、初期コピーと呼ばれる「パブリッシャのテーブルからサブスクライバのテーブルへのデータコピー処理」が実行されます。

-- サブスクリプション作成前の logical_table の中身（初期コピー前は 0 件）
second=# =# SELECT * FROM logical_table;
 id | no | data | data2
----+----+------+-------
(0 行)

-- サブスクリプション作成（初期コピー実施）
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub;
CREATE SUBSCRIPTION

-- サブスクリプション作成後の logical_table の中身
-- （パブリッシャの logical_table のデータがコピー）
second=# SELECT * FROM logical_table;
 id | no |  data  | data2
----+----+--------+-------
  1 |  1 | 北海道 |
  2 |  2 | 青森県 |
  3 |  3 | 岩手県 |
  : |  : | 　:　 |
  : |  : | 　:　 |
 47 | 47 | 沖縄県 |
(47 行)

また、この初期コピーの際に、コピーされるパブリッシャのデータとサブスクライバの既存のデータが競合し、一意制約エラーの発生する可能性があります。

これは初期コピーが「差分のみを追加する」などの制御を行わずに、単純に「パブリッシャのテーブルのデータを、そのままサブスクライバのテーブルへ追加する」ためです。

# データ競合時のエラーメッセージ
2020-10-14 15:15:27.775 JST [8365](err_code=23505) ERROR:  duplicate key value violates unique constraint "logical_table_pkey"
2020-10-14 15:15:27.775 JST [8365](err_code=23505) DETAIL:  Key (id)=(1) already exists.

こういった場合、copy_data オプションに false を指定し、初期コピーを行わないことでエラーを回避できます。

second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub WITH (copy_data = false);

サブスクリプションの有効／無効の切り替え

サブスクリプションは有効／無効を切り替えることができます。そのため、ロジカルレプリケーションを一時的に中断したい場合でも、サブスクリプションを削除する必要がありません。

サブスクリプションの無効化

サブスクリプションを無効にします。無効化している間は、当然ですがパブリッシャで行った操作がサブスクライバへレプリケーションされなくなります。

second=# ALTER SUBSCRIPTION logical_sub DISABLE;

サブスクリプションの有効化

サブスクリプションを有効にします。サブスクリプションを有効にした場合、無効化した時点からレプリケーションが行われます。そのため、サブスクリプションを有効化することで、無効化されている間に行った操作がサブスクライバへレプリケーションされます。

second=# ALTER SUBSCRIPTION logical_sub ENABLE;

まとめ

以上、ロジカルレプリケーションの概要と基本的な使い方をご紹介させていただきました。次回以降では、ロジカルレプリケーションの機能を実現するプロセスについての解説や、カスケードレプリケーションの設定やコンフリクト発生時の解消方法などの運用に関する情報などをお伝えする予定です。