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. Bei Cloud SQL for SQL Server ist das Notfallwiederherstellungsreplikat 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.

Hinweise

Wenn Sie das Google Cloud SDK verwenden möchten, müssen Sie Version 502.0.0 oder höher 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.

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 die primäre 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.

Nachdem die alte primäre Instanz als Lesereplikat neu konfiguriert wurde, wird der DNS-Schreibendpunkt, der zuvor auf die alte primäre Instanz verweiste, auf die neue primäre Instanz umgeleitet.

Hinweise

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

• Erstellen Sie ein DR-Replikat, falls noch nicht geschehen.
• Prüfen Sie, ob die primäre Instanz und das DR-Replikat online sind.
• Wenn Sie einen DNS-Schreibendpunkt verwenden, prüfen Sie, ob die SSL-Konfiguration für die primäre Instanz und das DR-Replikat identisch ist. Wenn das DR-Replikat beispielsweise so konfiguriert ist, dass SSL-Verschlüsselung erzwungen wird, die primäre Instanz aber unverschlüsselte Verbindungen zulässt, können Clients nach Abschluss des Switchover-Vorgangs keine Verbindung mehr zur neuen primären Instanz herstellen.
• 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

gcloud sql instances switchover REPLICA_NAME

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

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"

$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

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "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"
}

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

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"

$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

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "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.

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

Nachdem Sie den Replikat-Failover-Vorgang aufgerufen haben, wird der DNS-Schreibendpunkt, der zuvor auf die alte primäre Instanz verweiste, auf die neue primäre Instanz aufgelöst.

Hinweise

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

• Erstellen Sie ein DR-Replikat, falls noch nicht geschehen.
• Sorgen Sie dafür, dass das DR-Replikat online und fehlerfrei ist.

Replikat-Failover-Vorgang ausführen

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

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

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"

$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

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "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"
}

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

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/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

$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/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/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.

• 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 und als primäre Instanz verwendet wird.

Sie können die PITR zu einem Zeitpunkt vor dem Switchover ausführen, als die Instanz noch eine primäre Instanz war. Sowohl beim Switchover als auch beim Replikat-Failover wird in Cloud SQL eine Best-Effort-Sicherung für die neue primäre Instanz gestartet, sobald diese hochgestuft wird. PITR wird erst nach Abschluss dieser Sicherung auf der hochgestuften Instanz aktiviert. Diese Sicherung kann je nach Laufwerkgröße zwischen 5 und 15 Minuten dauern.

Split-Brain bei Replikat-Failover

Es kann zu einer Splitbrain-Situation kommen, wenn die primäre Instanz weiterhin Schreibvorgänge akzeptiert, während ein Replikat über das Replikations-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. Die erweiterte Notfallwiederherstellung unterstützt den Zugriff auf private Dienste.

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

• Terraform wird für Switchover- oder Replikat-Failover-Vorgänge nicht unterstützt.

• Mit der Google Cloud Console können Sie keine Replik-Failover- oder -Wechselvorgänge ausführen.

Fehlerbehebung

Nächste Schritte

• An Standorten weltweit verfügbare Google Cloud-Dienste
• Informationen zur Beobachtbarkeit von Datenbanken
• Cloud SQL-Instanzen überwachen