Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Hohe Verfügbarkeit ist ein wichtiges Feature der Azure-Datenbank für MySQL, das darauf ausgelegt ist, Ausfallzeiten zu minimieren und sicherzustellen, dass Ihre Anwendungen auch bei geplanten Wartungs- oder unerwarteten Ausfällen zugänglich bleiben. Dieser Artikel befasst sich mit häufigen Fragen zu Optionen für hohe Verfügbarkeit, Abrechnung, Failoverprozesse, Leistungsbeeinträchtigungen und bewährten Methoden, mit denen Sie fundierte Entscheidungen für Ihre MySQL-Workloads in Azure treffen können.
Was sind die SLAs für lokale redundante und zonenredundante HA-aktivierte flexible Server?
SLA-Informationen für Azure Database for MySQL – Flexibler Server finden Sie unter SLA für Azure Database for MySQL.
Wie werden hochverfügbare Server (HA) in Rechnung gestellt?
Server, für die die Hochverfügbarkeit aktiviert ist, verfügen über ein primäres und ein sekundäres Replikat. Sekundäre Replikate können sich in derselben Zone befinden oder zonenredundant sein. Ihnen werden die bereitgestellte Compute und der bereitstellte Speicher sowohl für das primäre als auch für das sekundäre Replikat in Rechnung gestellt. Wenn Sie beispielsweise über eine primäre Version mit 4 vCores von Compute und 512 GB bereitgestelltem Speicher verfügen, verfügt Ihr sekundäres Replikat über 4 vCores und 512 GB bereitgestellten Speicher.
Ihr zone-redundanter HA-Server wird mit 8 vCores und 1.024 GB Speicherplatz berechnet. Abhängig von Ihrem Sicherungsspeichervolume wird Ihnen möglicherweise auch der Sicherungsspeicher in Rechnung gestellt.
Kann ich das Standbyreplikat für Lese- oder Schreibvorgänge verwenden?
Der Standbyserver ist nicht für Lese- oder Schreibvorgänge verfügbar. Er dient als passiver Standbyserver, der ein schnelles Failover ermöglichen soll.
Kommt es bei einem Failover zu Datenverlusten?
Auf Protokolle im ZRS kann auch dann zugegriffen werden, wenn der primäre Server nicht verfügbar ist. Durch diese Verfügbarkeit wird sichergestellt, dass keine Daten verloren gehen. Nachdem das Standbyreplikat aktiviert und die binären Protokolle angewandt wurden, übernimmt das Standbyreplikat die Funktionen des primären Servers.
Muss ich nach einem Failover Maßnahmen ergreifen?
Failovers sind für die Clientanwendung vollständig transparent. Sie müssen also keine Maßnahmen ergreifen. Die Anwendungen sollten lediglich die Wiederholungslogik für ihre Verbindungen nutzen.
Was geschieht, wenn ich keine spezifische Zone für mein Standbyreplikat auswähle? Kann ich die Zone später ändern?
Wenn Sie keine Zone auswählen, wird eine nach dem Zufallsprinzip ausgewählt. Es ist die für den primären Server verwendete. Wenn Sie die Zone später ändern möchten, können Sie im Bereich "Hohe Verfügbarkeit" auf "Deaktiviert" festlegen und dann auf "Zone Redundant" zurücksetzen und eine Zone auswählen.
Erfolgt die Replikation zwischen dem primären Replikat und den Standbyreplikaten synchron?
Die Replikation zwischen dem primären und dem Standbymodus ähnelt dem semisynchronen Modus in MySQL. Wenn eine Transaktion committet wird, erfolgt nicht unbedingt ein Commit auf den Standbyserver. Wenn die primäre Datei jedoch nicht verfügbar ist, repliziert der Standbymodus alle Datenänderungen aus dem primären, um sicherzustellen, dass kein Datenverlust besteht.
Wird bei allen ungeplanten Ausfällen ein Failover auf das Standbyreplikat durchgeführt?
Wenn ein Datenbankabsturz oder ein Knotenfehler auftritt, wird die VM des flexiblen Servers auf demselben Knoten neu gestartet. Gleichzeitig wird ein automatisches Failover ausgelöst. Wenn der VM-Neustart des flexiblen Servers erfolgreich ist, bevor das Failover abgeschlossen ist, wird der Failovervorgang abgebrochen. Die Bestimmung, welcher Server als primäres Replikat verwendet werden soll, hängt von dem Prozess ab, der zuerst abgeschlossen ist.
Hat die Verwendung von Hochverfügbarkeit Auswirkungen auf die Leistung?
Bei zonenredundanter Hochverfügbarkeit gibt es zwar keine größeren Leistungseinbußen bei Lese-Workloads in Verfügbarkeitszonen, aber die Latenz beim Schreiben von Abfragen kann um bis zu 40 Prozent sinken. Der Anstieg der Schreiblatenz ist auf die synchrone Replikation in der Verfügbarkeitszone zurückzuführen. Die Schreiblatenzauswirkungen sind bei zonenredundanter HA doppelt so hoch im Vergleich zu derselben Zonen-HA. Bei lokal redundantem HA, da sich das primäre und das Standbyreplikat in derselben Zone befinden, ist die Replikationslatenz und damit die synchrone Schreiblatenz niedriger.
Wenn die Schreiblatenz im Vergleich zur Verfügbarkeit wichtiger ist, sollten Sie möglicherweise eine lokal redundante HA auswählen. Wenn jedoch die Verfügbarkeit und Resilienz Ihrer Daten für Sie auf Kosten einer geringeren Schreiblatenz wichtiger ist, müssen Sie eine zonenredundante HA auswählen. Um die genaue Auswirkung des Latenzabbruchs im HA-Setup zu messen, empfehlen wir Ihnen, Leistungstests für Ihre Workload durchzuführen, um eine fundierte Entscheidung zu treffen.
Wie wird mein Hochverfügbarkeitsserver gewartet?
Geplante Ereignisse wie die Skalierung von Rechenleistung und kleinere Versions-Upgrades werden zuerst auf der ursprünglichen Standbyinstanz durchgeführt, dann wird ein geplanter Failovervorgang ausgelöst und anschließend auf der ursprünglichen primären Instanz ausgeführt. Sie können das Zeitfenster für geplante Wartungen für Hochverfügbarkeitsserver genauso wie für Flexibler Server festlegen. Die Anzahl der Ausfallzeiten entspricht der Ausfallzeit für die Azure-Datenbank für mySQL Flexible Server-Instanz, wenn HA deaktiviert ist.
Kann ich eine Zeitpunktwiederherstellung (Point-in-Time Restore, PITR) für meinen Hochverfügbarkeitsserver durchführen?
Sie können einen PITR für eine HA-fähige Azure-Datenbank für MySQL Flexible Server-Instanz in einer neuen Azure-Datenbank für MySQL Flexible Server-Instanz ausführen, die HA deaktiviert hat. Wenn der Quellserver mit zonenredundanten HA erstellt wurde, können Sie zonenredundante HA oder lokal redundante HA auf dem wiederhergestellten Server später aktivieren. Wenn der Quellserver mit local-redundant HA erstellt wurde, können Sie nur den lokalen redundanten HA auf dem wiederhergestellten Server aktivieren.
Kann ich Hochverfügbarkeit auf einem Server aktivieren, nachdem der Server erstellt wurde?
Zonenredundanter HA muss während der Servererstellung aktiviert werden. Sie können lokale redundante HA nach der Servererstellung aktivieren, aber stellen Sie sicher, dass die Serverparameter enforce_gtid_consistency und gtid_mode auf den Wert ON festgelegt sind, bevor Sie fortfahren.
Kann ich die Hochverfügbarkeit für einen Server deaktivieren, nachdem dieser erstellt wurde?
Sie können HA auf einem Server deaktivieren, nachdem Sie ihn erstellt haben. Die Abrechnung wird sofort beendet.
Wie kann ich die Downtime verkürzen?
Sie müssen in der Lage sein, Ausfallzeiten für Ihre Anwendung zu minimieren, auch wenn Sie HA nicht verwenden. Dienstdowntime, z. B. durch geplante Patches, Nebenversionsupgrades oder von der Kundschaft initiierte Vorgänge wie die Computeskalierung, können während geplanter Wartungsfenster ausgeführt werden. Um die Auswirkungen von Anwendungen für von Azure initiierte Wartungsaufgaben zu verringern, können Sie sie an einem Wochentag und einer Zeit planen, die die Auswirkungen auf die Anwendung minimiert.
Kann ich ein Lesereplikat für einen Server verwenden, für den Hochverfügbarkeit aktiviert ist?
Ja, Lesereplikate werden für HA-Server unterstützt.
Kann ich die Datenreplikation für Hochverfügbarkeitsserver nutzen?
Der Support für die Replikation eingehender Daten für Hochverfügbarkeits (HA)-fähige Server ist nur über die GTID-basierte Replikation verfügbar.
Die gespeicherte Prozedur für die Replikation mit GTID ist auf allen HA-fähigen Servern unter dem Namen mysql.az_replication_with_gtidverfügbar.
Kann ich während eines Serverneustarts oder beim Hoch- bzw. Herunterskalieren ein Failover auf den Standbyserver durchführen, um die Downtime zu verringern?
Derzeit hat Azure-Datenbank für MySQL Flexible Server ein geplantes Failover genutzt, um die HA-Vorgänge zu optimieren, einschließlich der Skalierung nach oben/unten und der geplanten Wartung, um die Ausfallzeiten zu reduzieren.
Wenn solche Vorgänge gestartet werden, wird zuerst die ursprüngliche Standbyinstanz verarbeitet, dann ein geplanter Failovervorgang ausgelöst und schließlich die ursprüngliche primäre Instanz verarbeitet.
Können wir den Verfügbarkeitsmodus (zonenredundante Hochverfügbarkeit/lokal redundant) des Servers ändern**
Wenn Sie den Server mit aktiviertem zonenredundantem HA-Modus erstellen, können Sie vom zonenredundanten HA-Modus zu einem lokal-redundanten wechseln und umgekehrt.
Um den Verfügbarkeitsmodus zu ändern, können Sie im Bereich "Hohe Verfügbarkeit" auf "Deaktiviert" festlegen und dann auf "Zone Redundant" oder "Lokal redundant" zurücksetzen und den Modus "Hohe Verfügbarkeit" auswählen.