Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

論理フェイルオーバースロットを使用した高度な障害復旧（DR）

このページでは、論理フェイルオーバースロットを使用して、Cloud SQL for PostgreSQL の論理レプリケーションを構成し、高度な障害復旧（DR）オペレーション（特に Cloud SQL Enterprise Plus エディションのインスタンスでの切り替えとレプリカフェイルオーバー）とシームレスに連携させる方法について説明します。

Cloud SQL の高度な障害復旧（DR）機能により、堅牢な障害復旧機能が実現します。PostgreSQL の論理レプリケーションと組み合わせる場合は、スイッチオーバーまたはレプリカフェイルオーバー後にレプリケーションストリームが途切れないようにすることが重要です。

PostgreSQL の論理レプリケーションで高度な障害復旧（DR）を使用すると、論理サブスクライバーでデータ損失が発生せず、障害復旧イベント後に新しいプライマリインスタンスに自動的に再接続されるため、ビジネスの継続性を確保できます。

この機能は、次の構成の Cloud SQL インスタンスで使用できます。

PostgreSQL バージョン 17 以降
Cloud SQL Enterprise Plus エディション
プライベートサービスアクセス

プライベートサービスアクセスドメイン名サービス（DNS）書き込みエンドポイントを使用して、論理サブスクライバーの自動再接続を有効にすることをおすすめします。

始める前に

gcloud CLI をインストールします。

バージョン 502.0.0 以降を使用する必要があります。Google Cloud SDK のバージョンを確認するには、gcloud --version を実行します。Google Cloud SDK を更新するには、gcloud components update を実行します。
Google Cloud プロジェクトを作成するか、既存のプロジェクトを使用します。
必要な Identity and Access Management（IAM）のロールと権限を付与します。
- プロジェクトを作成する: プロジェクト作成者（roles/resourcemanager.projectCreator）
- Cloud SQL インスタンスを作成して管理する: Cloud SQL 管理者（roles/cloudsql.admin）
- Compute Engine VM を作成して管理する: Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）と Compute 閲覧者（roles/compute.networkViewer）
- VPC ネットワークを作成する: ネットワーク管理者（roles/compute.networkAdmin）
[IAM] ページに移動

詳細については、ロールと権限をご覧ください。

IAM ロールと権限を付与する方法については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

論理レプリケーションを使用して高度な障害復旧（DR）を設定する

PostgreSQL の論理レプリケーションを使用して高度な障害復旧（DR）を設定する手順は、おおまかに次のとおりです。

環境変数と要塞 VM を設定します。
プライマリインスタンスを作成して設定する。
DR レプリカを作成して指定する。
論理サブスクライバーインスタンスを作成して設定する。
論理レプリケーションサブスクリプションを作成する。
スイッチオーバーまたはレプリカフェイルオーバーを実行する。
レプリケーションを検証します。
新しいレプリカで孤立したレプリケーションスロットをクリーンアップします。
省略可: スイッチバックを実行します。

環境変数と要塞 VM を設定する

次の環境変数を設定します。
```
# Project
export PROJECT="PROJECT_ID"

# Instance names
export PRIMARY_INSTANCE_NAME="PRIMARY_INSTANCE"
export DR_REPLICA_NAME="DR_REPLICA"
export SUBSCRIBER_INSTANCE_NAME="SUBSCRIBER_INSTANCE"
export BASTION_VM_NAME="BASTION_VM"

# Regions and zones
export PRIMARY_REGION="PRIMARY_REGION"
export REPLICA_REGION="REPLICA_REGION"
export SUBSCRIBER_REGION="SUBSCRIBER_REGION"
export VM_ZONE="VM_ZONE"

# Network
export NETWORK_NAME="NETWORK"

# Credentials
export POSTGRES_PASSWORD="PASSWORD"

# Set gcloud project
gcloud config set project PROJECT_ID
```
次のように置き換えます。
- PROJECT_ID: 実際のプロジェクトの ID。
- PRIMARY_INSTANCE: プライマリ Cloud SQL インスタンスの名前。
- DR_REPLICA: レプリカの名前。
- SUBSCRIBER_INSTANCE: サブスクライバーインスタンスの名前。
- BASTION_VM: 踏み台 VM の名前。
- PRIMARY_REGION: プライマリインスタンスが配置されているリージョン。
- REPLICA_REGION: レプリカが配置されているリージョン。レプリカは、プライマリインスタンスとは異なるリージョンに存在する必要があります。
- SUBSCRIBER_REGION: サブスクライバーが配置されているリージョン。
- VM_ZONE: 要塞 VM が配置されているゾーン。
- NETWORK: VPC ネットワークの名前。
- PASSWORD: postgres ユーザーのパスワード。

Compute Engine 踏み台 VM を作成します。

Cloud SQL インスタンスはプライベート IP を使用します。そのため、VPC ネットワークに Compute Engine 踏み台インスタンス VM を作成します。

gcloud compute instances create $BASTION_VM_NAME \
  --zone=$VM_ZONE \
  --machine-type=e2-small \
  --network=projects/$PROJECT_ID/global/networks/$NETWORK_NAME \
  --image-project=debian-cloud \
  --image-family=debian-11 \
  --project=$PROJECT

踏み台 VM に接続します。

gcloud compute ssh $BASTION_VM_NAME \
  --zone=$VM_ZONE \
  --project=$PROJECT

要塞 VM に PostgreSQL クライアントをインストールします。
```
sudo apt-get update
sudo apt-get install -y postgresql-client
exit
```

以降の手順の PostgreSQL コマンドは、要塞 VM から実行します。

プライマリインスタンスを作成して設定する

プライマリ Cloud SQL インスタンスを作成します。

gcloud sql instances create $PRIMARY_INSTANCE_NAME \
  --database-version=POSTGRES_17 \
  --edition=ENTERPRISE_PLUS \
  --region=$PRIMARY_REGION \
  --tier=db-perf-optimized-N-2 \
  --no-assign-ip \
  --network=projects/$PROJECT/global/networks/$NETWORK_NAME \
  --project=$PROJECT

論理デコードを有効にします。

gcloud sql instances patch $PRIMARY_INSTANCE_NAME \
  --database-flags=cloudsql.logical_decoding=on \
  --project=$PROJECT

プライマリの postgres ユーザーのパスワードを設定します。

gcloud sql users set-password postgres \
  --instance=$PRIMARY_INSTANCE_NAME \
  --password="$POSTGRES_PASSWORD" \
  --project=$PROJECT

踏み台 VM からプライマリインスタンスに接続します。
1. プライマリインスタンスのプライベート IP アドレスを取得します。
```
gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
  --format="value(ipAddresses[0].ipAddress)" \
  --project=$PROJECT
```
  プライマリインスタンスのプライベート IP アドレスをコピーして保存します。
2. 踏み台 VM に SSH で接続します。
```
gcloud compute ssh $BASTION_VM_NAME --zone=$VM_ZONE --project=$PROJECT
```
3. 踏み台 VM からプライマリインスタンスに接続します。
```
psql -h PRIMARY_PRIVATE_IP -U postgres
```
  PRIMARY_PRIVATE_IP は、この手順のステップ 4.a で取得したプライマリインスタンスのプライベート IP に置き換えます。
4. パスワードの入力を求められたら、変数 $POSTGRES_PASSWORD を入力します。
  
  これで、PostgreSQL を介して、踏み台 VM がプライマリインスタンスに接続されました。
権限を付与してパブリケーションを作成します。
1. postgres ユーザーに REPLICATION 権限を付与します。
```
ALTER USER postgres WITH REPLICATION;
```
2. public スキーマとテーブルに必要な権限を付与します。
```
GRANT SELECT ON ALL TABLES IN SCHEMA public TO postgres;
```
3. すべてのテーブルのパブリケーションを作成します。
```
CREATE PUBLICATION my_publication FOR ALL TABLES;
```
4. 「exit」と入力して PostgreSQL を終了し、もう一度「exit」と入力して要塞 VM の SSH セッションを閉じます。

障害復旧レプリカ（DR レプリカ）を作成して指定する

DR レプリカを作成します。

gcloud sql instances create $DR_REPLICA_NAME \
  --master-instance-name=$PRIMARY_INSTANCE_NAME \
  --edition=ENTERPRISE_PLUS \
  --tier=db-perf-optimized-N-2 \
  --region=$REPLICA_REGION \
  --no-assign-ip \
  --network=projects/$PROJECT/global/networks/$NETWORK_NAME \
  --project=$PROJECT

このレプリカを DR レプリカとして指定します。

gcloud sql instances patch $PRIMARY_INSTANCE_NAME \
  --failover-dr-replica-name=$DR_REPLICA_NAME \
  --project=$PROJECT

論理スロットの同期用に DR レプリカを構成します。

gcloud sql instances patch $DR_REPLICA_NAME \
  --database-flags="^:^cloudsql.logical_decoding=on:hot_standby_feedback=on:sync_replication_slots=on:cloudsql.logical_slot_sync_dbname=postgres" \
  --project=$PROJECT

プライマリインスタンスと DR レプリカ間の同期レプリケーションを構成します。

プライマリインスタンスの突然の停止と、それに続くレプリカのフェイルオーバーが発生した場合に、論理サブスクライバーでデータ損失が発生する可能性を防ぐため、プライマリインスタンスと DR レプリカ間の同期レプリケーションを構成することをおすすめします。

プライマリインスタンスで cloudsql.synchronized_standby_replicas を設定すると、プライマリインスタンスの論理レプリケーション先行書き込みログ（WAL）送信者は、DR レプリカが特定のトランザクションの WAL を受信してフラッシュするまで待機してから、そのトランザクションを論理サブスクライバーに送信します。これにより、DR レプリカの状態は常に論理サブスクライバーの状態以上になります。
```
gcloud sql instances patch $PRIMARY_INSTANCE_NAME \
  --database-flags="^:^cloudsql.logical_decoding=on:cloudsql.synchronized_standby_replicas=$DR_REPLICA_NAME" \
  --project=$PROJECT
```
注: --database-flags="^:^cloudsql.logical_decoding=on:cloudsql.synchronized_standby_replicas=$DR_REPLICA_NAME" は、予期しないレプリカフェイルオーバー時のデータ損失を防ぐために重要です。計画された切り替えオペレーションには、レプリカを昇格させる前に完全に同期させるための独自のメカニズムがあります。このフラグは切り替えに必須ではありませんが、すべての障害復旧シナリオで安全性を高めることができます。

論理サブスクライバーインスタンスを作成して設定する

サブスクライバーインスタンスを作成します。

gcloud sql instances create $SUBSCRIBER_INSTANCE_NAME \
  --database-version=POSTGRES_17 \
  --tier=db-perf-optimized-N-2 \
  --region=$SUBSCRIBER_REGION \
  --no-assign-ip \
  --network=projects/$PROJECT/global/networks/$NETWORK_NAME \
  --project=$PROJECT

サブスクライバーで論理デコードを有効にします。

gcloud sql instances patch $SUBSCRIBER_INSTANCE_NAME \
  --database-flags=cloudsql.logical_decoding=on \
  --project=$PROJECT

論理レプリケーションサブスクリプションを作成する

プライマリインスタンスのプライベートサービスアクセス書き込みエンドポイントを取得します。
```
gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
  --format="value(replicationCluster.psaWriteEndpoint)" \
  --project=$PROJECT
```
書き込みエンドポイントをコピーして保持します。
サブスクライバーインスタンスに接続します。
1. サブスクライバーインスタンスの postgres ユーザーのパスワードを更新します。
```
gcloud sql users set-password postgres \
  --instance=$SUBSCRIBER_INSTANCE_NAME \
  --password="$POSTGRES_PASSWORD" \
  --project=$PROJECT
```
2. サブスクライバーインスタンスのプライベート IP アドレスを取得します。
```
gcloud sql instances describe $SUBSCRIBER_INSTANCE_NAME \
  --format="value(ipAddresses[0].ipAddress)" \
  --project=$PROJECT
```
  プライベート IP アドレスをコピーして保存します。
3. 踏み台 VM に SSH で接続します。
```
gcloud compute ssh $BASTION_VM_NAME \
  --zone=$VM_ZONE \
  --project=$PROJECT
```
4. PostgreSQL を介して、要塞 VM からサブスクライバーインスタンスに接続します。
```
psql -h SUBSCRIBER_PRIVATE_IP -U postgres
```
  SUBSCRIBER_PRIVATE_IP は、この手順のステップ 2.b でコピーしたサブスクライバーインスタンスのプライベート IP に置き換えます。
5. パスワードの入力を求められたら、変数 $POSTGRES_PASSWORD を入力します。
サブスクリプションを作成します。
```
CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=DR_CLUSTER_PSA_DNS_WRITE_ENDPOINT port=5432 dbname=postgres user=postgres password=PASSWORD'
PUBLICATION my_publication
WITH (failover = true);
```
次のように置き換えます。
- DR_CLUSTER_PSA_DNS_WRITE_ENDPOINT: この手順のステップ 1 でコピーしたプライベートサービスアクセスの書き込みエンドポイント。
- PASSWORD: 変数 ${POSTGRES_PASSWORD} の値。
PostgreSQL と要塞 VM の SSH セッションを終了します。
省略可。DR レプリカでスロットの永続性を確認します。

この永続化（temporary = false）への移行は通常、迅速に行われます。プライマリの活動が少ない場合は、数秒以内に行われることがよくあります。プライマリに書き込み負荷が高い場合、このプロセスには通常 1 分ほどかかります。これらの手動コマンドを完了すると、スロットは永続的になります。
1. DR レプリカのプライベート IP アドレスを取得します。
```
gcloud sql instances describe $DR_REPLICA_NAME \
  --format="value(ipAddresses[0].ipAddress)" \
  --project=$PROJECT
```
  DR レプリカのプライベート IP アドレスをコピーして保存します。
2. 踏み台 VM に SSH で接続します。
```
gcloud compute ssh $BASTION_VM_NAME \
  --zone=$VM_ZONE \
  --project=$PROJECT
```
3. 踏み台 VM から DR レプリカに接続します。
```
psql -h DR_REPLICA_PRIVATE_IP -U postgres
```
  DR_REPLICA_PRIVATE_IP は、この手順のステップ 5.a で取得した DR レプリカのプライベート IP アドレスに置き換えます。
4. パスワードの入力を求められたら、変数 $POSTGRES_PASSWORD を入力します。
5. スロットのステータスを確認します。
```
SELECT slot_name, slot_type, temporary, failover, synced
FROM pg_replication_slots
WHERE slot_type = 'logical' AND failover = true;
```
  temporary 列が f になるまで待ちます。通常、この処理は 1 分以内に完了します。
6. PostgreSQL と要塞 VM の SSH セッションを終了します。

スイッチオーバーまたはレプリカフェイルオーバーを実行する

シナリオに基づいて、実行するオペレーションを選択します。

スイッチオーバー（計画的なロールの反転）: 計画的なメンテナンス、障害復旧テスト、プライマリインスタンスがオンラインで正常な場合にロールを切り替える場合は、これを選択します。このオペレーションにより、物理レプリケーションでデータ損失が発生しないことが保証されます。
```
gcloud sql instances switchover $DR_REPLICA_NAME \
  --project=$PROJECT
```
注: コマンドが返されたら、オペレーションは完了です。
レプリカフェイルオーバー（障害復旧）: プライマリインスタンスが使用できない場合や応答しない場合に選択します。このオペレーションにより、DR レプリカがプライマリに昇格します。論理サブスクライバーのデータ損失のリスクを最小限に抑えるには、障害復旧レプリカ（DR レプリカ）を作成して指定するで推奨されているように、プライマリインスタンスに cloudsql.synchronized_standby_replicas が設定されていることを確認してください。
```
gcloud sql instances promote-replica $DR_REPLICA_NAME \
  --failover \
  --project=$PROJECT
```
$DR_REPLICA_NAME のプロモーションは迅速に行われます。ただし、元のプライマリインスタンス（$PRIMARY_INSTANCE_NAME）は、オンラインに戻った後にのみ、新しいプライマリのレプリカとして再構成されます。オペレーションログで $PRIMARY_INSTANCE_NAME の RECONFIGURE_OLD_PRIMARY オペレーションが完了したかどうかを確認することで、これを追跡できます。次のコマンドを実行します。
```
gcloud sql operations list --instance=$PRIMARY_INSTANCE_NAME --project=$PROJECT --limit=10`
```
このフェーズが完了した後にのみ、障害復旧の設定が完全に復元されます。

どちらのオペレーションの後でも、サブスクライバーはプライベートサービスアクセス書き込みエンドポイントを介して新しいプライマリ $DR_REPLICA_NAME に自動的に再接続します。

フラグの管理

Cloud SQL のワークフローは、切り替えとレプリカフェイルオーバーのオペレーション中とオペレーション後に、障害復旧クラスタ内の両方のインスタンスで必要なデータベースフラグを自動的に管理します。これには次のものが含まれます。

論理スロット同期フラグ（cloudsql.logical_decoding、hot_standby_feedback、sync_replication_slots、cloudsql.logical_slot_sync_dbname）は、新しいレプリカになるインスタンスで正しく設定されます。
新しいプライマリになるインスタンスの cloudsql.synchronized_standby_replicas フラグは、新しい DR レプリカの名前を指すように自動的に更新されます。

スイッチオーバーまたはレプリカフェイルオーバーオペレーション後に、これらのフラグを手動で再適用または変更する必要はありません。Cloud SQL は、プライマリロールとレプリカロールの正しい構成を維持します。

レプリケーションを検証する

登録者のステータスを確認します。
1. 踏み台 VM から、次のコマンドを実行します。
```
psql -h SUBSCRIBER_PRIVATE_IP -U postgres
```
  SUBSCRIBER_PRIVATE_IP は、サブスクライバーインスタンスのプライベート IP アドレスに置き換えます。
2. サブスクライバーインスタンスで、次のコマンドを実行します。
```
SELECT subname, pid IS NOT NULL AS is_active
FROM pg_stat_subscription;
```
  ステータスは streaming である必要があります。
新しいプライマリのレプリケーションスロットのステータスを確認します。新しいプライマリは、以前の DR レプリカ（$DR_REPLICA_NAME）です。
1. 新しいプライマリのプライベート IP アドレスを取得します。
```
gcloud sql instances describe $DR_REPLICA_NAME \
  --project=$PROJECT --format="value(ipAddresses[0].ipAddress)"
```
  新しいプライマリのプライベート IP アドレスをコピーして保存します。
2. 踏み台 VM に SSH で接続します。
```
psql -h NEW_PRIMARY_PRIVATE_IP -U postgres
```
  NEW_PRIMARY_PRIVATE_IP は、前の手順でコピーした新しいプライマリのプライベート IP アドレスに置き換えます。
3. 新しいプライマリインスタンスで、次のコマンドを実行します。
```
SELECT
    slot_name,
    slot_type,
    active,
    synced,
    active_pid,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS replication_lag
FROM pg_replication_slots
WHERE slot_type = 'logical';
```
  スロット（my_subscription など）は active = t である必要があります。
```
SELECT
    application_name,
    state
FROM pg_stat_replication;
```
  pg_stat_replication に、接続されているサブスクライバーが表示されます。

新しいレプリカで孤立したレプリケーションスロットをクリーンアップする

切り替えとフェイルオーバーのオペレーションが完了すると、元のプライマリインスタンス（$PRIMARY_INSTANCE_NAME）はレプリカになります。この新しいレプリカインスタンスは、ディスク上の my_subscription という名前の元の論理レプリケーションスロットを保持しています。サブスクライバーはプライベートサービスアクセス書き込みエンドポイントを介して新しいプライマリ（$DR_REPLICA_NAME）に接続することが想定されているため、この my_subscription スロットは孤立しています。

Cloud SQL は、この孤立したスロットを新しいレプリカから自動的に削除しません。これは、Cloud SQL が、サブスクライバーがプライベートサービスアクセス書き込みエンドポイントではなくインスタンスの IP アドレスを使用するように構成されているかどうかを判断できないためです。サブスクリプションが手動で変更されるまで、サブスクライバーは新しいレプリカの古いスロットへの接続を試行し続ける可能性があります。スロットを自動的に削除すると、このような構成が破損する可能性があります。

新しいレプリカ（$PRIMARY_INSTANCE_NAME）にこの孤立したスロットが存在すると、このインスタンスの slotsync ワーカープロセスでログにエラーが生成されます。新しいレプリカの postgres.log に、次のようなエラーメッセージが表示されることがあります。このエラーは、slotsync ワーカーが再試行を続ける限り繰り返されます。

ERROR: exiting from slot synchronization because same name slot "my_subscription" already exists on the standby

このようなエラーを防ぎ、slotsync ワーカーがこのレプリカの my_subscription スロットの新しい同期バージョンを正しく確立できるようにするには、孤立したスロットを手動で削除する必要があります。これにより、将来的にスイッチバックを行う場合に、このインスタンスが適切に準備されます。

新しいレプリカのプライベート IP アドレス（$PRIMARY_INSTANCE_NAME）を取得します。
```
gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
  --project=$PROJECT --format="value(ipAddresses[0].ipAddress)"
```
新しいレプリカのプライベート IP アドレスをコピーして保存します。

踏み台 VM に SSH で接続します。

gcloud compute ssh $BASTION_VM_NAME \
  --zone=$VM_ZONE \
  --project=$PROJECT

踏み台 VM から、新しいレプリカに接続します。
```
psql -h NEW_REPLICA_IP -U postgres
```
NEW_REPLICA_IP は、この手順のステップ 1 でコピーした新しいレプリカの IP アドレスに置き換えます。
パスワードの入力を求められたら、変数 $POSTGRES_PASSWORD を入力します。
新しいレプリカ（$PRIMARY_INSTANCE_NAME）で、孤立したスロットを削除します。
```
SELECT slot_name, slot_type, temporary, failover, synced, active
FROM pg_replication_slots
WHERE slot_name = 'my_subscription';
```
スロットが synced = false と active = false で存在することを確認してから、ドロップします。
```
SELECT pg_drop_replication_slot('my_subscription');
```
孤立したスロットが削除されます。

自動スロット再同期

孤立したスロットが削除されると、新しいレプリカ（$PRIMARY_INSTANCE_NAME）の slotsync ワーカーは、次のサイクルで新しいプライマリ（$DR_REPLICA_NAME）に自動的に接続します。新しいプライマリのアクティブスロットと同期される新しいローカル my_subscription スロットが作成されます。

新しいレプリカの postgres.log に、次のような成功を示すメッセージが表示されます。

LOG: newly created slot "my_subscription" is sync-ready now

新しい同期スロットには failover=true があり、最終的に永続的（temporary=false）になります。これにより、後で切り替えても、このインスタンスは準備完了になります。

省略可: スイッチバックを実行する

次に、$PRIMARY_INSTANCE_NAME を再びプライマリインスタンスにして、切り替えます。
```
gcloud sql instances switchover $PRIMARY_INSTANCE_NAME \
  --project=$PROJECT
```
スイッチバック後に検証を行います。
1. サブスクライバーインスタンスのステータスを確認します。
```
SELECT subname, pid IS NOT NULL AS is_active
FROM pg_stat_subscription;
```
  サブスクリプションは引き続き有効（is_active = t）である必要があります。
2. 新しいプライマリ（$PRIMARY_INSTANCE_NAME）のスロットのステータスを確認します。
```
SELECT slot_name, active FROM pg_replication_slots WHERE slot_type = 'logical';
SELECT * FROM pg_stat_replication;
```
  スロットはアクティブで、サブスクライバーが接続されている必要があります。

トラブルシューティング

問題トラブルシューティング

問題	トラブルシューティング
切り替え後の新しいレプリカ（つまり、古いプライマリインスタンス）のエラー: `"exiting from slot synchronization because same name slot already exists on the standby"`	新しいレプリカで孤立したレプリケーションスロットをクリーンアップするの手順に沿って操作します。

切り替え後の新しいレプリカ（つまり、古いプライマリインスタンス）のエラー:

"exiting from slot synchronization because same name slot already exists on the standby"

新しいレプリカで孤立したレプリケーションスロットをクリーンアップするの手順に沿って操作します。