Hochverfügbarkeit

MySQL   |  PostgreSQL   |  SQL Server

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 bei einem Zonenausfall oder Hardwareproblem auftreten. Mit Hochverfügbarkeit sind Ihre Daten weiterhin für Clientanwendungen verfügbar.

Die Konfiguration der Hochverfügbarkeit bietet Datenredundanz. Eine Cloud SQL-Instanz, die für Hochverfügbarkeit konfiguriert ist, wird auch als regionale Instanz bezeichnet und hat eine primäre und sekundäre 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. Bei einem Ausfall einer Instanz oder Zone wird die Standby-Instanz zur neuen primären Instanz. Anschließend werden die Nutzer auf die neue primäre Instanz umgeleitet. Dieser Vorgang wird als Failover bezeichnet.

Hinweis: In bestimmten Fällen wird von Cloud SQL ein Neustart anstelle eines Failovers ausgeführt. In diesem Fall wird Folgendes angezeigt: Neustart als Vorgang auf der Instanz, wenn Sie den Bereich Vorgänge und Logs auf der Übersichtsseite oder der Vorgangsseite der Instanz aufrufen. Beispielsweise kann die Datenbank neu gestartet werden, wenn eine Ressource aufgebraucht ist, z. B. wenn eine Instanz nicht mehr über genügend Arbeitsspeicher verfügt. Informationen zur Vermeidung von Ausfallzeiten aufgrund von Speicherproblemen finden Sie unter Hohen Arbeitsspeicherverbrauch optimieren.

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 nichtflüchtige Speicher unterstützt die Cloud SQL-Konfiguration für hohe Verfügbarkeit mit mindestens einer dedizierten CPU. Er hat eine vollständige Service Level Agreement (SLA)-Abdeckung. Eine für Hochverfügbarkeit konfigurierte Instanz kostet doppelt so viel wie eine eigenständige Instanz. Der Preis umfasst CPU, Arbeitsspeicher und Speicher. Weitere Informationen finden Sie auf der Preisseite.

Sie können ein Konto erstellen, um die Leistungsfähigkeit von Cloud SQL in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten in Cloud SQL auszuführen, zu testen und bereitzustellen. Gebühren werden ihnen erst in Rechnung gestellt, wenn sie ein Upgrade ausführen.

Registrieren Sie sich jetzt, um Cloud SQL kostenlos zu testen.

Lesereplikate

Wenn die Verfügbarkeit für Ihre Lesereplikate eine Rolle spielt, können Sie Hochverfügbarkeit für die Replikate aktivieren. Wenn Sie ein solches Replikat zur primären Instanz hochstufen, ist es bereits als hochverfügbare Instanz eingerichtet.

Während eines Zonenausfalls wird der Traffic zu Lesereplikaten in dieser Zone angehalten. Sobald die Zone wieder verfügbar ist, setzen alle Lesereplikate in der Zone die Replikation von der primären Instanz fort. Wenn sich Lesereplikate nicht in einer Zone befinden, die ausgefallen ist, werden sie mit der Standby-Instanz verbunden, wenn diese zur primären Instanz wird.

Als Best Practice empfehlen wir, einige Ihrer Lesereplikate in einer anderen Zone als der primären Instanz und Standby-Instanz zu platzieren. Wenn Sie beispielsweise eine primäre Instanz in Zone A und eine Standby-Instanz in Zone B haben, fügen Sie ein Lesereplikat in Zone C hinzu, um die Zuverlässigkeit zu erhöhen. 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.

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 Failover-Verlauf des Vorgangslogs können Sie sehen, ob ein Failover aufgetreten ist.

Weitere Informationen dazu, wie Sie Abfragen im Log-Explorer erstellen. Wenn Sie genauere Informationen zu einem Vorgang benötigen, z. B. den Nutzer, der den Vorgang ausgeführt hat, müssen Sie das Audit-Logging aktivieren.

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

Normal

Failover

Nach dem Failover

Failback

Prozess

Der folgende Prozess läuft ab:

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

  Jede Sekunde erkennt das Heartbeat-System, ob die primäre Instanz fehlerfrei ist. Wenn mehrere Heartbeats ausbleiben, wird ein Failover ausgelöst.

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

Hinweis: Tritt ein Failover auf, wechseln die Lesereplikate außerhalb der Ausfallzone die Zonen nicht. Sie liefern weiterhin Daten, selbst wenn sie sich in einer anderen Zone als die primäre Instanz befinden.

Hinweis: Wenn ein Failover auftritt, können Sie davon ausgehen, dass die Instanz ungefähr 60 Sekunden lang nicht verfügbar ist. Diese Dauer kann je nach Cloud SQL-Umgebung variieren. Weitere Informationen finden Sie unter Failover initialisieren.

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, gewartet werden oder einen lang andauernden Cloud SQL-Instanzvorgang ausführen, etwa einen Sicherungsvorgang).
• Die sekundäre Zone und die Standby-Instanz müssen beide in einem fehlerfreien Zustand sein. Wenn die Standby-Instanz nicht mehr reagiert, werden Failover-Vorgänge blockiert. Nachdem Cloud SQL die Standby-Instanz repariert hat und die sekundäre Zone wieder verfügbar ist, erlaubt Cloud SQL einen Failover.

Hinweis: Wenn sowohl die primäre Instanz als auch die Standby-Instanz nicht mehr reagieren, erlaubt Cloud SQL keinen Failover.

Sichern und wiederherstellen

Automatische Sicherungen werden für Hochverfügbarkeit dringend empfohlen.

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. 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 für einen kurzen Zeitraum nicht verfügbar sind. Weitere Informationen dazu, wie sich die Wartung auf Hochverfügbarkeitsinstanzen auswirkt, finden Sie unter So funktioniert die Wartung. Um die Auswirkungen auf Ihren Dienst zu minimieren, ändern Sie die Wartungseinstellungen, um zu steuern, wann Ausfallzeiten auftreten.

Nächste Schritte

• Hochverfügbarkeit für eine Instanz aktivieren und deaktivieren
• Failover auslösen
• Mehr über die Verwaltung von Datenbankverbindungen erfahren
• Mehr zu Regionen und Zonen in Cloud SQL