Erweiterte Notfallwiederherstellung (Disaster Recovery, DR) verwenden

MySQL   |  PostgreSQL   |  SQL Server

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. Bei Cloud SQL for SQL Server ist das DR-Replikat ein kaskadierbares Replikat.
• 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.

Hinweis: Diese Seite enthält Funktionen zu den Cloud SQL-Versionen. Weitere Informationen zu den Cloud SQL-Versionen finden Sie unter Einführung in die Cloud SQL-Versionen.

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 erstellen

Bevor Sie die erweiterte Notfallwiederherstellung verwenden, erstellen Sie ein kaskadierbares Replikat der primären Instanz in einer anderen Region als der primären Instanz.

Switchover durchführen

Nachdem Sie ein DR-Replikat erstellt 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.

Wichtig: Nachdem die alte primäre Instanz als Lesereplikat neu konfiguriert wurde, verweisen Sie Ihre Anwendungen so, dass sie im letzten Schritt die IP-Adresse der neuen primären Instanz für den Switchover verwenden.

Hinweise

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

• Falls noch nicht geschehen, erstellen Sie ein DR-Replikat.
• 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. Klicken Sie auf die DR-Replikatinstanz. Die Seite Übersicht für das DR-Replikat wird angezeigt.
3. Klicken Sie auf die Schaltfläche Wechseln.
4. 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.
5. Klicken Sie auf Umstellung.

gcloud

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

gcloud beta sql instances switchover REPLICA_NAME

Ersetzen Sie die folgenden Variablen:

• REPLICA_NAME: der Name des festgelegten DR-Replikats, mit dem die primäre Instanz die Rollen wechseln soll.

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:

curl (Linux, macOS oder Cloud Shell)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu haben Sie gcloud init oder gcloud auth login ausgeführt oder die Cloud Shell genutzt, die Sie automatisch bei der gcloud-Befehlszeile anmeldet. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu führen Sie gcloud init oder gcloud auth login aus. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

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

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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:

curl (Linux, macOS oder Cloud Shell)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu haben Sie gcloud init oder gcloud auth login ausgeführt oder die Cloud Shell genutzt, die Sie automatisch bei der gcloud-Befehlszeile anmeldet. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu führen Sie gcloud init oder gcloud auth login aus. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

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

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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 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.

Hinweise

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

• Falls noch nicht geschehen, erstellen Sie ein DR-Replikat.
• 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. Klicken Sie auf die DR-Replikatinstanz. Die Seite Übersicht für das DR-Replikat wird angezeigt.
3. Klicken Sie auf die Schaltfläche Replikat-Failover.
4. 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.
5. 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 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:

curl (Linux, macOS oder Cloud Shell)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu haben Sie gcloud init oder gcloud auth login ausgeführt oder die Cloud Shell genutzt, die Sie automatisch bei der gcloud-Befehlszeile anmeldet. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu führen Sie gcloud init oder gcloud auth login aus. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

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

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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:

curl (Linux, macOS oder Cloud Shell)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu haben Sie gcloud init oder gcloud auth login ausgeführt oder die Cloud Shell genutzt, die Sie automatisch bei der gcloud-Befehlszeile anmeldet. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu führen Sie gcloud init oder gcloud auth login aus. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

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

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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 SQL Server VERSION 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 eine primäre Instanz war), können Sie den Klonbefehl ausführen, um den Zeitpunkt festzulegen, zu dem die Instanz eine primäre Instanz 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. Obwohl die Instanz ein Replikat ist, muss der Wiederherstellungsbefehl auf eine andere eigenständige Instanz ausgerichtet sein und kann nicht auf dem Replikat selbst wiederhergestellt werden.

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 während des Replikat-Failover

Es kann zu einem Split-Brain-Zustand 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 wird erstellt. Mit dieser Sicherung können alle Split-Brain-Daten wiederhergestellt werden, die nicht in das beförderte Replikat geschrieben wurden.

Hinweis: Bei Umstellungsvorgängen kann es nicht zu einer Split-Brain-Situation kommen.

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.

Hinweis: Sie können die Einstellungen für die Sicherungskonfiguration nicht ändern, solange die Instanz ein Replikat ist.

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 (abfolgefähiges Replikat) erfüllt. Prüfen Sie die Anzahl der Transaktionen in der Datenbank. 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.	Achten Sie darauf, dass Sie ein DR-Replikat für die primäre Instanz erstellt haben und dass es online ist. Wenn das Failover auf das DR-Replikat fehlgeschlagen ist, stufen Sie stattdessen zu einem regulären (Nicht-DR-) Lesereplikat hoch.

Nächste Schritte

• Informationen zur Beobachtbarkeit von Datenbanken
• Cloud SQL-Instanzen überwachen