Cloud SQL for PostgreSQL の論理レプリケーションと論理デコーディング機能を使用できます。これらの機能によって、論理レプリケーション ワークフローと変更データ キャプチャ（CDC）ワークフローが可能になります。
レプリケーションの概要については、Cloud SQL でのレプリケーションをご覧ください。
はじめに
PostgreSQL が論理レプリケーションを実行すると、レプリカにストリーミングされる変更が論理デコーディングにより WAL ログから抽出されます。デコーディングされた変更は、基盤となる物理ストレージの形式と関係ありません。これらの変更は、INSERT、UPDATE、DELETE に関して、SQL レベルのデータ変更のみを反映します。ストレージ レイヤから独立しているため、柔軟性が高くなり、変更ストリームのコンシューマは幅広い機能を使用できます。
論理レプリケーションは、論理デコーディングを基盤とする中核機能です。
PostgreSQL の物理レプリケーション機能では、送信元データベースと送信先データベースの両方を同じバージョンにする必要がありますが、論理レプリケーションでは PostgreSQL のメジャー バージョン間でレプリケーションを行うことができます。Cloud SQL の論理レプリケーションは、すべての PostgreSQL バージョンで利用可能な pglogical 拡張機能と、PostgreSQL 10 で追加された PostgreSQL のネイティブ論理レプリケーションでサポートされています。
変更のストリーミング形式はさまざまなプラグインで構成できます。これにより、柔軟な変更データ キャプチャ（CDC）アーキテクチャが可能になります。たとえば、wal2json 拡張機能を使用すると、データベース内のすべての変更を JSON 形式でコンシューマにストリーミングできます。Cloud SQL は、組み込みの pgoutput デコーダ、test_decoding contrib モジュール、wal2json をサポートしています。Cloud SQL は現在、トランザクション全体を単一の JSON オブジェクトとしてエンコードする JSON 出力 format-version 1 の wal2json バリアントと、コマンドごとに 1 つの JSON オブジェクトを出力する format-version 2 の両方をサポートしています。これらのプラグインを使用すると、PostgreSQL 以外のデータベースへのレプリケーションが可能になります。
PostgreSQL インスタンスを構成する
PostgreSQL では、追加情報をログ先行書き込み（WAL）に書き込むことで論理デコーディングをサポートしています。
この機能を Cloud SQL で有効にするには、cloudsql.logical_decoding フラグを on に設定します。この設定は、標準の PostgreSQL で使用されるものとは異なります。外部 PostgreSQL インスタンスを変更する場合は、wal_level 構成パラメータを logical に設定して、この機能を有効にします。
pglogical 拡張機能を使用する場合は、shared_preload_libraries に pglogical を追加してください。このフラグを Cloud SQL で直接変更することはできません。cloudsql.enable_pglogical を on に設定することで pglogical を有効にできます。 （VM では、sudo apt-get install postgresql-13-pglogical を使用）。その後、データベースを再起動します。
pglogical を使用して 2 つの PostgreSQL インスタンス間で複製を行う場合、論理デコーディングは、レプリカ インスタンスではなく、プライマリ インスタンスでのみ有効にする必要があります（ただし、そのインスタンスが他のレプリカのプライマリ インスタンスの場合は除きます）。ただし、どちらのインスタンスでも pglogical 拡張機能を有効にする必要があります。「プライマリ」と「レプリカ」という用語の意味と使い方については、Cloud SQL でのレプリケーションをご覧ください。
ネットワーク接続を有効にする
プライマリ インスタンスがレプリカ インスタンスからの接続を受け入れるようにします。
| メイン | レプリカ | 構成 |
|---|---|---|
| Cloud SQL（パブリック IP） | Cloud SQL（パブリック IP） | レプリカの送信 IP アドレスをプライマリの承認済みネットワークに追加します。 |
| Cloud SQL（プライベート IP） | Cloud SQL（プライベート IP） | 両方のインスタンスが同じ Google Cloud プロジェクトにある場合は、レプリカの VPC ネットワークに割り振られた IP 範囲を、インスタンスをホストする承認済みネットワークに追加します。 Google Cloud コンソールで割り振られた IP 範囲を確認するには:
|
| 外部 | Cloud SQL | Database Migration Service を使用できます。 |
| Cloud SQL | 外部 | 詳細については、外部レプリカの構成をご覧ください。 |
レプリカ インスタンスの送信 IP アドレスを取得する
レプリカ インスタンスが Cloud SQL インスタンスであり、パブリック IP アドレスがある場合は、次の手順で送信 IP アドレスを取得します。
コンソール
[Cloud SQL インスタンス] ページを開きます。
Cloud SQL レプリカのパブリック IP アドレスの横にある [詳細] ツールチップにカーソルを合わせて、送信 IP アドレスを取得します。この送信 IP アドレスは、Cloud Console でレプリカのメインリストに表示される IP アドレスではありません。
レプリカ インスタンスが Cloud SQL インスタンスでない場合は、関連するドキュメントを参照してください。
インスタンスのパブリック IP アドレスを取得する方法については、Cloud SQL レプリカの送信 IP アドレスの取得をご覧ください。
gcloud
次の gcloud コマンドを使用できます。
gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"
接続を許可する
プライマリ インスタンスが Cloud SQL インスタンスの場合、承認済みネットワークとして追加することで、レプリカの送信 IP アドレスからのアクセスを許可できます。
PostgreSQL 9.6 以前でレプリケーション接続を有効にする
プライマリ インスタンスが Cloud SQL で実行されず、PostgreSQL 9.6 以前を実行している場合は、インスタンスの pg_hba.conf
ファイルがレプリケーション接続を受け入れるように設定されているかを確認する必要があります。all all を使用して、このファイルに次の行を追加します（これは、初回のテストでのみ行います）。セキュリティを高めるには、次の例のように、ユーザーと IP アドレスを必要な範囲に制限します。
host replication all all md5
詳細については、pg_hba.conf ファイルをご覧ください。
レプリケーション ユーザーを作成する
論理デコーディング機能を使用するには、REPLICATION 属性を持つ PostgreSQL ユーザーを作成します。
例
CREATE USER replication_user WITH REPLICATION
IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secret';
また、既存のユーザーに以下の属性を設定することもできます。
ALTER USER existing_user WITH REPLICATION;
PostgreSQL リソース
論理デコーディングが使用されている場合、プライマリ PostgreSQL インスタンスのバックグラウンド プロセスは、選択したデコーディング プラグインを使用して WAL 変更を論理変更に変換し、論理変更をコンシューマに中継します（PostgreSQL 以外のインスタンスの場合もあります）。このバックグラウンド プロセスを WAL 送信者といいます。PostgreSQL インスタンスで同時にアクティブにできる WAL 送信者の数は、max_wal_senders フラグによって制限されます。このフラグのデフォルト値は 10 です。この上限は Cloud SQL インスタンスのメモリに比例して増加します。メモリ 1 GB あたり 8 個の WAL 送信者が許可されます。
WAL セグメントがすべてのコンシューマに送信される前に破棄されないように、PostgreSQL は論理レプリケーション スロットを使用して、どのコンシューマ（と物理レプリケーション スロット）にどのデータが送信されたかを追跡します。PostgreSQL インスタンス用に作成できるレプリケーション スロットの数は、max_replication_slots フラグによって制限されます。このフラグのデフォルト値は 10 で、その上限は Cloud SQL インスタンスのメモリに応じて増加します。メモリ 1 GB あたり 2～8 個のレプリケーション スロットが許可されます。
次の表は、Cloud SQL インスタンスの最大メモリと、インスタンスの最大レプリケーション スロットの関係を示しています。
一般に、コンシューマごとに 1 つのレプリケーション スロットと WAL 送信者があるため、これらのフラグはほぼ同じ値に設定する必要があります。ただし PostgreSQL では、接続が予期せず切断されて新しい接続が行われた場合に、max_wal_senders で処理する小さなバッファを確保することをおすすめします。Cloud SQL リードレプリカで使用される物理レプリケーションでは、レプリケーション スロットと WAL 送信者も使用されるため、必要なリソース数を計算する際に、これらのレプリカをカウントします。
PostgreSQL ネイティブの論理レプリケーションと pglogical では、プライマリ インスタンスとレプリカ インスタンスの両方で、追加のバックグラウンド プロセスを実行する必要があります。実行できるバックグラウンド プロセスの数は、max_worker_processes フラグによって制限されます。デフォルト値は 8 で、その上限は Cloud SQL インスタンスのメモリに比例して増加し、メモリ 1 GB あたり 2 個のプロセスを追加できます。これらのアプローチで使用されるワーカー プロセスの正確な数については、それぞれのセクションで説明します。
このフラグの設定値が小さすぎると、レプリケーションが失敗し、ログにエラー メッセージ worker registration failed が記録されます。その場合は、max_worker_processes の設定を増やす必要があります。
WAL 送信者はワーカー プロセスとしてカウントされません。並列クエリ実行用に生成されるワーカーはカウント対象になります。max_worker_processes の値が小さすぎると、PostgreSQL で並列クエリ実行ができなくなるため、パフォーマンスが低下する可能性があります。
pg_ls_waldir () 関数を使用すると、WAL ディスク使用量を判別できます。この関数は、デフォルトの管理ユーザー postgres などの cloudsqlsuperuser ユーザーに制限されています。この関数は、PostgreSQL バージョン 10 以降でのみ使用できます。
WAL ディスク使用量の合計を計算するには:
postgres=> select * from pg_ls_waldir();
| 名前 | サイズ | 更新日時 |
|---|---|---|
| 00000001000000000000000A | 16777216 | 2021-08-11 15:16:49+00 |
| 000000010000000000000009 | 16777216 | 2021-08-12 06:23:24+00 |
（2 行）
postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();
| WAL ディスクの合計使用量 |
|---|
| 32 MB |
（1 行）
外部レプリカを使用して論理レプリケーションを設定する
pglogical と論理デコードを使用した完全な例については、外部レプリカの構成をご覧ください。
pglogical を使用して論理レプリケーションを設定する
pglogical を使用して論理レプリケーションを設定するには、プライマリ インスタンスで論理デコーディングを有効にする必要があります。Cloud SQL インスタンスでは cloudsql.logical_decoding=on を、外部インスタンスでは wal_level=logical を設定します。また、プライマリ インスタンスとレプリカ インスタンスの両方で pglogical を有効にする必要があります。Cloud SQL インスタンスで cloudsql.enable_pglogical=on を設定するか、外部インスタンスの shared_preload_libraries に pglogical を追加します。これらのフラグを変更するには、プライマリ インスタンスとレプリカ インスタンスの両方を再起動する必要があります。
これらの手順で問題が発生した場合は、pglogical のトラブルシューティングをご覧ください。
レプリケーション権限を持つユーザーを作成する
pglogical を使用する場合、プライマリ インスタンスとレプリカ インスタンスの両方でレプリケーション権限と cloudsqlsuperuser ロールを持つユーザーが必要です。以下で説明するコマンドは、このユーザーが実行する必要があります。
pglogical 拡張機能をインストールする
プライマリ インスタンスとレプリカ インスタンスの両方に pglogical 拡張機能をインストールする必要があります。プライマリでは、レプリケーション ユーザー（データベースに接続するユーザー）がインストールする必要があります。
CREATE EXTENSION pglogical;
各インスタンスに pglogical ノードを作成する
pglogical ノードは物理的な PostgreSQL インスタンスを表し、そのインスタンスの接続の詳細を保存しています。次のように、プライマリ インスタンスとレプリカ インスタンスの両方をノードとして登録する必要があります。
source-instance$ SELECT pglogical.create_node(
node_name := 'primary',
dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=secret'
);
dest-instance$ SELECT pglogical.create_node(
node_name := 'replica',
dsn := 'host=<replica-ip> port=5432 dbname=postgres user=replication_user password=secret'
);
複製するデータを含むテーブルを作成する
pglogical 拡張機能では、テーブルのサブセットのみを宛先に複製できます。たとえば、プライマリ インスタンスでダミーテーブルを作成し、テスト用のデータを入力します。
CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');
このテーブルをレプリカ インスタンスにも作成する必要があります。
テーブルをレプリケーション セットに追加する
異なるデータセットを異なる宛先に複製できるように、pglogical はレプリケーション セットのコンセプトに対応しています。テストテーブルは、デフォルトのレプリケーション セットに追加できます。
SELECT pglogical.replication_set_add_table('default', 'replica_test', true);
pglogical サブスクリプションを作成する
プライマリ インスタンスへの接続の詳細を指定して、移行先インスタンスで pglogical サブスクリプションを作成します。
SELECT pglogical.create_subscription(
subscription_name := 'test_sub',
provider_dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
);
SELECT * FROM pglogical.show_subscription_status('test_sub');
ステータスが「複製中」と表示されている場合、設定は成功です。replica_test テーブルにクエリを実行して、データが複製されているかどうかを確認します。プライマリ インスタンスにレコードを挿入して変更し、レプリカ インスタンスに表示されるかを確認します。
プライマリで、pg_replication_slots テーブルにクエリを実行し、サブスクリプションによって作成されたレプリケーション スロットを確認します。
クリーンアップ
テストが成功したら、pglogical.drop_subscription('test_sub') を使用してレプリカのサブスクリプションを削除します。プライマリでレプリケーション スロットも削除されているか確認します。削除されていなければ、WAL セグメントは引き続きレプリカ インスタンスに蓄積されます。
レプリケーション セット、部分データ レプリケーション、DDL レプリケーション、その他の高度な構成と制限事項の詳細については、pglogical に関するドキュメントをご覧ください。
リソースの使用量
pglogical 拡張機能は、max_worker_processes の上限の対象になる複数のバックグラウンド プロセスを実行します。
定常状態では、有効になっている「スーパーバイザー」プロセスが 1 つ、拡張機能をインストールした PostgreSQL データベースごとに「マネージャー」プロセスが 1 つ（たとえば、これらを D とします）、レプリカ インスタンスの pglogical サブスクリプションごとに 1 つの「適用」プロセス（たとえば、これらを S とします）が実行されます。ただし、拡張機能は最初の同期時に追加のワーカー プロセスを生成し、実際にはインスタンスの各データベースに対して「マネージャー」プロセスを生成することがありますが、データベースに拡張機能がインストールされていなければ、データベースは直ちに終了します。
そのため、定常状態で必要以上に多くのワーカー プロセスを割り当てます。ワーカー プロセスは、並列クエリ処理などの目的で PostgreSQL によって使用されます。max_worker_processes の設定値が小さすぎると、レプリケーションが自動的に失敗するか、PostgreSQL が並列クエリ処理を実行できない可能性があります。
このため、次の設定が推奨されます。
max_worker_processes
>= 1 + D + 8 (on the source instance)
>= 1 + D + S + 8 (on the destination instance)
max_wal_senders >= S + 2 (on the source instance)
max_replication_slots >= S (on the source instance)
pglogical のトラブルシューティング
pglogical 拡張機能を作成できない
pglogical 拡張機能をインストールしようとすると、次のようなエラーが発生することがあります。
ERROR: pglogical is not in shared_preload_libraries
Cloud SQL インスタンスに pglogical をインストールする場合は、cloudsql.enable_pglogical=on を設定済みか確認してください。外部インスタンスを使用する場合は、shared_preload_libraries フラグに直接追加してください（例: shared_preload_libraries=pg_stat_statements,pglogical）。この変更を適用するには、プライマリ インスタンスの再起動が必要です。
pglogical サブスクリプションを作成できない
サブスクリプションを作成するときに、pglogical は最初に接続の詳細を使用してインスタンスに接続できるかどうかを確認します。まず通常の接続を作成しようとします。失敗すると ERROR: could not
connect to the postgresql server エラーが発生します。
このエラーが発生した場合は、プライマリ インスタンスがレプリカ インスタンスからの接続を許可するように構成されているか確認してください。また、指定した接続の詳細が正しいかをどうかも確認する必要があります。PostgreSQL が接続を確立できなかった理由の詳細が表示されます。
通常の接続を作成したら、pglogical は特別なレプリケーション接続の作成を試みます。PostgreSQL 9.6 以前では、このタイプの接続に異なる認証構成が存在する可能性があります。ERROR: could
not connect to the postgresql server in replication mode というエラーが発生した場合は、ソース インスタンスの pg_hba.conf ファイルを更新する必要があります。
Cloud SQL で使用される pg_hba.conf ファイルには、必要な変更がすでに含まれています。このエラーは、Cloud SQL で管理されていない外部インスタンスに接続している場合にのみ発生します。
また、ソース インスタンスが十分な WAL 送信者を許可していない場合、レプリケーション モードの接続が失敗することがあります。FATAL: number of requested
standby connections exceeds max_wal_senders が表示された場合は、プライマリ インスタンスで max_wal_senders を増やしてください。
pglogical サブスクリプションが停止している
pglogical サブスクリプションのレプリケーションが失敗する場合があります。この問題に対処するには、まず、レプリカ インスタンスでバックグラウンド プロセスが実行されているかどうかを確認します。pg_stat_activity にクエリを実行し、pglogical apply プロセスが実行されているかどうかを確認してください。問題がない場合は、宛先ノードのログを確認します。「worker
registration failed,」というメッセージが表示された場合は、max_worker_processes 設定を増やすことができます。
次に、プライマリ インスタンスにレプリケーション スロットが作成されているかどうか確認します。レプリカ インスタンスの pglogical.subscription の行には、サブスクリプションが作成しようとしているスロットの名前が含まれています。プライマリ インスタンスでは、pg_replication_slots にクエリを実行してスロットが問題なく作成されたかどうかを確認できます。
レプリケーション スロットが作成されていない場合は、プライマリ インスタンスのログを確認します。
「ERROR: logical decoding requires wal_level >= logical」というエラーは、wal_level フラグが logical に設定されていないことを意味します。プライマリ インスタンスが Cloud SQL インスタンスの場合は、プライマリ インスタンスに cloudsql.logical_decoding=on を設定してこの問題を解決します。
インスタンスが外部インスタンスの場合は、wal_level=logical を設定します。
これを設定しないと、ERROR: all replication slots are in use と HINT: Free one or increase max_replication_slots の両方が表示されます。
ネイティブ PostgreSQL 論理レプリケーションを設定する
PostgreSQL 10 以降では、PostgreSQL はネイティブの組み込み論理レプリケーションをサポートしています。ネイティブ論理レプリケーションを設定するには、Cloud SQL インスタンスで cloudsql.logical_decoding=on を設定するか、外部インスタンスで wal_level=logical を設定して、プライマリ インスタンスで論理デコーディングを有効にする必要があります。これらのフラグを変更した場合は、プライマリ インスタンスの再起動が必要です。
PostgreSQL インスタンスを構成するセクションを確認し、（ネットワーク接続などで）インスタンスが適切に構成されていることを確認します。このページでは、概念実証の手順について説明します。これらの手順で問題が発生した場合は、pglogical のトラブルシューティングをご覧ください。詳細については、PostgreSQL ドキュメントの論理レプリケーションをご覧ください。
複製するデータを含むテーブルを作成する
ネイティブ PostgreSQL 論理レプリケーションは、データベース全体または個々のテーブルのみをサポートします。たとえば、プライマリ インスタンスでダミーテーブルを作成し、テスト用のデータを入力します。
CREATE TABLE native_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO native_test (data) VALUES ('apple'), ('banana'), ('cherry');
このテーブルをレプリカ インスタンスにも作成する必要があります。
プライマリ インスタンスでパブリケーションを作成する
ネイティブ PostgreSQL 論理レプリケーションはパブリッシャーとサブスクライバーを処理します。native_test にデータのパブリケーションを作成します。
CREATE PUBLICATION pub FOR TABLE native_test;
レプリカ インスタンスにサブスクリプションを作成する
以下に、レプリカ インスタンスにサブスクリプションを作成する例を示します。
CREATE SUBSCRIPTION sub
CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
PUBLICATION pub;
レプリカ インスタンスにサブスクリプションを作成するには、cloudsqlsuperuser ロールが必要です。サブスクリプションを作成したら、native_test テーブルにクエリを実行し、レプリカ インスタンスにデータが存在するかどうか確認します。
プライマリで pg_replication_slots テーブルにクエリを実行すると、サブスクリプションによって作成されたレプリケーション スロットを確認できます。
クリーンアップ
テストが成功したら、DROP
SUBSCRIPTION sub; を使用してレプリカのサブスクリプションを削除します。プライマリでレプリケーション スロットも削除されているか確認します。削除されていなければ、WAL セグメントは引き続きプライマリ インスタンスに蓄積されます。
ネイティブ PostgreSQL 論理レプリケーションの制限
pg_subscription システム テーブルの subconninfo 列にはアクセスできません。
pg_dump を実行すると、接続しているユーザーにスーパーユーザー権限があるかどうか確認されるため、サブスクリプションに関する情報をダンプできません。
変更データ キャプチャ（CDC）用のデコードされた WAL 変更を受信する
CDC の代替方法として、論理デコーディングでは PostgreSQL インスタンスから変更をストリーミングできます。これに使用する標準ツールは pg_recvlogical です。
pg_recvlogical ツールを使用してレプリケーション スロットを作成し、そのスロットによって追跡された変更をストリーミングできます。変更の形式は、選択したデコーディング プラグインによって変わります。次を使用できます。
wal2json（JSON 形式で変更をストリーミングする場合）
test_decoding（ベアボーン テキスト形式でフォーマットされた変更をストリーミングする場合）
レプリケーション スロットを作成する
レプリケーション スロットを作成するには、以下を実行します。
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--create-slot \
-P <decoder_plugin>
ストリームを変更する
1 つの Cloud Shell ターミナルで、以下を実行します。
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--start \
-f -
別の Cloud Shell ターミナルでデータベースに接続し、次のコマンドを実行します。
CREATE TABLE cdc_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO cdc_test (data) VALUES ('apple', 'banana');
UPDATE cdc_test SET data = 'cherry' WHERE id = 2;
DELETE FROM cdc_test WHERE id = 1;
DROP TABLE cdc_test;
wal2json デコーダ プラグインを使用している場合は、最初の Cloud Shell ターミナルに次のような出力が表示されます。
{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[1,"apple"]},{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"banana"]}]}
{"change":[{"kind":"update","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"cherry"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[2]}}]}
{"change":[{"kind":"delete","schema":"public","table":"cdc_test","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[1]}}]}
{"change":[]}
test_decoding デコーダ プラグインを使用している場合は、最初の Cloud Shell ターミナルに次のような出力が表示されます。
BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464
（トランザクション ID は異なる場合があります）
クリーンアップ
テストが完了したら、以下を実行して、作成したレプリケーション スロットを削除します。
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--drop-slot
注意と制限事項
このセクションで説明する注意と制限事項は、Cloud SQL for PostgreSQL の論理レプリケーションとデコーディング機能に適用されます。
pglogical拡張機能は、コネクタ適用が有効になっているインスタンスでは機能しません。この制限は、プライベート サービス アクセスが構成されているインスタンスには適用されません。cloudsql.logical_decodingまたはcloudsql.enable_pglogicalが有効で、現在論理レプリケーションのパブリッシャーとして機能するインスタンスを復元する場合は、すべてのターゲット インスタンスへのレプリケーションを無効にしておく必要があります。この操作を行わないと、インスタンスへの復元に失敗しますが、現時点ではエラーの詳細は表示されません。バックアップの時点で
cloudsql.logical_decodingまたはcloudsql.enable_pglogicalが有効になっているインスタンスのバックアップを新しいインスタンスに復元する場合、レプリケーションの状態は、新しいインスタンスに復元されません。後でレプリケーションを手動で再構成する必要があります。1 つ以上の Cloud SQL リードレプリカがある Cloud SQL インスタンス（物理レプリケーションを使用）で、
cloudsql.logical_decodingまたはcloudsql.enable_pglogicalを有効にすると、これらのフラグもリードレプリカで有効になります。PostgreSQL がリードレプリカの論理デコードをサポートしていないため、Cloud SQL リードレプリカ インスタンスは論理レプリケーションのパブリッシャーとして機能しません。ただし、昇格されたときにプライマリ レプリカの代わりに機能するように、リードレプリカ インスタンスでフラグが有効になっています。
プライマリ インスタンスで
cloudsql.logical_decodingまたはcloudsql.enable_pglogicalを有効にすると、すべてのリードレプリカでフラグが有効になります。これにより、プライマリ レプリカとリードレプリカが連続して再起動します。この状況を回避し、各インスタンスが再起動するタイミングを制御するには、（1）各リードレプリカにフラグを設定して、（2）プライマリ インスタンスにフラグを設定する必要があります。プライマリ インスタンスで
cloudsql.logical_decodingまたはcloudsql.enable_pglogicalを無効にしても、すべてのリードレプリカでフラグが無効になるわけではありません。インスタンス間でフラグを無効にするには、上記のステップと逆の手順を行います。（1）プライマリ インスタンスのフラグを無効にしてから（2）各リードレプリカのフラグを順番に無効にします。