Hochverfügbarkeit konfigurieren – Übersicht

Diese Seite bietet einen Überblick über die Hochverfügbarkeitskonfiguration für Cloud SQL-Instanzen. Informationen zum Konfigurieren einer neuen Instanz mit Hochverfügbarkeit oder zum Aktivieren der Hochverfügbarkeit für eine vorhandene Instanz finden Sie unter Hochverfügbarkeit für eine Instanz aktivieren und deaktivieren.

Hochverfügbarkeit konfigurieren

Der Zweck einer Hochverfügbarkeitskonfiguration besteht darin, Ausfallzeiten zu reduzieren, wenn eine Zone oder Instanz nicht mehr verfügbar ist. Dies kann beim Ausfall einer Zone oder beim Ausfall einer Instanz auftreten. Mit Hochverfügbarkeit sind Ihre Daten weiterhin für Clientanwendungen verfügbar.

Die Hochverfügbarkeitskonfiguration, die manchmal als Cluster bezeichnet wird, gewährleistet Datenredundanz. Eine Cloud SQL-Instanz, die für Hochverfügbarkeit konfiguriert ist, wird auch als regionale Instanz bezeichnet und befindet sich in einer primären und sekundären Zone innerhalb der konfigurierten Region. Innerhalb einer regionalen Instanz besteht die Konfiguration aus einer primären Instanz und einer Standby-Instanz. Durch synchrone Replikation auf den nichtflüchtigen Speicher jeder Zone werden alle an der primären Instanz ausgeführten Schreibvorgänge auf Laufwerken in beiden Zonen repliziert, bevor eine Transaktion als Commit gemeldet wird. Sollte eine Instanz oder Zone ausfallen, wird der nichtflüchtige Speicher an die Standby-Instanz angehängt und wird zur neuen primären Instanz. Anschließend werden die Nutzer auf die neue primäre Domain umgeleitet. Dieser Vorgang wird als Failover bezeichnet.

Nach einem Failover bleibt die Instanz, die das Failover erhalten hat, weiterhin die primäre Instanz, auch wenn die ursprüngliche Instanz wieder online ist. Sobald die Zone oder Instanz, in der ein Ausfall aufgetreten ist, wieder verfügbar ist, wird die ursprüngliche primäre Instanz gelöscht und neu erstellt. Dann wird sie zur neuen Standby-Instanz. Wenn ein Failover in Zukunft stattfindet, führt ein Failover der neuen primären Instanz auf die ursprüngliche Instanz in der ursprünglichen Zone durch.

Wenn Sie die primäre Instanz in der Zone haben, die den Ausfall verursacht hat, können Sie ein Failback ausführen. Ein Failback führt dieselben Schritte wie ein Failover aus, nur in der Gegenrichtung, um Traffic zurück zur ursprünglichen Instanz zu leiten. Verwenden Sie das Verfahren unter Failover initialisieren, um ein Failback auszuführen.

Der regionale Support für nichtflüchtigen Speicher für Cloud SQL und die Cloud SQL-Konfiguration für hohe Verfügbarkeit haben eine vollständige Service Level Agreement (SLA)-Abdeckung. Die Gebühren für eine Instanz, die für hohe Verfügbarkeit konfiguriert ist, werden zum doppelten Preis einer eigenständigen Instanz berechnet. Der Preis umfasst CPU, Arbeitsspeicher und Speicher. Weitere Informationen finden Sie auf der Preisseite.

Diagrammübersicht der Cloud SQL-Konfiguration für hohe Verfügbarkeit Beschreibung im folgenden Text

Lesereplikate

Lesereplikate können nicht wie hochverfügbare Instanzen bereitgestellt werden. Während eines Zonenausfalls wird der Traffic zu Lesereplikaten in dieser Zone angehalten. Sobald die Zone wieder verfügbar ist, übernehmen alle Lesereplikate in der Zone die Replikation von der primären Instanz wieder. Wenn sich Lesereplikate in einer Zone befinden, die nicht im Ausfall ist, werden sie mit der Standby-Instanz verbunden, wenn diese zur primären Instanz wird.

Als Best Practice sollten Sie Lesereplikate in einer anderen Zone als die primären und Standby-Instanzen ablegen. Wenn Sie beispielsweise eine primäre Instanz in Zone A und eine Standby-Instanz in Zone B haben, legen Sie die Lesereplikate in Zone C fest. Diese Vorgehensweise gewährleistet, dass Lesereplikate auch dann funktionieren, wenn die Zone für die primäre Instanz ausfällt. Sie sollten auch eine Geschäftslogik in der Client-Anwendung hinzufügen, um Lesevorgänge an die primäre Instanz zu senden, wenn Lesereplikate nicht verfügbar sind.

Hinweis: Die Standby-Instanz kann nicht für Leseanfragen verwendet werden. Dies unterscheidet sich von der Legacy-Hochverfügbarkeitskonfiguration für Cloud SQL for MySQL.

Failover – Übersicht

Wenn eine für hohe Verfügbarkeit konfigurierte Instanz nicht mehr reagiert, wechselt Cloud SQL zum Bereitstellen von Daten automatisch zur Stand-by-Instanz. Im Verlauf Ihres Failover-Protokolls können Sie feststellen, ob ein Failover aufgetreten ist.

Klicken Sie auf die Tabs, um zu sehen, wie sich das Failover auf die Instanz auswirkt.

Normal

Diagramm einer fehlerfreien Instanz vor einem Failover

Failover

Diagramm einer Instanz bei einem Failover

Nach Failover

Diagramm einer Instanz nach einem Failover

Failback

Diagramm einer Instanz nach einem Failback

Prozess

Der folgende Prozess läuft ab:

  • Die primäre Instanz oder Zone schlägt fehl.

    Die primäre Instanz schreibt jede Sekunde wie ein Herzschlagsignal in die Systemdatenbank. Wenn mehrere Heartbeats ausbleiben, wird ein Failover ausgelöst. Dies tritt auf, wenn die primäre Instanz für ca. 60 Sekunden nicht antwortet oder die primäre Zone ausfällt.

  • Sobald die Standby-Instanz neu verbunden ist, liefert sie die Daten.

    Die Standby-Instanz liefert nun Daten aus der sekundären Zone über eine gemeinsame statische IP-Adresse mit der primären Instanz.

Voraussetzungen

Damit Cloud SQL ein Failover zulässt, muss die Konfiguration die folgenden Anforderungen erfüllen:

  • Die primäre Instanz muss in einem normalen Betriebszustand sein (d. h. sie darf nicht angehalten sein, nicht gewartet werden oder einen lang andauernden Cloud SQL-Instanzvorgang ausführen, etwa einen Sicherungs-, Import- oder Exportvorgang ausführen).
  • Die sekundäre Zone und die Standby-Instanz müssen beide in einem fehlerfreien Zustand sein. Wenn die Standby-Instanz nicht mehr reagiert und/oder die Replikation in die sekundäre Zone unterbrochen wird, werden Failover-Vorgänge blockiert. Nachdem Cloud SQL die Stand-by-Instanz repariert hat und die sekundäre Zone wieder verfügbar ist, wird die Replikation fortgesetzt und Cloud SQL ermöglicht einen Failover.

Sichern und wiederherstellen

Automatische Sicherungen und die Wiederherstellung zu einem bestimmten Zeitpunkt müssen für Hochverfügbarkeit aktiviert sein. Bei der Wiederherstellung zu einem bestimmten Zeitpunkt wird Binär-Logging verwendet.

Anwendungen und Instanzen

Es macht keinen Unterschied, ob Sie mit Instanzen mit hoher Verfügbarkeit oder ohne hohe Verfügbarkeit arbeiten. Daher muss Ihre Anwendung nicht auf eine bestimmte Weise konfiguriert werden. Wenn ein Failover auftritt, werden alle vorhandenen Verbindungen zur primären Instanz und den Lesereplikaten geschlossen. Es dauert etwa 2 bis 3 Minuten, bis die Verbindungen zur primären Instanz wiederhergestellt sind. Verbindungen zu Replikaten können länger dauern. Ihre Anwendung kann jedoch die Verbindung mit demselben Verbindungsstring oder derselben IP-Adresse wiederherstellen, sodass Sie die Anwendung nach dem Failover nicht aktualisieren müssen.

Sie können ein Failover manuell auslösen, um genau zu sehen, wie sich ein Failover auf Ihre Anwendungen auswirkt.

Wartungsausfallzeit

Wartungsereignisse wirken sich auf mit Hochverfügbarkeit konfigurierte primäre Instanzen auf die gleiche Weise aus wie auf jede andere Instanz. Sie können davon ausgehen, dass die primären Instanzen in dieser Zeit nicht verfügbar sind. Über ein Wartungsfenster können Sie Ausfallzeiten festlegen, um die Auswirkungen auf Ihren Dienst zu minimieren.

Wenn eine Wartung für eine Instanz ausgeführt wird, erfolgt kein Failover auf die Stand-by-Instanz. Wartungsupdates werden gleichzeitig auf die Standby-Instanz und die primäre Instanz angewendet.

Leistung

Die Leistung nichtflüchtiger Speicher hängt von vielen Faktoren ab. Beachten Sie insbesondere den VM-Instanztyp und die Arbeitslasteingabe und -ausgabe. Ein weiterer zu beachtender Messwert ist, dass die Latenz für regionalen nichtflüchtigen Speicher mit SSDs (Solid State Drives) höher ist als für nichtflüchtige Speicher mit lokalen SSDs. Das bedeutet: Wenn Ihre Arbeitslast keine Streaming-Arbeitslast und somit latenzempfindlich ist, kann sie kein Limit für Ein-/Ausgabevorgänge pro Sekunde (IOPS) erreichen, da der regionale nichtflüchtige Speicher mit SSD eine höhere Latenz hat als ein nichtflüchtiger Speicher mit lokalen SSDs. Das liegt daran, dass die für das Schreiben von zwei Kopien erforderliche Redundanz die Extremwertlatenz erhöht.

Alte MySQL-Hochverfügbarkeitsoption

Bis zum ersten Quartal 2021 haben Sie die Möglichkeit, den Legacy-Prozess zum Hinzufügen der Hochverfügbarkeit zu MySQL-Instanzen zu verwenden. Hierbei wird ein Failover-Replikat genutzt. Das Legacy-Feature ist in der Cloud Console nicht verfügbar. Verwenden Sie stattdessen die gcloud- oder cURL-Befehle. Weitere Informationen erhalten Sie unter Legacy-Konfiguration: Neue Instanz mit Hochverfügbarkeit erstellen oder Legacy-Konfiguration: Eine bestehende Instanz für Hochverfügbarkeit konfigurieren.

Nächste Schritte