Erweiterte Notfallwiederherstellung (Disaster Recovery, DR) verwenden

Auf dieser Seite wird die Verwendung der erweiterten Notfallwiederherstellung (Disaster Recovery, DR) beschrieben. Die erweiterte Notfallwiederherstellung bietet zwei Hauptfunktionen:

  • Mit dem Replikat-Failover können Sie bei einem regionalen Ausfall ein Failover von Ihrer primären Instanz auf das DR-Replikat ausführen.
  • Mit Switchover können Sie die Rollen der primären Instanz und eines DR-Replikats ohne Datenverlust umkehren. Mit Switchover können Sie eine Bereitstellung nach dem Replikat-Failover in ihren ursprünglichen Bereitstellungsstatus wiederherstellen oder die Notfallwiederherstellung mit Switchover testen.

Die erweiterte Notfallwiederherstellung wird nur auf Cloud SQL Enterprise Plus-Instanzen unterstützt.

Hinweise

Wenn Sie das Google Cloud SDK verwenden möchten, müssen Sie Version 470.0.0 oder höher und gcloud beta-Befehle verwenden. Führen Sie gcloud --version aus, um die Version des Google Cloud SDK zu ermitteln. Führen Sie zum Initialisieren des Google Cloud SDK gcloud components update aus:

Informationen zum Installieren des Google Cloud SDK finden Sie unter Installieren der gcloud CLI.

DR-Replikat bestimmen

Um eine erweiterte Notfallwiederherstellung durchzuführen, müssen Sie zuerst ein regionenübergreifendes DR-Replikat festlegen.

Anforderungen an das DR-Replikat

Das festgelegte DR-Lesereplikat muss die folgenden Anforderungen erfüllen:

  • Muss eine Cloud SQL Enterprise Plus-Instanz sein
  • Muss dieselbe Haupt- und Nebenversion der Datenbank wie die primäre Instanz sein, auf der MySQL 8.0.31 oder höher ausgeführt wird
  • Muss sich in einer anderen Region als die primäre Instanz befinden
  • Muss ein direktes Lesereplikat sein Darf kein kaskadierendes Replikat sein
  • Neben den Standardwerten kann für das DR-Replikat keines der folgenden Flags konfiguriert werden:
    • replicate_do_db
    • replicate_ignore_db
    • replicate_do_table
    • replicate_wild_do_table
    • replicate_ignore_table
    • replicate_wild_ignore_table
  • Muss die für PITR verwendeten Transaktionslogs in Cloud Storage speichern
  • Darf kein externes Replikat sein

Empfehlungen für das Replikat für Notfallwiederherstellung

Dieser Abschnitt enthält Empfehlungen für das DR-Replikat. Die folgenden Empfehlungen können helfen, Leistungsprobleme in Ihrer Bereitstellung zu vermeiden:

  • Verwenden Sie dieselbe Laufwerkgröße wie die primäre Instanz oder aktivieren Sie die automatische Vergrößerung.
  • Verwenden Sie eine konsistente Hochverfügbarkeitskonfiguration. Wenn Sie Hochverfügbarkeit auf der primären Instanz aktivieren, aktivieren Sie auch Hochverfügbarkeit auf dem DR-Replikat.
  • Verwenden Sie eine konsistente Datencache-Konfiguration. Wenn Sie den Datencache auf der primären Instanz aktivieren, müssen Sie auch den Datencache auf dem DR-Replikat aktivieren.
  • Konfigurieren Sie alle geeigneten Datenbank-Flags für Ihr DR-Replikat vor und nach Switchover- oder Replikat-Failover-Vorgängen.

Replikat erstellen, um die Anforderungen für DR-Replikate zu erfüllen

Wenn die primäre Instanz noch kein regionenübergreifendes Lesereplikat hat, das die Anforderungen der DR-Replikatdatenbank erfüllt, erstellen Sie eins.

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie die primäre Instanz.
  3. Klicken Sie in der Spalte Aktionenauf das Menü Weitere Aktionen.
  4. Wählen Sie Lesereplikat erstellen aus.
  5. Geben Sie im Feld Instanz-ID einen Namen für das DR-Replikat ein.
  6. Im Feld Datenbankversion ist MySQL 8.0 bereits ausgewählt.
  7. Übernehmen Sie im Feld Nebenversion die vorab ausgewählte Nebenversion. Das DR-Replikat und die primäre Instanz müssen dieselbe Datenbank-Nebenversion haben.
  8. Führen Sie im Abschnitt Region und zonale Verfügbarkeit auswählen der Seite die folgenden Schritte aus:
    • Wählen Sie eine andere Region als die Region Ihrer primären Instanz aus.
    • Optional. Wählen Sie Mehrere Zonen für das DR-Replikat aus.
    • Optional. Wählen Sie die primären und sekundären Zonen für das DR-Replikat aus.
  9. Im Bereich Instanz anpassen der Seite können Sie die Einstellungen für das DR-Replikat ändern. Weitere Informationen zu den einzelnen Einstellungen finden Sie auf der Seite zu den Instanzeinstellungen.
  10. Wählen Sie unter Maschinenformen den gleichen Maschinentyp wie Ihre primäre Instanz aus.
  11. Konfigurieren Sie unter Flags alle Flags, die für Ihre Datenbank erforderlich sind.
  12. Klicken Sie auf Replikat erstellen.

Cloud SQL erstellt eine Sicherung der primären Instanz und das Replikat. Sie werden dann zur Instanzseite der primären Instanz zurückgeleitet.

gcloud

Führen Sie den folgenden Befehl aus, um ein Replikat zu erstellen, das die Anforderungen eines DR-Replikats erfüllt:

gcloud sql instances create REPLICA_NAME \
   --master-instance-name=PRIMARY_INSTANCE_NAME \
   --region=REPLICA_REGION_NAME \
   --database-version=DATABASE_VERSION \
   --tier=MACHINE_TYPE \
   --availability-type=AVAILABILITY_TYPE
   --edition="ENTERPRISE_PLUS"

Ersetzen Sie die folgenden Variablen:

  • REPLICA_NAME: der Name des DR-Replikats
  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • REPLICA_REGION_NAME: Geben Sie eine Region an, die sich von der Region der primären Instanz unterscheidet.
  • DATABASE_VERSION: Geben Sie den Versionsstring an, der mit der Haupt- und Nebenversion der Datenbank der primären Instanz übereinstimmt, z. B. MYSQL_8_0_31.

    Die Haupt- und Nebenversionen der Datenbank müssen für das primäre und das DR-Replikat identisch sein.

  • MACHINE_TYPE: Geben Sie denselben Maschinentyp wie die primäre Instanz an. Der Maschinentyp sollte mit dem Maschinentyp der primären Instanz übereinstimmen.
  • AVAILABILITY_TYPE: Wenn die primäre Instanz für Hochverfügbarkeit konfiguriert ist, empfehlen wir, REGIONAL anzugeben, um Hochverfügbarkeit zu aktivieren.
  • EDITION: Geben Sie ENTERPRISE_PLUS an.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • DATABASE_VERSION:-Versionsstring, der mit der Haupt- und Nebenversion der Datenbank der primären Instanz übereinstimmt, z. B. MYSQL_8_0_31. Die Haupt- und Nebenversionen der Datenbank müssen für das primäre und das DR-Replikat identisch sein.
  • REPLICA_NAME: der Name der DR-Replikatinstanz, die Sie erstellen
  • REPLICA_REGION: die Region der DR-Replikatinstanz Die Replikatregion muss sich von der Region der primären Instanz unterscheiden.
  • MACHINE_TYPE: Geben Sie denselben Maschinentyp wie die primäre Instanz an. Es wird empfohlen, denselben Maschinentyp wie die primäre Instanz auszuwählen.
  • AVAILABILITY_TYPE: Wenn die primäre Instanz für Hochverfügbarkeit konfiguriert ist, empfehlen wir, REGIONAL anzugeben, um Hochverfügbarkeit zu aktivieren.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

JSON-Text anfordern:

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • DATABASE_VERSION:-Versionsstring, der mit der Haupt- und Nebenversion der Datenbank der primären Instanz übereinstimmt, z. B. MYSQL_8_0_31. Die Haupt- und Nebenversionen der Datenbank müssen für das primäre und das DR-Replikat identisch sein.
  • REPLICA_NAME: der Name der DR-Replikatinstanz, die Sie erstellen
  • REPLICA_REGION: die Region der DR-Replikatinstanz Die Replikatregion muss sich von der Region der primären Instanz unterscheiden.
  • MACHINE_TYPE: Geben Sie denselben Maschinentyp wie die primäre Instanz an. Wir empfehlen, dass die Laufwerksgröße mit der Laufwerksgröße der primären Instanz übereinstimmt.
  • AVAILABILITY_TYPE: Wenn die primäre Instanz für Hochverfügbarkeit konfiguriert ist, empfehlen wir, REGIONAL anzugeben, um Hochverfügbarkeit zu aktivieren.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances

JSON-Text anfordern:

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

DR-Replikat für die primäre Instanz festlegen

Im Folgenden wird beschrieben, wie Sie eines der regionenübergreifenden Replikate einer primären Instanz als DR-Replikat für das Switchover oder das Replikat-Failover festlegen.

Console

So legen Sie ein DR-Replikat für eine primäre Instanz fest:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
  3. Klicken Sie im Navigationsmenü auf Replikate.
  4. Suchen Sie in der Liste der Lesereplikate das regionenübergreifende Lesereplikat, das Sie als DR-Replikat festlegen möchten.
  5. Klicken Sie für das Replikat auf die Schaltfläche more_vert Aktionen und wählen Sie Als DR-Replikat festlegen aus.
  6. Klicken Sie auf Bestätigen.

gcloud

Verwenden Sie den folgenden Befehl, um ein DR-Replikat zu einer primären Instanz festzulegen:

gcloud beta sql instances patch PRIMARY_INSTANCE_NAME \
   --failover-dr-replica-name=REPLICA_NAME

Ersetzen Sie die folgenden Variablen:

  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • REPLICA_NAME: der Name des DR-Replikats

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Kennzeichnung des DR-Replikats ändern

Wenn das Replikat die Anforderungen erfüllt, können Sie ein anderes Replikat als DR-Replikat festlegen. Das alte DR-Replikat verliert die Kennzeichnung des DR-Replikats.

Console

So ändern Sie das DR-Replikat für eine primäre Instanz:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
  3. Klicken Sie im Navigationsmenü auf Replikate.
  4. Suchen Sie in der Liste der Lesereplikate das regionenübergreifende Lesereplikat, das Sie als neues DR-Replikat festlegen möchten.
  5. Klicken Sie für das Replikat auf die Schaltfläche more_vert Aktionen und wählen Sie Als DR-Replikat festlegen aus.

gcloud

Wenn Sie das DR-Replikat ändern möchten, führen Sie den Befehl noch einmal aus und geben Sie ein anderes DR-Replikat an.

REST

Wenn Sie das DR-Replikat ändern möchten, stellen Sie die API-Anfrage noch einmal und geben Sie ein anderes DR-Replikat an.

Kennzeichnung des DR-Replikats ansehen

Mit der gcloud CLI oder der Cloud SQL Admin API können Sie prüfen, welches DR-Replikat der primären Instanz zugewiesen ist. Sie können auch prüfen, ob ein Replikat ein festgelegtes DR-Replikat ist.

Gehen Sie so vor, um herauszufinden, welches DR-Replikat für eine primäre Instanz festgelegt wurde.

Console

So finden Sie heraus, welches Lesereplikat das festgelegte DR-Replikat für eine primäre Instanz ist:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
  3. Klicken Sie im Navigationsmenü auf Replikate.
  4. Prüfen Sie in der Liste der Lesereplikate, ob MySQL disaster recovery replica in der Spalte Typ für das festgelegte DR-Replikat angezeigt wird.

gcloud

Verwenden Sie den folgenden Befehl, um herauszufinden, welche Instanz das festgelegte DR-Replikat einer primären Instanz ist:

gcloud beta sql instances describe PRIMARY_INSTANCE_NAME

Ersetzen Sie die folgende Variable:

  • PRIMARY_INSTANCE_NAME: der Name der primären Instanz

Die Ausgabe dieses Befehls enthält das Feld failoverDrReplica, mit dem das festgelegte DR-Replikat angegeben wird.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Mit einem der folgenden Verfahren können Sie prüfen, ob ein Replikat ein DR-Replikat ist.

Console

So prüfen Sie, ob eine Replikatinstanz ein DR-Replikat ist:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie die Replikatinstanz.
  3. Prüfen Sie, ob MySQL disaster recovery replica in der Spalte Typ für das angegebene DR-Replikat angezeigt wird.

gcloud

Führen Sie den folgenden Befehl aus, um zu prüfen, ob eine Replikatinstanz ein DR-Replikat ist:

gcloud beta sql instances describe REPLICA_NAME

Ersetzen Sie die folgende Variable:

  • REPLICA_NAME: der Name des Lesereplikats, das Sie prüfen möchten

Wenn das Replikat ein DR-Replikat ist, enthält die Ausgabe des Befehls das Feld drReplica=true.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
  • REPLICA_NAME: der Name des Replikats

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
  • REPLICA_NAME: der Name des Replikats

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

DR-Replikat entfernen

Sie können die Kennzeichnung des DR-Replikats von einer primären Instanz löschen. Wenn jedoch einer primären Instanz kein DR-Replikat zugewiesen ist, können Sie keinen Switchover und kein Replikat-Failover ausführen.

Console

So entfernen Sie ein festgelegtes DR-Replikat aus einer primären Instanz:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
  3. Klicken Sie im Navigationsmenü auf Replikate.
  4. Suchen Sie in der Liste der Lesereplikate das regionenübergreifende Lesereplikat, das Sie entfernen möchten.
  5. Klicken Sie für das Replikat auf die Schaltfläche more_vert Aktionen und wählen Sie Als DR-Replikat entfernen aus.
  6. Klicken Sie auf Bestätigen.

gcloud

Führen Sie den folgenden Befehl auf der primären Instanz aus, um die Kennzeichnung des DR-Replikats zu entfernen:

gcloud beta sql instances patch PRIMARY_INSTANCE_NAME \
  --clear-failover-dr-replica-name

Ersetzen Sie die folgende Variable:

  • PRIMARY_INSTANCE_NAME: der Name der primären Instanz, aus der Sie das festgelegte DR-Replikat entfernen möchten

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • Setzen Sie das Feld failoverDrReplicaName auf einen leeren String.

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
  • Setzen Sie das Feld failoverDrReplicaName auf einen leeren String.

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Switchover durchführen

Nachdem Sie ein DR-Replikat festgelegt haben, können Sie den Switchover-Vorgang ausführen. Als Best Practice sollten Sie den Switchover-Vorgang jedoch unter den folgenden Umständen vermeiden:

  • Die primäre Instanz wird aktiv verwendet.
  • Administratorvorgänge werden ausgeführt, z. B. die automatische Sicherung oder die Aktivierung oder Deaktivierung der Hochverfügbarkeit (High Availability, HA).

Führen Sie einen Switchover durch, wenn das Transaktionsvolumen niedrig ist, um eine Zeitüberschreitung zu vermeiden.

Nach Abschluss des Switchovers wird die Sicherung der neuen primären Instanz (dem vorherigen DR-Replikat) erstellt, sobald die neue primäre Instanz hochgestuft wird. Nach Abschluss dieser Sicherung ist die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-Time-Recovery, PITR) auf der neuen primären Instanz vollständig aktiviert. Diese Sicherung kann je nach Laufwerkgröße zwischen 5 und 15 Minuten dauern. Die PITR-Abdeckung beginnt erst, wenn diese Sicherung abgeschlossen wurde. Weitere Informationen zur Verwendung von PITR mit erweiterter DR finden Sie unter PITR mit erweiterter DR verwenden.

Nach Abschluss des Switchover-Vorgangs werden Sie feststellen, dass die Richtung der Replikation umgekehrt wird.

Hinweise

Führen Sie die folgenden Schritte aus, bevor Sie den Switchover-Vorgang ausführen:

  • Legen Sie ein DR-Replikat fest. Sie können nur ein Switchover zwischen der primären Instanz und dem angegebenen DR-Replikat ausführen.
  • Prüfen Sie, ob die primäre Instanz und das DR-Replikat online sind.
  • Erstellen Sie eine On-Demand-Sicherung der primären Instanz. Diese Sicherung ist eine Vorsichtsmaßnahme, falls Sie nach einem unerwarteten Fehler eine Wiederherstellung durchführen müssen.

Switchover-Vorgang ausführen

Console

So führen Sie den Switchover-Vorgang aus:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie das festgelegte DR-Replikat der primären Instanz.
  3. Klicken Sie auf die DR-Replikatinstanz. Die Seite Übersicht für das DR-Replikat wird angezeigt.
  4. Klicken Sie auf die Schaltfläche Wechseln.
  5. Geben Sie auf der Seite Switchover zwischen dem primären und dem DR-Replikat den Namen der primären Instanz in das Feld Instanz-ID ein.
  6. Klicken Sie auf Umstellung.

gcloud

Führen Sie den folgenden Befehl aus, um den Switchover auszuführen:

gcloud beta sql instances switchover REPLICA_NAME
   [--db-timeout=TIMEOUT_DURATION ]

Ersetzen Sie die folgenden Variablen:

  • REPLICA_NAME: der Name des festgelegten DR-Replikats, mit dem die primäre Instanz die Rollen wechseln soll.
  • TIMEOUT_DURATION: Optional. Das Zeitlimit, um den Abschluss der Datenbankvorgänge auf der Instanz zu ermöglichen

    • Wenn Sie diesen Parameter nicht angeben, enthält der Umschaltvorgang ein Zeitlimit von 10 Minuten.

    Sie können den Wert dieses Zeitlimits erhöhen, indem Sie den Parameter --db-timeout angeben. Ersetzen Sie TIMEOUT_DURATION durch eine Zeitraumdauer von bis zu 24 Stunden, einschließlich einer Anfangsschreibweise für das Format. Geben Sie beispielsweise für 30 Sekunden 30s an. Für 24 Stunden geben Sie 24h an. Sie können auch Brucheinheiten des Zeitraums mit Dezimalzahlen mit bis zu neun Stellen angeben. Geben Sie beispielsweise für 30,5 Minuten 30.5m an.

    Wenn keine ausstehenden Vorgänge vorhanden sind, können Sie den Wert dieses Zeitlimits verringern.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Notfallwiederherstellung durch Aufruf eines Replikat-Failovers ausführen

Bei einem regionalen Ausfall oder einem Notfall können Sie die Notfallwiederherstellung durchführen, indem Sie einen Replikat-Failover-Vorgang zu dem vorgesehenen DR-Replikat aufrufen. Für ein Replikat-Failover stufen Sie das festgelegte DR-Replikat hoch. Im Gegensatz zur Umstellung erfolgt das Hochstufen des DR-Replikats sofort.

Da das DR-Replikat die Rolle der primären Instanz sofort übernimmt, ist es möglich, dass das Replikat aufgrund der Replikationsverzögerung nicht alle Daten aus der alten primären Instanz hat. Aus diesem Grund kann bei einem Replikat-Failover Datenverluste auftreten.

Im Rahmen des Hochstufungsprozesses erstellt das Replikat-Failover eine Sicherung der neuen primären Instanz (dem vorherigen DR-Replikat), sobald das DR-Replikat zur neuen primären Instanz wird. Nach Abschluss der Sicherung ist die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-In-Time Recovery, PITR) auf der neuen primären Instanz vollständig aktiviert. Diese Sicherung kann je nach Laufwerkgröße der neuen (und alten) primären Instanz zwischen 5 und 15 Minuten dauern. Während dieses Sicherungszeitraums ist PITR nicht verfügbar.

Sobald die alte primäre Instanz wieder online ist, erstellt der Replikat-Failover-Prozess eine Sicherung. Nachdem diese Sicherung erstellt wurde, wird die alte primäre Instanz als Lesereplikat der neuen primären Instanz neu erstellt. Bei diesem Vorgang verliert die alte primäre Instanz alle alten PITR-Transaktionslogs, die noch nicht in Cloud Storage gespeichert sind. Daher garantiert ein Replikat-Failover nicht, dass alle Transaktionslogs, die für PITR auf der alten primären Instanz verwendet werden, beibehalten werden.

Weitere Informationen zur Verwendung von PITR mit erweiterter DR finden Sie unter PITR mit erweiterter DR verwenden.

Wichtig: Nachdem Sie den Replikat-Failover-Vorgang aufgerufen haben, weisen Sie Ihre Anwendungen darauf hin, die IP-Adresse der neuen primären Instanz zu verwenden.

Hinweise

Führen Sie die folgenden Schritte aus, bevor Sie ein Replikat-Failover ausführen können:

  • Legen Sie ein DR-Replikat fest, falls noch nicht geschehen. Sie können ein Replikat-Failover nur zwischen der primären Instanz und dem angegebenen DR-Replikat ausführen.
  • Sorgen Sie dafür, dass das DR-Replikat online und fehlerfrei ist.

Replikat-Failover-Vorgang ausführen

Console

So führen Sie den Replikat-Failover-Vorgang aus:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie das festgelegte DR-Replikat der primären Instanz.
  3. Klicken Sie auf die DR-Replikatinstanz. Die Seite Übersicht für das DR-Replikat wird angezeigt.
  4. Klicken Sie auf die Schaltfläche Replikat-Failover.
  5. Geben Sie auf der Seite Replikat-Failover zwischen dem primären und dem DR-Replikat ausführen den Namen der primären Instanz in das Feld Instanz-ID ein. Damit bestätigen Sie, dass Sie mit dem Vorgang fortfahren möchten.
  6. Klicken Sie zum Starten des Replikat-Failovers auf Replikat-Failover.

gcloud

Verwenden Sie den folgenden Befehl, um ein Replikat-Failover zum DR-Replikat aufzurufen:

gcloud beta sql instances promote-replica \
   REPLICA_NAME --failover

Ersetzen Sie die folgende Variable:

  • REPLICA_NAME: der Name des DR-Replikats

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • REPLICA_NAME: der Name des DR-Replikats
  • ENABLE_REPLICA_FAILOVER: Legen Sie true fest, um das Replikat-Failover zu verwenden. Wenn Sie false festlegen, verwendet die API die reguläre promoteReplica-Methode ohne Replikat-Failover.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
  • REPLICA_NAME: der Name des DR-Replikats
  • ENABLE_REPLICA_FAILOVER: Legen Sie true fest, um das Replikat-Failover zu verwenden. Wenn Sie false festlegen, verwendet die API die reguläre promoteReplica-Methode ohne Replikat-Failover.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Status eines Replikat-Failovers prüfen

Das Replikat-Failover erfolgt in zwei Phasen. Die erste Phase ist die Hochstufung des DR-Replikats. In der zweiten Phase wird die alte primäre Instanz als Lesereplikat wiederhergestellt.

Prüfen Sie den Status der einzelnen Phasen, um den Status des Replikat-Failovers zu prüfen.

  1. Prüfen Sie den Status der ersten Phase.

    Console

    So prüfen Sie, ob das DR-Replikat zu einer eigenständigen Instanz hochgestuft wurde:

    1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

      Cloud SQL-Instanzen aufrufen

    2. Suchen Sie den Namen des DR-Replikats, das Sie hochgestuft haben.
    3. Prüfen Sie, ob MySQL 8.0 in der Spalte Typ für die neue primäre Instanz angezeigt wird.

    gcloud

    Sie können den Status prüfen, indem Sie den folgenden Befehl ausführen:

    gcloud sql instances describe DR_REPLICA_NAME

    Ersetzen Sie die folgende Variable:

    • DR_REPLICA_NAME ist der Name des hochgestuften DR-Replikats.

    Prüfen Sie in der Ausgabe, ob das folgende Feld angezeigt wird und das Replikat zu einer eigenständigen Cloud SQL-Instanz geworden ist:

    instanceType: CLOUD_SQL_INSTANCE

  2. Prüfen Sie im Vorgangslog der Instanz auf die Meldung RECONFIGURE_OLD_PRIMARY, um den Abschluss der zweiten Phase zu prüfen.

    Die Darstellung dieser Nachricht hängt davon ab, wann die alte primäre Instanz online ist. Dies kann im Notfall einige Minuten oder Tage dauern.

    Weitere Informationen zum Prüfen der Vorgangslogs für eine Instanz finden Sie unter Instanzlogs ansehen.

PITR mit erweiterter Notfallwiederherstellung verwenden

Sowohl beim Switchover als auch beim Replikat-Failover werden die folgenden Änderungen vorgenommen, um die Sicherung und PITR zu unterstützen, sobald das DR-Replikat zu einer primären Instanz hochgestuft wird:

  • Die Sicherungskonfiguration, einschließlich der automatischen Sicherungsplanung, wird von der alten primären Instanz in die neue primäre Instanz kopiert.
  • Wenn diese Option deaktiviert ist, wird das binlog-Konfigurations-Flag aktiviert, um PITR zu aktivieren.
  • Eine neue Sicherung wird erstellt, um PITR auf der neuen primären Instanz zu unterstützen.
  • Die Aufbewahrungsrichtlinie des Transaktionslogs wird von der alten primären Instanz zur neuen primären Instanz kopiert.

Sowohl für die Sicherungskonfiguration als auch für die Aufbewahrungsrichtlinien der Transaktionslogs sollten Sie überprüfen, ob die von der alten primären Instanz übernommenen Einstellungen für die neue primäre Instanz korrekt sind.

Beginn der PITR-Abdeckung

Am Ende des Switchover-Vorgangs plant Cloud SQL automatische Sicherungen und erstellt die erste Sicherung der neuen primären Instanz. Wenn Sie möchten, dass die PITR-Abdeckung früher als später beginnt, sollten Sie prüfen, ob die erste Sicherung erfolgreich war. Die neu hochgestufte primäre Instanz hat die PITR-Abdeckung erst, nachdem die erste automatische Sicherung erfolgreich abgeschlossen wurde.

Weitere Informationen zum Aufrufen der Sicherungen, die für eine Instanz verfügbar sind, finden Sie unter Liste der Sicherungen ansehen.

PITR-Abdeckung für Instanzen während des Switchovers und des Replikat-Failover

Wenn eine Instanz an einem Switchover oder einem Replikat-Failover-Vorgang beteiligt ist, verbringt die Instanz Zeit als Lesereplikat. PITR und die Wiederherstellung einer Sicherung werden während des Zeitraums unterstützt, in dem die Instanz als Lesereplikat genutzt wird. Wenn Sie PITR bis zu einem Zeitpunkt vor dem Switchover-Ereignis ausführen möchten (als die Instanz noch primär war), können Sie den Befehl „clone“ verwenden, um den Zeitpunkt anzugeben, zu dem die Instanz noch primär war. Sie können keine PITR für einen Zeitraum anfordern, in dem die Instanz ein Lesereplikat war.

Wenn Sie PITR nicht ausführen können, weil die primäre Instanz zum entsprechenden Zeitpunkt ein Lesereplikat war, müssen Sie die PITR-Anfrage an die Instanz ausführen, die zum jeweiligen Zeitpunkt als primäre Instanz fungierte.

Ebenso können Sie eine Sicherung wiederherstellen, die zu einem Zeitpunkt erstellt wurde, als das Replikat eine primäre Instanz war. Da es sich bei der Instanz um ein Replik handelt, muss der Befehl zum Wiederherstellen auf eine andere eigenständige Instanz ausgerichtet sein. Die Wiederherstellung kann nicht auf dem Replik selbst erfolgen.

Verwenden Sie die Vorgangsliste, um zu ermitteln, welche Instanz für die PITR-Anfrage verwendet werden soll. Anhand der Vorgangsliste für eine Instanz können Sie feststellen, wann für eine Instanz Switchover- oder Replikat-Failover-Vorgänge durchgeführt wurden.

Split-Brain bei Replikat-Failover

Es kann zu einer Split-Brain-Situation kommen, wenn die primäre Instanz weiterhin Schreibvorgänge akzeptiert, während ein Replikat durch ein Replika-Failover hochgestuft wird. Nachdem das Replikat hochgestuft wurde und die alte primäre Instanz wieder verfügbar ist, wird sie als Replikat der hochgestuften Instanz neu erstellt und eine endgültige Sicherung erstellt. Mit dieser Sicherung können alle Split-Brain-Daten wiederhergestellt werden, die nicht in das beförderte Replikat geschrieben wurden.

Sicherungen und Transaktionslogs auf Replikaten löschen

Wenn eine primäre Instanz, die mit PITR aktiviert wurde, und Sicherungen zu einem Lesereplikat wird, wird die letzte Sicherung und PITR-Aufbewahrungsrichtlinie ab ihrer Zeit als primäre Instanz beibehalten und während ihrer Zeit als Replikat angewendet. Auch wenn die neue primäre Instanz keine Sicherungen erstellt, werden die alten Sicherungen und Transaktionslogs, die für PITR verwendet werden, gemäß der zuletzt konfigurierten Richtlinie auf dem Lesereplikat gelöscht.

Wenn die Instanz beispielsweise für tägliche automatische Sicherungen konfiguriert ist und sieben Sicherungen mit sieben Tagen PITR-Logs speichert, werden alle Daten, die älter als sieben Tage sind, einmal täglich gelöscht, sobald diese Instanz zu einem Lesereplikat wird.

Wenn Sie Sicherungen früher löschen müssen, können Sie diese manuell entfernen. Weitere Informationen finden Sie unter Sicherung löschen.

Beschränkungen

  • Die erweiterte Notfallwiederherstellung wird für Cloud SQL-Instanzen, die Private Service Connect verwenden, nicht unterstützt.
  • Sie können eine Lesereplikatinstanz der Cloud SQL Enterprise Plus-Version nicht als DR-Replikat festlegen, wenn die primäre Instanz ihre Transaktionslogs für die Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) auf dem Laufwerk speichert. Informationen zum Prüfen, wo eine Instanz ihre Logs für PITR speichert, finden Sie unter Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden.
  • Sie können ein externes Replikat nicht als DR-Replikat festlegen.

Fehlerbehebung

Problem Fehlerbehebung
Der Umschaltvorgang ist fehlgeschlagen.
  • Prüfen Sie, ob die Instanz alle angegebenen Anforderungen für das DR-Replikat erfüllt.
  • Prüfen Sie die Anzahl der Transaktionen in der Datenbank. Der Switchover sichert die binären Logs der primären Instanz in Cloud Storage, bevor er den Switchover durchführt. Wenn das Transaktionsvolumen hoch ist, kann dies zu einer Zeitüberschreitung des Vorgangs führen. Versuchen Sie, den Vorgang zu wiederholen, wenn die Transaktionslast geringer ist.
Der Umschaltvorgang ist fehlgeschlagen und die primäre Instanz bleibt im schreibgeschützten Modus. Führen Sie einen Neustart der Datenbank durch, um sie wieder in den Schreibmodus zu versetzen.
Der Umschaltvorgang ist abgeschlossen, aber in der Google Cloud Console werden die neuen umgekehrten Rollen für die Instanzen nicht angezeigt. Aktualisieren Sie Ihren Browser, um die aktualisierte Topologie anzuzeigen.
Der Replikat-Failover-Vorgang ist fehlgeschlagen.
  • Sorgen Sie dafür, dass ein DR-Replikat für die primäre Instanz festgelegt ist und online ist.
  • Wenn das Failover auf das DR-Replikat fehlgeschlagen ist, stufen Sie stattdessen zu einem regulären (Nicht-DR-) Lesereplikat hoch.
Ich kann nicht erkennen, ob die Replikation nicht erfolgt Stellen Sie eine Verbindung zum Replikat her und geben Sie Folgendes ein: 
show slave status;
  • Wenn die Replikation erfolgt, wird in der ersten Spalte „Slave_IO_State“ der Wert Waiting for master to send event angezeigt und das Feld „Last_IO_Error“ ist leer.
  • Wenn die Replikation nicht erfolgt, wird in der ersten Spalte "Slave_IO_State" der Eintrag "Connecting to master" angezeigt. und das Feld "Last_IO_Error" einen Fehler wie "error connecting to master 'cloudsqlreplica@x.x.x.x:3306" anzeigt.

Sie können den Replikationsstatus der Replikate auch im Cloud SQL-Monitoring-Dashboard aufrufen. Weitere Informationen finden Sie unter Cloud SQL-Instanzen überwachen.

Sie haben die folgende Fehlermeldung erhalten:

"Instance was converted into a replica between the target PITR time and the last available base backup. PITR logs are not available for the period instance was a replica. Please clone from the instance that was primary at time %s"

Sie können PITR nicht für einen Zeitraum ausführen, in dem eine Instanz auf ein Replikat umgestellt wurde. Die PITR-Logs sind nicht für den Zeitraum verfügbar, in dem die Instanz ein Replikat war.

  • Überprüfen Sie die Liste der Vorgänge für die Instanz, um festzustellen, ob die Instanz zu diesem Zeitpunkt ein Replikat war.
  • Ermitteln Sie anhand der Liste der Vorgänge, welche Instanz zu diesem Zeitpunkt die primäre Instanz war.
  • Klonen Sie diese Instanz, um PITR auszuführen.

Sie haben die folgende Fehlermeldung erhalten:

"You can only designate a disaster recovery (DR) replica for primary instances that are storing their PITR logs in Cloud Storage. PITR logs of the instance %s are not stored in Cloud Storage"

Die primäre Instanz hat den Speicherort für ihre Transaktionslogs noch nicht auf Cloud Storage geändert. Sie können es noch einmal versuchen, nachdem der Speicherort für die Transaktionslogs geändert wurde, oder ein DR-Replikat für eine andere primäre Instanz festlegen.

Weitere Informationen zum Verschieben des Speicherorts der für PITR verwendeten Transaktionslogs finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt verwenden.

Sie haben die folgende Fehlermeldung erhalten:

"The specified failover dr replica name REPLICA_NAME must be one of the replicas of the primary instance INSTANCE_NAME."

Weitere Informationen zum Festlegen eines DR-Replikats und zur korrekten Befehlssyntax finden Sie unter DR-Replikat für die primäre Instanz festlegen.

Nächste Schritte