Notfallwiederherstellung (Disaster Recovery, DR) in Cloud SQL

Auf dieser Seite wird die Notfallwiederherstellung in Cloud SQL vorgestellt.

Überblick

In Google Cloud ist die Datenbank-Notfallwiederherstellung darauf ausgelegt, die Aufrechterhaltung der Verarbeitung zu gewährleisten, insbesondere wenn eine Region ausfällt oder nicht verfügbar ist. Cloud SQL ist ein regionaler Dienst (wenn Cloud SQL für Hochverfügbrkeit konfiguriert ist). Wenn die Google Cloud-Region, in der eine Cloud SQL-Datenbank gehostet wird, nicht mehr verfügbar ist, ist die Cloud SQL-Datenbank ebenfalls nicht mehr verfügbar.

Für die weitere Verarbeitung müssen Sie die Datenbank so schnell wie möglich in einer sekundären Region verfügbar machen. Der Notfallwiederherstellungs-Plan erfordert, dass Sie ein regionenübergreifendes Lesereplikat in Cloud SQL konfigurieren. Ein Failover, der auf dem Export/Import oder der Sicherung/Wiederherstellung basiert, ist ebenfalls möglich, benötigt jedoch mehr Zeit, insbesondere bei großen Datenbanken.

Die folgenden geschäftlichen Szenarien sind Beispiele, die eine regionsübergreifende Failover-Konfiguration garantieren:

  • Das Service Level Agreement für die Geschäftsanwendung ist größer als das regionale Cloud SQL-Service Level Agreement (99,99% Verfügbarkeit, je nach Cloud SQL-Version). Durch ein Failover in eine andere Region können Sie einen Ausfall minimieren.
  • Alle Ebenen der Geschäftsanwendung sind bereits multiregional und können bei einem Ausfall der Region weiter verarbeitet werden. Die regionenübergreifende Failover-Konfiguration sorgt für die kontinuierliche Verfügbarkeit einer Datenbank.
  • Das erforderliche Recovery Time Objective (RTO) und das Recovery Point Objective (RPO) sind in Minuten statt in Stunden angegeben. Ein Failover in eine andere Region ist schneller als das Neuerstellen einer Datenbank.

Im Allgemeinen gibt es zwei Varianten für den DR-Prozess:

  • Eine Datenbank kann nicht auf eine sekundäre Region übertragen werden. Sobald die Datenbank bereit ist und von einer Anwendung verwendet wird, wird sie zur neuen primären Datenbank und behält die primäre Datenbank.
  • Eine Datenbank führt kein Failover auf eine sekundäre Region durch, greift aber nach dem Ausfall der primären Region wieder auf die primäre Region zurück.

In dieser Übersicht zur Notfallwiederherstellung für Google Cloud SQL-Datenbanken wird die zweite Variante beschrieben. Hierbei wird eine ausgefallene Datenbank wiederhergestellt und greift auf die primäre Region zurück. Dieser Notfallwiederherstellungs-Prozess ist insbesondere für Datenbanken relevant, die aufgrund der Netzwerklatenz in der primären Region laufen müssen oder weil einige Ressourcen nur in der primären Region verfügbar sind. Bei dieser Variante wird die Datenbank in der sekundären Region nur für die Dauer des Ausfalls in der primären Region ausgeführt.

Notfallwiederherstellungsarchitektur

Das folgende Diagramm zeigt die minimale Architektur, die die Datenbank-DR für eine Cloud SQL-Instanz für hohe Verfügbarkeit unterstützt:

Die primäre Instanz und die Standby-Instanz befinden sich in einer Region und das Lesereplikat befindet sich in einer zweiten Region.

Die Architektur funktioniert so:

  • Zwei Instanzen von Cloud SQL (eine primäre Instanz und eine Standby-Instanz) befinden sich in zwei separaten Zonen innerhalb einer einzelnen Region (der primären Region). Die Instanzen werden mithilfe von regionalen nichtflüchtigen Speichern synchronisiert.
  • Eine Instanz von Cloud SQL (das regionenübergreifende Lesereplikat) befindet sich in einer zweiten Region (sekundäre Region). Bei DR wird das regionenübergreifende Lesereplikat mithilfe der asynchronen Replikation mit der primären Instanz synchronisiert (mithilfe der Lesereplikation).

Die primäre Instanz und die Standby-Instanz teilen sich das gleiche regionale Laufwerk, sodass ihre Status identisch sind.

Da diese Konfiguration eine asynchrone Replikation verwendet, kann es vorkommen, dass das regionenübergreifende Lesereplikat hinter der primären Instanz zurückliegt. Wenn ein Failover auftritt, unterstützt das regionenübergreifende Lesereplikat einen RPO von null.

Notfallwiederherstellungsprozess

Der Notfallwiederherstellungsprozess beginnt, wenn die primäre Region nicht mehr verfügbar ist. Wenn Sie die Verarbeitung in einer sekundären Region fortsetzen möchten, lösen Sie ein Failover der primären Instanz aus, indem Sie ein regionenübergreifendes Lesereplikat hochstufen. Der DR-Prozess umfasst eine manuelle oder automatische Ausführung der operativen Schritte, um den regionalen Ausfall zu minimieren und eine laufende primäre Instanz in einer sekundären Region einzurichten.

Das folgende Diagramm zeigt den DR-Prozess:

Wenn Region 1 nicht mehr verfügbar ist, wird das ursprüngliche Lesereplikat zur primären Instanz hochgestuft.

Der Prozess besteht aus den folgenden Schritten:

  1. Die primäre Region (R1), die die primäre Instanz ausführt, ist nicht mehr verfügbar.
  2. Das operative Team erkennt und bestätigt offiziell den Notfall und entscheidet, ob ein Failover erforderlich ist.
  3. Wenn ein Failover erforderlich ist, können Sie das regionenübergreifende Lesereplikat in der sekundären Region (R2) zur neuen primären Instanz hochstufen.
  4. Clientverbindungen werden neu konfiguriert, um die Verarbeitung auf der neuen primären Instanz fortzusetzen und in R2 auf die primäre Instanz zuzugreifen.

Im Rahmen dieses grundlegenden Prozesses wird wieder eine funktionierende primäre Datenbank eingerichtet. Es wird jedoch keine vollständige DR-Architektur eingerichtet, bei der die neue primäre Instanz selbst eine Standby-Instanz und ein regionenübergreifendes Lesereplikat hat.

Ein vollständiger DR-Prozess stellt sicher, dass die einzelne Instanz, die neue primäre Instanz, für HA aktiviert ist und über ein regionenübergreifendes Lesereplikat verfügt. Ein vollständiger DR-Prozess bietet auch ein Fallback auf die ursprüngliche Bereitstellung in der ursprünglichen primären Region.

Failover auf sekundäre Region ausführen

Ein vollständiger DR-Prozess ergänzt den grundlegenden DR-Prozess durch Schritte, mit denen eine vollständige DR-Architektur nach einem Failover eingerichtet wird. Das folgende Diagramm zeigt eine vollständige Datenbank-DR-Architektur nach dem Failover:

Clients greifen auf die neue primäre Instanz zu und ein Lesereplikat wird in einer dritten Region eingerichtet.

Der vollständige Datenbank-DR-Prozess umfasst die folgenden Schritte:

  1. Die primäre Region (R1), die die primäre Datenbank ausführt, ist dann nicht mehr verfügbar.
  2. Das operative Team erkennt und bestätigt offiziell den Notfall und entscheidet, ob ein Failover erforderlich ist.
  3. Wenn ein Failover erforderlich ist, können Sie dann das regionenübergreifende Lesereplikat in der sekundären Region (R2) zur neuen primären Instanz hochstufen.
  4. Clientverbindungen werden neu konfiguriert, um auf die neue primäre Instanz (R2) zuzugreifen und sie zu verarbeiten.
  5. Eine neue Standby-Instanz wird in R2 erstellt und gestartet und der primären Instanz hinzugefügt. Die Standby-Instanz befindet sich in einer anderen Zone als die primäre Instanz. Die primäre Instanz ist jetzt hochverfügbar, weil für sie eine Standby-Instanz erstellt wurde.
  6. In einer dritten Region (R3) wird ein neues regionenübergreifendes Lesereplikat erstellt und der primären Instanz hinzugefügt. An diesem Punkt wird eine vollständige Architektur zur Notfallwiederherstellung neu erstellt und betrieben.

Wenn die ursprüngliche primäre Region (R1) verfügbar ist, bevor Schritt 6 implementiert wurde, kann das regionenübergreifende Lesereplikat in Region R1 und nicht in Region R3 platziert werden. In diesem Fall ist das Fallback auf die ursprüngliche primäre Region (R1) weniger komplex und erfordert weniger Schritte.

Split-Brain-Status vermeiden

Ein Ausfall der primären Region (R1) bedeutet nicht, dass die ursprüngliche primäre Instanz und ihre Standby-Instanz automatisch heruntergefahren, entfernt oder anderweitig zugänglich gemacht werden, wenn R1 wieder verfügbar ist. Wenn R1 verfügbar ist, können Clients Daten (auch nach Unfall) auf der ursprünglichen primären Instanz lesen und schreiben. In diesem Fall kann eine Split-Brain-Situation entwickelt werden, bei der einige Clients auf veraltete Daten in der alten primären Datenbank zugreifen. Andere Clients greifen auf neue Daten in der neuen primären Datenbank zu, was zu Problemen in Ihrem Unternehmen führt.

Achten Sie darauf, dass Clients nicht mehr auf die ursprüngliche primäre Instanz zugreifen können, sobald R1 verfügbar ist. So vermeiden Sie eine Teilungszeit für Daten. Idealerweise sollten Sie die ursprüngliche primäre Instanz nicht mehr zugänglich machen, bevor Clients die neue primäre Instanz verwenden. Löschen Sie dann die ursprüngliche primäre Instanz, sobald Sie nicht mehr darauf zugreifen können.

Erste Sicherung nach einem Failover erstellen

Wenn Sie das regionenübergreifende Lesereplikat in einem Failover zur neuen primären Datenbank hochstufen, werden die Transaktionen in der neuen primären Datenbank möglicherweise nicht vollständig mit Transaktionen aus der ursprünglichen primären Datenbank synchronisiert. Daher sind diese Transaktionen in der neuen Instanz nicht verfügbar.

Als Best Practice empfehlen wir, dass Sie sofort die neue primäre Instanz zu Beginn des Failovers sichern und dann wieder auf die Datenbank zugreifen. Diese Sicherung stellt einen konsistenten, bekannten Status zum Zeitpunkt des Failovers dar. Solche Sicherungen können für rechtliche Zwecke oder für die Wiederherstellung eines bekannten Zustands wichtig sein, wenn Clients Probleme beim Zugriff auf die neue primäre Datenbank haben.

Zurück zur ursprünglichen primären Region

Wie bereits beschrieben, umfasst dieses Dokument die Schritte, die auf die ursprüngliche Region (R1) zurückgehen. Der Fallback-Prozess umfasst zwei verschiedene Versionen.

  • Wenn Sie das neue regionenübergreifende Lesereplikat in einer tertiären Region (R3) erstellt haben, müssen Sie ein weiteres (sekundäres) regionenübergreifendes Lesereplikat in der primären Region (R1) erstellen.
  • Wenn Sie das neue regionenübergreifende Lesereplikat in der primären Region (R1) erstellt haben, müssen Sie kein weiteres regionenübergreifendes Lesereplikat in R1 erstellen.

Nachdem das regionenübergreifende Lesereplikat in R1 vorhanden ist, kann die Cloud SQL-Instanz auf R1 zurückgreifen. Da dieses Fallback manuell ausgelöst wird und nicht aufgrund eines Ausfalls besteht, können Sie für diese Wartungsaktivität einen geeigneten Tag und eine geeignete Uhrzeit auswählen.

Um eine vollständige DR mit einem primären, Standby- und regionenübergreifenden Lesereplikat zu erreichen, benötigen Sie daher zwei Failovers. Das erste Failover wird durch den Ausfall ausgelöst (ein wirkliches Failover) und das zweite Failover stellt die Startbereitstellung wieder her (ein Fallback).

Ein Fallback auf die ursprüngliche primäre Region (R1) besteht aus den folgenden Schritten:

  1. Hochstufen des neu erstellten regionenübergreifenden Replikats in der ursprünglichen primären Region (R1).
  2. Wenn die hochgestufte Instanz nicht ursprünglich als HA-Replikat erstellt wurde, aktivieren Sie HA auf der Instanz zum Schutz vor zonalen Fehlern.
  3. Konfigurieren Sie Ihre Anwendungen neu, sodass eine Verbindung zur neuen primären Instanz hergestellt werden kann.
  4. Erstellen Sie ein regionenübergreifendes Replikat für die neue primäre Instanz in der DR-Region (R2).
  5. (Optional) Bereinigen Sie die primäre Instanz in der DR-Region (R2), um die Ausführung mehrerer unabhängiger primäre Instanzen zu vermeiden.

Nächste Schritte

  • Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center