Erweiterte Notfallwiederherstellung mit logischem Failover-Slot

Auf dieser Seite wird beschrieben, wie Sie einen logischen Failover-Slot verwenden, um die logische Replikation von Cloud SQL for PostgreSQL so zu konfigurieren, dass sie nahtlos mit erweiterten Notfallwiederherstellungs-Vorgängen (DR) funktioniert, insbesondere mit Switchover und Replikat-Failover auf Instanzen mit Cloud SQL Enterprise Plus-Edition.

Die erweiterten Funktionen zur Notfallwiederherstellung (Disaster Recovery, DR) von Cloud SQL ermöglichen eine robuste Notfallwiederherstellung. In Kombination mit der logischen Replikation von PostgreSQL ist es entscheidend, dass der Replikationsstream nach einem Switchover oder einem Replica-Failover nicht unterbrochen wird.

Mit der erweiterten Notfallwiederherstellung (Disaster Recovery, DR) und der logischen Replikation von PostgreSQL können Sie sicherstellen, dass bei Ihren logischen Abonnenten kein Datenverlust auftritt und dass sie nach einem Notfallwiederherstellungsereignis automatisch wieder eine Verbindung zur neuen primären Instanz herstellen. So wird die Geschäftskontinuität sichergestellt.

Sie können diese Funktion für Cloud SQL-Instanzen mit der folgenden Konfiguration verwenden:

• PostgreSQL-Version 17 oder höher
• Cloud SQL Enterprise Plus-Version

• Zugriff auf private Dienste

  Wir empfehlen, den DNS-Schreibendpunkt für den Zugriff auf private Dienste zu verwenden, um automatische logische Abonnentenverbindungen zu ermöglichen.

Hinweis

• Installieren Sie die gcloud CLI.

  Sie müssen mindestens Version 502.0.0 verwenden. Führen Sie gcloud --version aus, um die Version des Google Cloud SDK zu ermitteln. Führen Sie zum Aktualisieren des Google Cloud SDK gcloud components update aus.

• Erstellen Sie ein Google Cloud Projekt oder wählen Sie ein vorhandenes Projekt aus.

• Erteilen Sie die erforderlichen IAM-Rollen und -Berechtigungen (Identity and Access Management).

  • Zum Erstellen eines Projekts: Project Creator (roles/resourcemanager.projectCreator)

  • Cloud SQL-Instanzen erstellen und verwalten: Cloud SQL-Administrator (roles/cloudsql.admin)

  • Zum Erstellen und Verwalten von Compute Engine-VMs: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) und Compute Viewer (roles/compute.networkViewer)

  • VPC-Netzwerke erstellen: Netzwerkadministrator (roles/compute.networkAdmin)

  Zur IAM-Seite

  Weitere Informationen finden Sie unter Rollen und Berechtigungen.

  Informationen zum Zuweisen von IAM-Rollen und -Berechtigungen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Erweiterte Notfallwiederherstellung mit logischer Replikation einrichten

Der Prozess zum Einrichten der erweiterten Notfallwiederherstellung (Disaster Recovery, DR) mit der logischen Replikation von PostgreSQL umfasst die folgenden allgemeinen Schritte:

1. Umgebungsvariablen und Bastion-VM einrichten
2. Primäre Instanz erstellen und einrichten
3. DR-Replikat erstellen und festlegen
4. Logische Abonnenteninstanz erstellen und einrichten
5. Abo für die logische Replikation erstellen
6. Switchover oder Replikat-Failover ausführen
7. Validieren Sie die Replikation.
8. Verwaisten Replikationsslot im neuen Replikat bereinigen
9. Optional: Switchback durchführen.

Umgebungsvariablen und Bastion-VM einrichten

1. Legen Sie die folgenden Umgebungsvariablen fest:

   # 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
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: die Projekt-ID.
   • PRIMARY_INSTANCE: Der Name der primären Cloud SQL-Instanz.
   • DR_REPLICA: der Name des Replikats
   • SUBSCRIBER_INSTANCE: der Name der Abonnenteninstanz.
   • BASTION_VM: der Name der Bastion-VM.
   • PRIMARY_REGION: Die Region, in der sich die primäre Instanz befindet.
   • REPLICA_REGION: die Region, in der sich das Replikat befindet. Das Replikat muss sich in einer anderen Region als die primäre Instanz befinden.
   • SUBSCRIBER_REGION: die Region, in der sich der Abonnent befindet.
   • VM_ZONE: die Zone, in der sich die Bastion-VM befindet.
   • NETWORK: der Name des VPC-Netzwerks
   • PASSWORD: das Passwort für den postgres-Nutzer.

2. Erstellen Sie eine Compute Engine-Bastion-VM.

   Cloud SQL-Instanzen verwenden private IP-Adressen. Erstellen Sie daher eine Compute Engine-Bastion Host-VM in Ihrem VPC-Netzwerk.

   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
   

3. Stellen Sie eine Verbindung zur Bastion-VM her.

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

4. Installieren Sie den PostgreSQL-Client auf der Bastion-VM.

   sudo apt-get update
   sudo apt-get install -y postgresql-client
   exit
   

Die PostgreSQL-Befehle in den folgenden Schritten müssen auf der Bastion-VM ausgeführt werden.

Primäre Instanz erstellen und einrichten

1. Primäre Cloud SQL-Instanz erstellen

   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
   

2. Aktivieren Sie die logische Decodierung.

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

3. Legen Sie das Passwort für den Nutzer postgres auf dem primären Profil fest.

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

4. Stellen Sie von der Bastion-VM aus eine Verbindung zur primären Instanz her.

   1. Rufen Sie die private IP-Adresse der primären Instanz ab.

      gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
        --format="value(ipAddresses[0].ipAddress)" \
        --project=$PROJECT
      

      Kopieren und speichern Sie die private IP-Adresse der primären Instanz.

   2. Stellen Sie eine SSH-Verbindung zu Ihrer Bastion-VM her.

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

   3. Stellen Sie von der Bastion-VM aus eine Verbindung zur primären Instanz her.

      psql -h PRIMARY_PRIVATE_IP -U postgres
      

      Ersetzen Sie PRIMARY_PRIVATE_IP durch die private IP-Adresse der primären Instanz, die Sie in Schritt 4a dieses Verfahrens abgerufen haben.

   4. Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie die Variable $POSTGRES_PASSWORD ein.

      Ihre Bastion-VM ist jetzt über PostgreSQL mit der primären Instanz verbunden.

5. Berechtigungen erteilen und Publikation erstellen.

   1. Erteilen Sie dem Nutzer postgres die Berechtigung REPLICATION.

      ALTER USER postgres WITH REPLICATION;
      

   2. Gewähren Sie die erforderlichen Berechtigungen für das öffentliche Schema und die Tabellen.

      GRANT SELECT ON ALL TABLES IN SCHEMA public TO postgres;
      

   3. Erstellen Sie die Publikation für alle Tabellen.

      CREATE PUBLICATION my_publication FOR ALL TABLES;
      

   4. Geben Sie exit ein, um PostgreSQL zu beenden, und dann noch einmal exit, um die SSH-Sitzung der Bastion-VM zu schließen.

Replikat für die Notfallwiederherstellung (DR-Replikat) erstellen und festlegen

1. DR-Replikat erstellen

   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
   

2. Legen Sie dieses Replikat als DR-Replikat fest.

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

3. Konfigurieren Sie das DR-Replikat für die Synchronisierung logischer Slots.

   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
   

4. Konfigurieren Sie die synchrone Replikation zwischen der primären Instanz und dem DR-Replikat.

   Um potenziellen Datenverlust auf dem logischen Abonnenten im Falle eines plötzlichen Ausfalls der primären Instanz und eines anschließenden Replikat-Failovers zu verhindern, empfehlen wir, die synchrone Replikation zwischen der primären Instanz und dem DR-Replikat zu konfigurieren.

   Wenn Sie cloudsql.synchronized_standby_replicas für die primäre Instanz festlegen, wird der WAL-Sender (Write-Ahead Log) für die logische Replikation der primären Instanz gezwungen, zu warten, bis das DR-Replikat das WAL für eine bestimmte Transaktion empfangen und geleert hat, bevor diese Transaktion an den logischen Abonnenten gesendet wird. So wird sichergestellt, dass der Zustand des DR-Replikats immer dem Zustand des logischen Abonnenten entspricht oder ihm voraus ist.

   gcloud sql instances patch $PRIMARY_INSTANCE_NAME \
     --database-flags="^:^cloudsql.logical_decoding=on:cloudsql.synchronized_standby_replicas=$DR_REPLICA_NAME" \
     --project=$PROJECT
   

   Hinweis :Die --database-flags="^:^cloudsql.logical_decoding=on:cloudsql.synchronized_standby_replicas=$DR_REPLICA_NAME" ist entscheidend, um Datenverlust bei einem unerwarteten Replikat-Failover zu verhindern. Der geplante Switchover-Vorgang hat eigene Mechanismen, um sicherzustellen, dass das Replikat vollständig synchronisiert ist, bevor es hochgestuft wird. Dieses Flag ist zwar nicht zwingend für den Wechsel erforderlich, bietet aber eine zusätzliche Sicherheitsebene für alle Notfallwiederherstellungsszenarien.

Logische Abonnenteninstanz erstellen und einrichten

1. Erstellen Sie eine Abonnenteninstanz.

   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
   

2. Aktivieren Sie die logische Decodierung auf dem Abonnenten.

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

Logisches Replikationsabo erstellen

1. Rufen Sie den Schreibendpunkt für den Zugriff auf private Dienste der primären Instanz ab.

   gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
     --format="value(replicationCluster.psaWriteEndpoint)" \
     --project=$PROJECT
   

   Kopieren Sie den Endpunkt für Schreibvorgänge und bewahren Sie ihn auf.

2. Stellen Sie eine Verbindung zur Abonnenteninstanz her.

   1. Aktualisieren Sie das Passwort für den Nutzer postgres der Abonnenteninstanz.

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

   2. Rufen Sie die private IP-Adresse der Abonnenteninstanz ab.

      gcloud sql instances describe $SUBSCRIBER_INSTANCE_NAME \
        --format="value(ipAddresses[0].ipAddress)" \
        --project=$PROJECT
      

      Kopieren Sie die private IP-Adresse und bewahren Sie sie auf.

   3. Stellen Sie eine SSH-Verbindung zur Bastion-VM her.

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

   4. Stellen Sie von der Bastion-VM aus über PostgreSQL eine Verbindung zur Abonnenteninstanz her.

      psql -h SUBSCRIBER_PRIVATE_IP -U postgres
      

      Ersetzen Sie SUBSCRIBER_PRIVATE_IP durch die private IP-Adresse der Abonnenteninstanz, die Sie in Schritt 2b dieses Verfahrens kopiert haben.

   5. Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie die Variable $POSTGRES_PASSWORD ein.

3. Abo erstellen

   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);
   

   Ersetzen Sie Folgendes:

   • DR_CLUSTER_PSA_DNS_WRITE_ENDPOINT: Der Schreibendpunkt für den Zugriff auf private Dienste, den Sie in Schritt 1 dieses Verfahrens kopiert haben.
   • PASSWORD: der Wert der Variablen ${POSTGRES_PASSWORD}.

4. Beenden Sie PostgreSQL und die SSH-Sitzung der Bastion-VM.

5. Optional. Prüfen Sie die Slot-Persistenz auf dem DR-Replikat.

   Die Umstellung auf persistent (temporary = false) erfolgt in der Regel schnell, oft innerhalb von Sekunden, wenn auf dem primären Gerät nur wenig Aktivität stattfindet. Bei hoher Schreiblast auf dem primären Gerät kann dieser Vorgang länger dauern, in der Regel etwa eine Minute. Der Slot sollte nach Ausführung dieser manuellen Befehle bestehen bleiben.

   1. Rufen Sie die private IP-Adresse des DR-Replikats ab.

      gcloud sql instances describe $DR_REPLICA_NAME \
        --format="value(ipAddresses[0].ipAddress)" \
        --project=$PROJECT
      

      Kopieren und speichern Sie die private IP-Adresse des DR-Replikats.

   2. Stellen Sie eine SSH-Verbindung zur Bastion-VM her.

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

   3. Stellen Sie von der Bastion-VM aus eine Verbindung zum DR-Replikat her.

      psql -h DR_REPLICA_PRIVATE_IP -U postgres
      

      Ersetzen Sie DR_REPLICA_PRIVATE_IP durch die private IP-Adresse des DR-Replikats, die Sie in Schritt 5.a dieser Anleitung abgerufen haben.

   4. Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie die Variable $POSTGRES_PASSWORD ein.

   5. Prüfen Sie den Slot-Status.

      SELECT slot_name, slot_type, temporary, failover, synced
      FROM pg_replication_slots
      WHERE slot_type = 'logical' AND failover = true;
      

      Warten Sie, bis die Spalte temporary den Wert f hat. Das dauert in der Regel weniger als eine Minute.

   6. Beenden Sie PostgreSQL und die SSH-Sitzung der Bastion-VM.

Switchover oder Replikat-Failover durchführen

Wählen Sie die gewünschte Operation aus:

• Switchover (geplanter Rollenwechsel): Wählen Sie diese Option für geplante Wartungsarbeiten, Notfallwiederherstellungstests oder zum Wechseln von Rollen aus, wenn die primäre Instanz online und fehlerfrei ist. Bei diesem Vorgang wird sichergestellt, dass bei der physischen Replikation keine Daten verloren gehen.

  gcloud sql instances switchover $DR_REPLICA_NAME \
    --project=$PROJECT
  

  Hinweis :Der Vorgang ist abgeschlossen, wenn der Befehl zurückgegeben wird.

• Replikat-Failover (Notfallwiederherstellung): Wählen Sie diese Option aus, wenn die primäre Instanz nicht verfügbar ist oder nicht reagiert. Bei diesem Vorgang wird das DR-Replikat zur primären Instanz hochgestuft. Um das Risiko eines Datenverlusts für den logischen Abonnenten zu minimieren, muss cloudsql.synchronized_standby_replicas für die primäre Instanz wie in Notfallwiederherstellungsreplikat erstellen und zuweisen empfohlen festgelegt werden.

  gcloud sql instances promote-replica $DR_REPLICA_NAME \
    --failover \
    --project=$PROJECT
  

  Das Hochstufen von $DR_REPLICA_NAME erfolgt schnell. Die ursprüngliche primäre Instanz ($PRIMARY_INSTANCE_NAME) wird jedoch erst als Replikat der neuen primären Instanz neu konfiguriert, wenn sie wieder online ist. Sie können dies im Vorgangsprotokoll nachvollziehen, indem Sie nach dem Abschluss des Vorgangs RECONFIGURE_OLD_PRIMARY für $PRIMARY_INSTANCE_NAME suchen. Führen Sie dazu diesen Befehl aus:

  gcloud sql operations list --instance=$PRIMARY_INSTANCE_NAME --project=$PROJECT --limit=10`
  

  Die Einrichtung der Notfallwiederherstellung wird erst nach Abschluss dieser Phase vollständig wiederhergestellt.

Nach einer der beiden Operationen stellt der Abonnent automatisch über den Schreibendpunkt für den Zugriff auf private Dienste eine Verbindung zum neuen primären $DR_REPLICA_NAME her.

Kennzeichnungen verwalten

Die Workflows von Cloud SQL verwalten die erforderlichen Datenbankflags auf beiden Instanzen im DR-Cluster während und nach dem Switchover und den Replikafailover-Vorgängen automatisch. Dazu gehören:

• Die Synchronisierungs-Flags für logische Slots (cloudsql.logical_decoding, hot_standby_feedback, sync_replication_slots, cloudsql.logical_slot_sync_dbname) sind auf der Instanz, die zum neuen Replikat wird, garantiert korrekt.
• Das cloudsql.synchronized_standby_replicas-Flag für die Instanz, die zur neuen primären Instanz wird, wird automatisch aktualisiert und verweist auf den Namen des neuen DR-Replikats.

Sie müssen diese Flags nach einem Switchover oder Replica-Failover nicht manuell neu anwenden oder ändern. Cloud SQL sorgt für die richtige Konfiguration für die primären und Replikatrollen.

Replikation validieren

1. Prüfen Sie den Status des Abonnenten.

   1. Führen Sie auf der Bastion-VM den folgenden Befehl aus.

      psql -h SUBSCRIBER_PRIVATE_IP -U postgres
      

      Ersetzen Sie SUBSCRIBER_PRIVATE_IP durch die private IP-Adresse der Abonnenteninstanz.

   2. Führen Sie auf der Abonnenteninstanz den folgenden Befehl aus.

      SELECT subname, pid IS NOT NULL AS is_active
      FROM pg_stat_subscription;
      

      Der Status sollte streaming lauten.

2. Prüfen Sie den Status des Replikations-Slots des neuen primären Servers. Der neue primäre Knoten ist das ehemalige DR-Replikat ($DR_REPLICA_NAME).

   1. Rufen Sie die private IP-Adresse des neuen Primärservers ab.

      gcloud sql instances describe $DR_REPLICA_NAME \
        --project=$PROJECT --format="value(ipAddresses[0].ipAddress)"
      

      Kopieren und speichern Sie die private IP-Adresse des neuen Primärservers.

   2. Stellen Sie eine SSH-Verbindung zur Bastion-VM her.

      psql -h NEW_PRIMARY_PRIVATE_IP -U postgres
      

      Ersetzen Sie NEW_PRIMARY_PRIVATE_IP durch die private IP-Adresse des neuen Primärservers, die Sie im vorherigen Schritt kopiert haben.

   3. Führen Sie auf der neuen primären Instanz die folgenden Befehle aus.

      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';
      

      Der Slot (z. B. my_subscription) sollte active = t sein.

      SELECT
          application_name,
          state
      FROM pg_stat_replication;
      

      Unter pg_stat_replication sollte der verbundene Abonnent angezeigt werden.

Verwaisten Replikationsslot im neuen Replikat bereinigen

Nach Abschluss des Switchover- und Failover-Vorgangs ist die ursprüngliche primäre Instanz ($PRIMARY_INSTANCE_NAME) jetzt ein Replikat. Diese neue Replikatinstanz behält den ursprünglichen logischen Replikationsslot mit dem Namen my_subscription auf der Festplatte bei. Dieser my_subscription-Slot ist jetzt verwaist, da der Abonnent über den Schreibendpunkt für den Zugriff auf private Dienste eine Verbindung zum neuen primären Gerät ($DR_REPLICA_NAME) herstellen soll.

Cloud SQL entfernt diesen verwaisten Slot nicht automatisch aus dem neuen Replikat. Das liegt daran, dass Cloud SQL nicht feststellen kann, ob der Abonnent für die Verwendung der IP-Adresse der Instanz anstelle des Schreibendpunkts für den Zugriff auf private Dienste konfiguriert wurde. Der Abonnent versucht möglicherweise weiterhin, eine Verbindung zu diesem alten Slot auf dem neuen Replikat herzustellen, bis das Abo manuell geändert wird. Wenn der Slot automatisch entfernt wird, kann das zu Problemen bei solchen Konfigurationen führen.

Das Vorhandensein dieses verwaisten Slots auf der neuen Replikatinstanz ($PRIMARY_INSTANCE_NAME) führt dazu, dass der slotsync-Worker-Prozess auf dieser Instanz Fehler in den Logs generiert. Möglicherweise wird im postgres.log der neuen Replik eine Fehlermeldung wie die folgende angezeigt. Dieser Fehler wird immer wieder angezeigt, da der slotsync-Worker es immer wieder versucht.

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

Um solche Fehler zu vermeiden und dem slotsync-Worker zu ermöglichen, eine neue synchronisierte Version des my_subscription-Slots auf diesem Replikat zu erstellen, müssen Sie den verwaisten Slot manuell löschen. So wird dafür gesorgt, dass diese Instanz richtig vorbereitet ist, falls Sie in Zukunft wieder zur alten Version wechseln möchten.

1. Rufen Sie die private IP-Adresse des neuen Replikats ($PRIMARY_INSTANCE_NAME) ab.

   gcloud sql instances describe $PRIMARY_INSTANCE_NAME \
     --project=$PROJECT --format="value(ipAddresses[0].ipAddress)"
   

   Kopieren und speichern Sie die private IP-Adresse des neuen Replikats.

2. Stellen Sie eine SSH-Verbindung zur Bastion-VM her.

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

3. Stellen Sie von der Bastion-VM aus eine Verbindung zum neuen Replikat her.

   psql -h NEW_REPLICA_IP -U postgres
   

   Ersetzen Sie NEW_REPLICA_IP durch die IP-Adresse des neuen Replikats, die Sie in Schritt 1 dieses Verfahrens kopiert haben.

4. Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie die Variable $POSTGRES_PASSWORD ein.

5. Entfernen Sie auf dem neuen Replikat ($PRIMARY_INSTANCE_NAME) den verwaisten Slot.

   SELECT slot_name, slot_type, temporary, failover, synced, active
   FROM pg_replication_slots
   WHERE slot_name = 'my_subscription';
   

   Bestätige, dass der Slot mit synced = false und active = false vorhanden ist, und lösche ihn dann.

   SELECT pg_drop_replication_slot('my_subscription');
   

   Der verwaiste Slot wird entfernt.

Automatische Synchronisierung von Zeiträumen

Sobald der verwaiste Slot gelöscht wurde, stellt der slotsync-Worker auf dem neuen Replikat ($PRIMARY_INSTANCE_NAME) in seinem nächsten Zyklus automatisch eine Verbindung zum neuen primären Replikat ($DR_REPLICA_NAME) her. Dadurch wird ein neuer lokaler my_subscription-Slot erstellt, der mit dem aktiven Slot der neuen primären Datenbank synchronisiert wird.

Im postgres.log des neuen Replikats werden Meldungen angezeigt, die den Erfolg bestätigen, ähnlich wie die folgenden:

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

Der neue synchronisierte Slot hat failover=true und wird schließlich persistent (temporary=false). Wenn Sie also später zurückwechseln, ist diese Instanz bereit.

Optional: Switchback durchführen

1. Wechseln Sie nun zurück und machen Sie $PRIMARY_INSTANCE_NAME wieder zur primären Instanz.

   gcloud sql instances switchover $PRIMARY_INSTANCE_NAME \
     --project=$PROJECT
   

2. Führen Sie die Bestätigung nach dem Zurückwechseln durch.

   1. Prüfen Sie den Status der Abonnenteninstanz.

      SELECT subname, pid IS NOT NULL AS is_active
      FROM pg_stat_subscription;
      

      Das Abo sollte noch aktiv sein, d. h. is_active = t.

   2. Prüfen Sie den Status des Slots der neuen primären Instanz ($PRIMARY_INSTANCE_NAME).

      SELECT slot_name, active FROM pg_replication_slots WHERE slot_type = 'logical';
      SELECT * FROM pg_stat_replication;
      

      Der Slot muss aktiv und der Abonnent verbunden sein.

Fehlerbehebung

Problem	Fehlerbehebung
Fehler im neuen Replikat (der alten primären Instanz) nach dem Switchover: "exiting from slot synchronization because same name slot already exists on the standby"	Folgen Sie der Anleitung unter Verwaisten Replikations-Slot auf dem neuen Replikat bereinigen.