Notfallwiederherstellung (Disaster Recovery, DR) in Cloud SQL

MySQL   |  PostgreSQL   |  SQL Server

Auf dieser Seite wird die Notfallwiederherstellung in Cloud SQL vorgestellt.

Übersicht

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ügbarkeit 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 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 also ein Failover auftritt, ist der RPO des regionenübergreifenden Lesereplikats wahrscheinlich nicht 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:

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:

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

Hinweis: Sie können das RTO für den gesamten Notfallwiederherstellungsprozess reduzieren, indem Sie die erweiterte Notfallwiederherstellung für Cloud SQL for SQL Server verwenden. Bei der erweiterten Notfallwiederherstellung wird die ursprüngliche primäre Instanz automatisch als Replikat der hochgestuften Instanz neu erstellt. Weitere Informationen finden Sie unter Erweiterte Notfallwiederherstellung.

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. Konfigurieren Sie Ihre Anwendungen neu, sodass eine Verbindung zur neuen primären Instanz hergestellt werden kann.
3. Erstellen Sie ein regionenübergreifendes Replikat für die neue primäre Instanz in der DR-Region (R2).
4. (Optional) Bereinigen Sie die primäre Instanz in der DR-Region (R2), um die Ausführung mehrerer unabhängiger primäre Instanzen zu vermeiden.

Kaskadierbare Replikate

Mit Cloud SQL können Sie Replikate für regionenübergreifende Notfalltests und Notfallwiederherstellungsszenarien erstellen. Sie können ein Replikat mit dem Flag cascadable-replica in einer anderen Region als der primären Instanz erstellen. Wenn in der Region der primären Instanz ein Notfall eintritt, starten Sie das Failover zum kaskadierenden Replikat. Sobald die ursprüngliche primäre Instanz wieder online ist und als fehlerfreies Replikat fungiert, können Sie mit dem Switchover-Vorgang zurück zur ursprünglichen primären Instanz wechseln.

Ein kaskadierendes Replikat bietet zwei zusätzliche Funktionen, die andere Lesereplikate nicht haben:

• Sie können zusätzliche Lesereplikate (kaskadierende Replikate) an das kaskadierbare Lesereplikat anhängen. Cloud SQL sendet regionenübergreifenden Replikationstraffic nur einmal an das kaskadierbare Replikat. Dieses leitet den Traffic dann an seine regionalen Replikate weiter. Mit dieser Architektur können Sie Kosten für die Netzwerkdatenübertragung zwischen Regionen sparen, wenn Sie in einer anderen Region mehrere Replikate haben müssen.
• Sie können das kaskadierbare Lesereplikat als Ziel für Switchover- und Failover-Vorgänge in regionenübergreifenden Szenarien der Notfallwiederherstellung verwenden. Bei diesen Vorgängen wird das kaskadierbare Replik als primäre Instanz in einem Cluster neu konfiguriert.

Sie haben zwei Möglichkeiten, die Notfallwiederherstellung zu testen:

• Hochstufung Ihres Replikats
• Erweiterte Notfallwiederherstellung

Hinweis: Führen Sie zum Konfigurieren des DR-Replikats für Hochverfügbarkeit einen Switchover-Vorgang aus, um das Replikat hochzustufen. Nachdem das Replikat zur primären Instanz hochgestuft wurde, können Sie die availability_type=REGIONAL-Konfiguration festlegen. Wenn Sie zurückwechseln, behält das Replikat seine Hochverfügbarkeitskonfiguration bei.

Erweiterte Notfallwiederherstellung

Wenn Sie Cloud SQL Enterprise Plus verwenden, können Sie die erweiterte Notfallwiederherstellung nutzen. Die erweiterte Notfallwiederherstellung vereinfacht die Wiederherstellung und den Fallback nach einem regionenübergreifenden Failover. Wie unter Notfallwiederherstellungsprozess beschrieben, entfernen Sie bei der Notfallwiederherstellung die Verbindung zwischen der ausgefallenen Region der alten primären Instanz und der Betriebsregion der neuen primären Instanz. ausgeführt werden. Mit der Notfallwiederherstellung müssen Sie eine Reihe manueller Fallback-Schritte ausführen, um Verbindungen zur ursprünglichen Bereitstellungsregion und zur alten primären Instanz wiederherzustellen.

Bei der erweiterten Notfallwiederherstellung können Sie bei einem regionalen Ausfall ein Replikat-Failover aufrufen. Beim Replikat-Failover stufen Sie ein regionenübergreifendes Lesereplikat ähnlich wie bei der regulären DR hoch, mit der Ausnahme, dass Sie das festgelegte Replikat der Notfallwiederherstellung (Disaster Recovery, DR) hochstufen. Für Cloud SQL for SQL Server erstellen Sie ein DR-Replikat, indem Sie ein regionenübergreifendes Replikat der primären Instanz mit dem Flag cascadable-replica erstellen. Das Hochstufen des DR-Replikats erfolgt sofort. Wenn Sie eine neue primäre Instanz erstellen oder ein Notfallwiederherstellungsreplikat für eine vorhandene primäre Instanz festlegen, wird in Cloud SQL außerdem ein Schreibendpunkt erstellt. Ein Schreibendpunkt ist ein DNS-Name, der in die IP-Adresse der primären Instanz aufgelöst wird. Wenn das DR-Replikat hochgestuft wird, wird der Schreibendpunkt aktualisiert, sodass er auf die neu hochgestufte primäre Instanz verweist. Dadurch wird sichergestellt, dass alle Anwendungen, die versuchen, eine Verbindung über den Schreibendpunkt herzustellen, an die hochgestufte Instanz weitergeleitet werden.

Anstatt die alte primäre Instanz zu entfernen, bleibt die Instanz Teil der asynchronen Replikationstopologie von Cloud SQL. Die alte primäre Instanz (Instanz A) wird schließlich zu einem Replikat des DR-Replikats (Instanz B), nachdem das DR-Replikat zur neuen primären Instanz hochgestuft wurde.

Nachdem die alte primäre Instanz (A) in ein Replikat umgewandelt wurde, können Sie den letzten Schritt der erweiterten DR ausführen. Sie können Ihre Cloud SQL-Bereitstellung in den ursprünglichen Zustand zurücksetzen und die alte primäre Instanz (A) auf ihre vorherige Rolle als primäre Instanz ohne Datenverlust wiederherstellen. Für diese Wiederherstellung ohne Datenverlust der alten primären Instanz (A) können Sie den Switchover-Vorgang verwenden. Wenn Sie ein Switchover ausführen, tritt kein Datenverlust auf, da die primäre Instanz (B) im Lesemodus verbleibt, bis das festgelegte DR-Replikat (A) die primäre Instanz (B) aufholt. Nachdem das DR-Replikat (A) alle Replikationsupdates erhalten hat, übernimmt das DR-Replikat (A) die Rolle der primären Instanz, während die vorherige primäre Instanz (B) automatisch als DR-Replikat der aktuellen primären Instanz (A) neu konfiguriert wird. Die Instanzen werden in ihre ursprünglichen Rollen zurückversetzt. Dadurch wird die Topologie in den ursprünglichen Zustand vor der Notfallwiederherstellung und dem Replikat-Failover zurückgesetzt.

Während der erweiterten Notfallwiederherstellung behalten alle Instanzen, die sowohl am Replikat-Failover als auch an Switchover-Vorgängen beteiligt sind, ihre IP-Adressen bei.

Hinweis: Während ein Switchover zu keinem Datenverlust führt, kann das Replikat-Failover zu Datenverlust führen, wenn beim Replikat-Failover beim DR-Replikat Replikationsverzögerungen auftreten.

Sie können den Switchover-Vorgang der erweiterten Notfallwiederherstellung auch verwenden, um routinemäßige DR-Aufschlüsselungen durchzuführen, um Ihre Cloud SQL-Topologie für den regionenübergreifenden Failover zu testen und vorzubereiten, bevor ein Notfall eintritt. Wenn tatsächlich ein Notfall eintritt, können Sie das bereits getestete regionenübergreifende Replikat-Failover ausführen.

DR-Replikat (Disaster Recovery, DR)

Als erforderliche Komponente der erweiterten Notfallwiederherstellung hat das DR-Replikat die folgenden Eigenschaften:

Ein DR-Replikat ist ein kaskadierendes Replikat, das Sie mit dem Flag cascadable-replica erstellen. Damit es als DR-Replikat verwendet werden kann, muss es sich in einer anderen Region als die primäre Instanz befinden.

In einer Region kann es nur ein DR-Replikat geben.

Sie können die Kennzeichnung des DR-Replikats jederzeit ändern, außer während eines Switchover- oder Replikat-Failover-Vorgangs.

Außerdem empfehlen wir Folgendes, um den RTO nach der Verwendung der erweiterten Notfallwiederherstellung zu reduzieren:

• Konfigurieren Sie das DR-Replikat mit derselben Größe wie die primäre Instanz.
• Wenn für die primäre Instanz Hochverfügbarkeit aktiviert ist, empfehlen wir, Hochverfügbarkeit auch für das DR-Replikat zu aktivieren. Prüfen Sie dazu zuerst, ob Hochverfügbarkeit für die primäre Instanz aktiviert ist. Führen Sie dann das Switchover zum DR-Replikat aus. Aktivieren Sie nach Abschluss des Vorgangs die Hochverfügbarkeit auf der neuen primären Instanz. Anschließend können Sie zur alten primären Instanz zurückkehren. Das DR-Replikat behält seine Hochverfügbarkeitskonfiguration bei, auch wenn es wieder zu einem Replikat wird.

Replikat-Failover

Ein Replikat-Failover besteht aus den folgenden Schritten:

1. Bevor Sie ein Replikat-Failover ausführen, haben Sie der primären Instanz ein DR-Replikat zugewiesen und den Prozess möglicherweise über einen Switchover getestet.
2. Die primäre Region, die die primäre Datenbank ausführt, ist dann nicht mehr verfügbar.
3. Das operative Team entscheidet, dass eine Notfallwiederherstellung erforderlich ist.
4. Sie führen ein Replikat-Failover auf das DR-Replikat aus.
5. Das DR-Replikat wird sofort zur primären Instanz und beginnt, eingehende Lese- und Schreibvorgänge zu akzeptieren.
6. Der Schreibendpunkt wird aktualisiert und beginnt, auf die neue primäre Instanz zu verweisen.
7. Nachdem das Replik hochgestuft wurde, prüft Cloud SQL regelmäßig, ob die ursprüngliche primäre Instanz wieder online ist. Wenn die ursprüngliche primäre Instanz online ist, konfiguriert Cloud SQL die alte primäre Instanz als Replikat der hochgestuften Instanz neu. Die alte primäre Instanz behält ihre IP-Adresse bei.
8. Wenn die alte primäre Instanz nicht 24 Stunden lang verfügbar ist, entfernt Cloud SQL sie aus der Replikationstopologie, um sicherzustellen, dass das Transaktionslog auf der neuen primären Instanz und den anderen Replikaten nicht unbegrenzt wächst.

Nachdem Sie ein Replikat-Failover durchgeführt haben, können Sie die primäre Instanz in Ihrer ursprünglichen Region wiederherstellen. Führen Sie dazu den Switchover-Vorgang aus und kehren Sie dasselbe DR-Replikat und dasselbe primäre Instanzpaar um.

Wechseln

Ein Switchover umfasst die folgenden Schritte:

1. Bevor Sie den Switchover-Vorgang starten, müssen Sie der primären Instanz ein DR-Replikat zuweisen.
2. Prüfen Sie, ob die primäre Instanz fehlerfrei ist. Sie können eine Umstellung nur ausführen, wenn sowohl die primäre Instanz als auch das DR-Replikat online sind.
3. Sie initiieren die Umstellung. Wenn Sie einen Switchover initiieren, wechselt die Replikation zum DR-Replikat in den synchronen Modus.
4. Das DR-Replikat holt die primäre Instanz auf und ändert seinen Status in „synchronisiert“.
5. Das DR-Replikat holt die primäre Instanz auf und ändert ihren Status in synchronisiert.
6. Wenn die Replikationsverzögerung auf null sinkt, wird das DR-Replikat zur neuen primären Instanz hochgestuft. Die neue primäre Instanz beginnt, eingehende Verbindungen zu akzeptieren, einschließlich Lese- und Schreibvorgängen der Anwendung.
7. Die alte primäre Instanz wird als Lesereplikat neu konfiguriert.
8. Der Schreibendpunkt wird aktualisiert und beginnt, auf die neue primäre Instanz zu verweisen.
9. PITR wird für die neue primäre Instanz automatisch aktiviert. PITR ist erst nach der ersten automatischen Sicherung möglich.

Schreibendpunkt

Der Schreibendpunkt ist ein DNS-Name (Domain Name Service), der in die IP-Adresse der primären Instanz aufgelöst wird. Dieser Endpunkt leitet eingehende Verbindungen bei einem Replikat-Failover oder Switchover-Vorgang automatisch an die primäre Instanz weiter. Sie können den Schreibendpunkt in einem SQL-Verbindungsstring anstelle einer IP-Adresse verwenden. Durch die Verwendung eines Schreibendpunkts können Sie vermeiden, dass Sie bei einem regionalen Ausfall Änderungen an der Anwendungsverbindung vornehmen müssen.

Für einen Schreibendpunkt muss die Cloud DNS API in dem Projekt aktiviert sein, in dem Sie die primäre Instanz der Cloud SQL Enterprise Plus-Version erstellen oder die bereits vorhandene Instanz haben. Wenn Sie eine Cloud SQL Enterprise Plus-Instanz mit einer privaten IP-Adresse und autorisierten Netzwerken erstellen, generiert Cloud SQL automatisch einen Schreibendpunkt für die Instanz. Wenn Sie bereits eine primäre Instanz von Cloud SQL Enterprise Plus haben, generiert Cloud SQL den Schreibendpunkt, wenn Sie das DR-Replikat erstellen (ein regionenübergreifendes Replikat, das Sie mit einem cascadable-replica-Flag erstellen). Wenn sich die primäre Instanz aufgrund eines Switchover- oder Replikat-Failover-Vorgangs ändert, weist Cloud SQL den Schreibendpunkt dem DR-Replikat zu, wenn das DR-Replikat zur neuen primären Instanz wird.

Weitere Informationen zum Abrufen des Schreibendpunkts für die Instanz finden Sie unter Instanzinformationen ansehen. Weitere Informationen zum Herstellen einer Verbindung zum Schreibendpunkt zur Verbindung mit der Instanz finden Sie unter Verbindung über einen Schreibendpunkt herstellen.

Nächste Schritte

• Erweiterte Notfallwiederherstellung (Disaster Recovery, DR) verwenden
• Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center