Freigeben über

Hohe Verfügbarkeit in Azure Database for MySQL

Mithilfe von Azure Database for MySQL Flexible Server können Sie hohe Verfügbarkeit mit automatischem Failover konfigurieren. Diese Lösung stellt sicher, dass Fehler niemals zu Datenverlust führen und dass die Datenbank kein einzelner Fehlerpunkt in Ihrer Softwarearchitektur ist. Wenn Sie hohe Verfügbarkeit konfigurieren, stellt Flexible Server automatisch ein Standby-Replikat bereit und verwaltet es. Sie bezahlen für die bereitgestellte Rechenleistung und den Speicher sowohl für die primären als auch für die sekundären Replikate. Es stehen zwei Hochverfügbarkeitsarchitekturmodelle zur Verfügung:

  • Zonenredundante hohe Verfügbarkeit. Diese Option bietet vollständige Isolation und Redundanz der Infrastruktur über mehrere Verfügbarkeitszonen hinweg. Es bietet die höchste Verfügbarkeitsebene, erfordert jedoch, dass Sie Anwendungsredundanz über Zonen hinweg konfigurieren. Wählen Sie zonenredundante hohe Verfügbarkeit aus, wenn Sie vor Infrastrukturfehlern in der Verfügbarkeitszone schützen möchten und wenn die Latenz in der Verfügbarkeitszone akzeptabel ist. Sie können die zonenredundante hohe Verfügbarkeit nur aktivieren, wenn Sie den Server erstellen. Zonenredundante hohe Verfügbarkeit ist in einer Teilmenge der Azure-Regionen verfügbar, in denen die Region mehrere Verfügbarkeitszonen und zonenredundante Premium-Dateifreigaben unterstützt.

  • Lokal redundante Hochverfügbarkeit. Diese Option bietet Infrastrukturredundanz mit geringerer Netzwerklatenz, da sich die primären und Standbyserver in derselben Verfügbarkeitszone befinden. Sie bietet hohe Verfügbarkeit, ohne dass Anwendungsredundanz über Zonen hinweg konfiguriert werden muss. Wählen Sie die lokale redundante Hohe Verfügbarkeit aus, wenn Sie die höchste Verfügbarkeitsebene innerhalb einer einzelnen Verfügbarkeitszone mit der niedrigsten Netzwerklatenz erreichen möchten. Lokale redundante Hochverfügbarkeit ist in allen Azure Regionen verfügbar, in denen Sie Azure Database for MySQL Flexible Server verwenden können.

Zonenredundante Hochverfügbarkeitsarchitektur (HA)

Wenn Sie einen Server mit zonenredundanter Hoher Verfügbarkeit bereitstellen, erstellt Azure zwei Server:

  • Ein primärer Server in einer Verfügbarkeitszone.
  • Ein Standby-Replikatserver in einer anderen Verfügbarkeitszone derselben Azure Region. Der Standby-Replikatserver hat dieselbe Konfiguration wie der primäre Server, einschließlich der Compute-Ebene, der Compute-Größe, der Speichergröße und der Netzwerkkonfiguration.

Sie können die Verfügbarkeitszone für den primären Server und das Standbyreplikat auswählen. Wenn Sie die Datenbankserver für das Standbyreplikat und die Standbyanwendungen in derselben Zone platzieren, reduzieren Sie die Latenz. Es hilft Ihnen auch bei der Vorbereitung auf Notfallwiederherstellungssituationen und Zonenausfallszenarien.

Diagramm, das die Architektur für lokal redundante Hochverfügbarkeit zeigt.

Die Daten- und Protokolldateien werden in zone-redundantem Speicher (ZRS) gehostet. Der Standbyserver liest und spielt die Protokolldateien kontinuierlich aus dem Speicherkonto des primären Servers ab, das durch Replikation auf Speicherebene geschützt ist.

Bei Auftreten eines Failovers:

  • Das Standbyreplikat wird aktiviert.
  • Die binären Protokolldateien des primären Servers werden weiterhin auf den Standbyserver angewendet, um sie online zur letzten zugesicherten Transaktion auf dem primären Server zu bringen.

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 binäre Protokolle angewendet wurden, übernimmt der aktuelle Standby-Replikatserver die Rolle des primären Servers. DNS-Aktualisierungen, damit Clientverbindungen beim erneuten Verbinden des Clients auf den neuen primären DNS-Server umgeleitet werden. Das Failover ist für die Clientanwendung vollständig transparent und benötigt keinerlei Aktionen von Ihrer Seite. Die Hochverfügbarkeitslösung schaltet dann nach Möglichkeit den alten primären Server wieder online und legt ihn als Standbyserver fest.

Sie verwenden den Datenbankservernamen, um Anwendungen mit dem primären Server zu verbinden. Die Lösung stellt keine Standby-Replikat-Informationen für direkten Zugriff bereit. Commits und Schreibvorgänge werden bestätigt, nachdem die Protokolldateien im ZRS des primären Servers geleert wurden. Aufgrund der in ZRS-Speicher verwendeten Synchronreplikationstechnologie können Sie 5 bis 10 Prozent höhere Latenzzeiten für Schreib- und Commit-Vorgänge von Anwendungen erwarten.

Der primäre Datenbankserver sichert automatisch sowohl Momentaufnahmen als auch Protokollsicherungen auf zoneredundantem Speicher.

Lokale redundante Hochverfügbarkeitsarchitektur (HA)

Wenn Sie einen Server mit lokal redundantem HA bereitstellen, erstellen Sie zwei Server in derselben Zone:

  • Ein primärer Server
  • Ein Standbyreplikatserver mit derselben Konfiguration wie der primäre Server (Computeebene, Computegröße, Speichergröße und Netzwerkkonfiguration)

Der Standbyserver bietet Infrastrukturredundanz mithilfe eines separaten virtuellen Computers (Compute). Durch diese Redundanz werden die Failoverzeit und die Netzwerklatenz zwischen der Anwendung und dem Datenbankserver aufgrund der Colocation reduziert.

Diagramm, das die Architektur für lokal redundante Hochverfügbarkeit zeigt.

Die Daten- und Protokolldateien werden in locally redundant storage (LRS) gehostet. Der Standbyserver liest kontinuierlich die Protokolldateien aus dem Speicherkonto des primären Servers und spielt sie erneut ab. Dieses Konto wird durch Speicherreplikation geschützt.

Bei Auftreten eines Failovers:

  • Das Standbyreplikat wird aktiviert.
  • Die binären Protokolldateien des primären Servers werden weiterhin auf den Standbyserver angewendet, um sie online zur letzten zugesicherten Transaktion auf dem primären Server zu bringen.

Auf Protokolle im LRS 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 binäre Protokolle angewendet wurden, übernimmt das aktuelle Standbyreplikat die Rolle des primären Servers. Das DNS wird aktualisiert, um Verbindungen an den neuen primären Server umzuleiten, wenn der Client erneut eine Verbindung herstellt. Das Failover ist für die Clientanwendung vollständig transparent und benötigt keinerlei Aktionen von Ihrer Seite. Die Hochverfügbarkeitslösung schaltet dann nach Möglichkeit den alten primären Server wieder online und legt ihn als Standbyserver fest.

Der Datenbankservername verbindet Anwendungen mit dem primären Server. Standby-Replikatinformationen werden für den direkten Zugriff nicht offengelegt. Commits und Schreibvorgänge werden bestätigt, nachdem die Protokolldateien im LRS des primären Servers geleert wurden. Da sich das primäre Replikat und das Standbyreplikat in derselben Zone befinden, gibt es weniger Verzögerung bei der Replikation und eine geringere Latenz zwischen dem Anwendungsserver und dem Datenbankserver. Das lokal redundante Setup bietet keine hohe Verfügbarkeit, wenn abhängige Infrastrukturen für die spezifische Verfügbarkeitszone nicht verfügbar sind. Es gibt Ausfallzeiten, bis alle abhängigen Dienste für diese Verfügbarkeitszone wieder online sind.

Der primäre Datenbankserver sichert sowohl Momentaufnahmen als auch Protokollsicherungen automatisch auf lokal redundanten Speicher.

Hinweis

Sowohl für zonenredundante als auch für lokal-redundante HA:

  • Wenn ein Fehler auftritt, hängt die Für die Übernahme der Rolle des primären Replikats benötigte Zeit von der Wiedergabe des Binärprotokolls aus dem primären Speicherkonto in den Standbymodus ab. Verwenden Sie Primärschlüssel für alle Tabellen, um die Failoverzeit zu reduzieren. Failoverzeiten dauern in der Regel zwischen 60 und 120 Sekunden.
  • Der Standbyserver ist nicht für Lese- oder Schreibvorgänge verfügbar. Er dient als passiver Standbyserver, der ein schnelles Failover ermöglichen soll.
  • Verwenden Sie immer den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) für Verbindungen mit dem primären Server. Vermeiden Sie die Verwendung einer IP-Adresse zum Herstellen einer Verbindung. Wenn ein Failover auftritt, kann sich ein DNS-A-Eintrag ändern, nachdem die primären und Standbyserverrollen gewechselt wurden. Diese Änderung verhindert, dass die Anwendung eine Verbindung mit dem neuen primären Server herstellt, wenn im Verbindungszeichenfolge eine IP-Adresse verwendet wird.

Failoverprozess

Während des Failoverprozesses in Azure Database for MySQL wechselt das System automatisch vom primären Server zum Standbyreplikat. Dieser Schalter stellt die Kontinuität sicher und minimiert Ausfallzeiten. Wenn das System einen Fehler erkennt, fördert es das Standby-Replikat, um zum neuen primären Server zu werden. Das System wendet die binären Protokolldateien vom ursprünglichen primären Server auf das Standbyreplikat an. Dieser Prozess synchronisiert das Standbyreplikat mit der letzten zugesicherten Transaktion und stellt keinen Datenverlust sicher. Dieser nahtlose Übergang trägt dazu bei, hohe Verfügbarkeit und Zuverlässigkeit des Datenbankdiensts aufrechtzuerhalten.

Hinweis

Um die Abhängigkeit der Failover-Zeit von der DNS-Zwischenspeicherung ab Oktober 2025 zu reduzieren, übernehmen alle neuen Hochverfügbarkeitsserver, die mit öffentlichem Zugriff oder privater Verbindung erstellt wurden, die neue Architektur mit einer dedizierten SLB für jeden Hochverfügbarkeitsserver. Durch die Verwaltung des MySQL-Datendatenverkehrspfads beseitigt SLB die Notwendigkeit von DNS-Änderungen während des Failovers und verbessert die Failoverleistung erheblich. Der Datenverkehr wird während des Failovers mithilfe von Lastenausgleichsregeln an die aktuelle primäre Instanz umgeleitet. Vorhandene Server mit öffentlichem Zugriff oder privatem Link werden schrittweise migriert, um deren Auswirkungen zu minimieren. Kunden, die eine frühe Migration bevorzugen, können hohe Verfügbarkeit deaktivieren und erneut aktivieren. Dieses Feature wird für Server, die private access mit der VNet-Integration verwenden, nicht unterstützt.

Geplant: erzwungenes Failover

Mit dem erzwungenen Failover von Azure Database for MySQL – Flexibler Server können Sie ein Failover manuell erzwingen. Mit dieser Funktion können Sie die Funktionalität mit Ihren Anwendungsszenarien testen und sich auf Ausfälle vorbereiten.

Beim erzwungenen Failover wird ein Failover ausgelöst. Dabei wird das Standbyreplikat aktiviert und als Primärserver mit Verwendung desselben Datenbankservernamen festgelegt, indem der DNS-Eintrag aktualisiert wird. Der ursprüngliche primäre Server startet neu und wechselt zum Standbyreplikat. Clientverbindungen trennen die Verbindung und müssen erneut verbunden werden, um ihre Vorgänge fortzusetzen.

Die gesamte Dauer des Failovers hängt von der aktuellen Workload und dem letzten Prüfpunkt ab. Im Allgemeinen dauert es zwischen 60 und 120 Sekunden.

Hinweis

Ein Azure Resource Health-Ereignis wird während eines geplanten Failovers generiert. Das Ereignis stellt die Failoverzeit dar, in der der Server nicht verfügbar ist. Sie können die ausgelösten Ereignisse sehen, wenn sie auf Resource Health im linken Bereich ausgewählt sind. Der Status zeigt sowohl ein vom Benutzer initiiertes oder manuelles Failover als "Nicht verfügbar" als auch als "Geplant" an. Beispielsweise wurde ein Failovervorgang von einem autorisierten Benutzer (geplant) ausgelöst. Wenn Ihre Ressource für einen längeren Zeitraum in diesem Zustand verbleibt, öffnen Sie ein support-Ticket und wir unterstützen Sie.

Ungeplant: automatisches Failover

Ungeplante Dienstausfallzeiten können aufgrund von Softwarefehlern oder Infrastrukturfehlern auftreten, z. B. Compute-, Netzwerk- oder storage-Fehler. Stromausfälle können sich auch auf die Verfügbarkeit der Datenbank auswirken. Wenn die Datenbank nicht verfügbar ist, wird die Replikation mit dem Standby-Replikat beendet, und das Standbyreplikat wird zur primären Datenbank. DNS-Updates treten auf, und Clients stellen erneut eine Verbindung mit dem Datenbankserver her, wobei deren Vorgänge fortgesetzt werden.

Die Gesamtfailoverzeit liegt in der Regel zwischen 60 und 120 Sekunden. Abhängig von der Aktivität auf dem primären Datenbankserver zum Zeitpunkt des Failovers, wie z. B. umfangreiche Transaktionen, und der Wiederherstellungszeit kann das Failover jedoch länger dauern.

Hinweis

Ein Azure Resource Health-Ereignis wird während eines ungeplanten Failovers generiert. Das Ereignis stellt die Failoverzeit dar, wenn der Server nicht verfügbar ist. Sie können die ausgelösten Ereignisse sehen, wenn Sie im linken Bereich Resource Health auswählen. Das automatische Failover zeigt den Status " Nicht verfügbar" an und wird als "Ungeplant" markiert.

Beispiel: Ein Failovervorgang wurde automatisch ausgelöst (ungeplant). Wenn Ihre Ressource lange in diesem Zustand bleibt, öffnen Sie ein Support-Ticket und wir helfen Ihnen.

Funktionsweise der automatischen Failovererkennung auf Servern mit aktivierter Hochverfügbarkeit

Der primäre Server und der sekundäre Server verfügen jeweils über zwei Netzwerkendpunkte:

  • Kunden-Endpunkt: Kunden stellen über diesen Endpunkt eine Verbindung her und führen Abfragen auf der Instanz aus.
  • Verwaltungsendpunkt: Wird intern für die Dienstkommunikation zu Verwaltungskomponenten und zum Herstellen einer Verbindung mit Back-End-storage verwendet.

Die Komponente „Integritätsüberwachung“ führt kontinuierlich die folgenden Prüfungen durch:

  • Der Monitor pingt den Verwaltungsnetzwerkendpunkt des Knotens. Wenn diese Überprüfung zweimal hintereinander fehlschlägt, wird ein automatischer Failover-Vorgang ausgelöst. Diese Integritätsprüfung befasst sich mit Szenarien wie der Nichtverfügbarkeit von Knoten oder der Nichtzuverlässigkeit aufgrund von Betriebssystemproblemen, Netzwerkproblemen zwischen Verwaltungskomponenten und Knoten und ähnlichen Problemen.
  • Der Monitor führt eine einfache Abfrage für die Instanz aus. Wenn die Abfragen nicht ausgeführt werden können, werden automatische Failovertrigger ausgelöst. Diese Gesundheitsprüfung behandelt Szenarien wie MySQL-Daemon-Abstürze, Anhalten oder Hängen sowie Backend-Storage-Probleme und ähnliche Probleme.

Hinweis

Die Integritätsprüfung überwacht keine Netzwerkprobleme zwischen der Anwendung und dem Kundennetzwerkendpunkt (privater/öffentlicher Zugriff). Diese Probleme können im Netzwerkpfad, auf dem Endpunkt oder in DNS-Problemen auf der Clientseite auftreten. Wenn Sie privaten Zugriff verwenden, stellen Sie sicher, dass die NSG-Regeln für das virtuelle Netzwerk die Kommunikation mit dem Netzwerkendpunkt des Instanzkunden auf Port 3306 nicht blockieren. Stellen Sie für öffentlichen Zugriff sicher, dass die Firewall-Regeln festgelegt sind und der Netzwerkdatenverkehr auf Port 3306 erlaubt ist, sofern der Netzwerkpfad über andere Firewalls verfügt. Sie müssen sich auch um die DNS-Auflösung von clientanwendungsseitiger Seite kümmern.

Überwachen der Hochverfügbarkeit

Um den Hochverfügbarkeitskonfigurationsstatus des Servers zu überprüfen, verwenden Sie den Hochverfügbarkeitsstatus im Hochverfügbarkeitsbereich des Servers im Portal.

Status Beschreibung
NotEnabled Hohe Verfügbarkeit ist nicht aktiviert.
ReplicatingData Der Standbyserver wird während der Hochverfügbarkeitsserverbereitstellung mit dem primären Server synchronisiert oder wenn Sie die Option für hohe Verfügbarkeit aktivieren.
FailingOver Der Datenbankserver weist einen Fehler vom primären auf den Standbymodus auf.
Gesund Die Option für hohe Verfügbarkeit ist aktiviert.
RemovingStandby Der Löschvorgang wird ausgeführt, wenn Sie die Option für hohe Verfügbarkeit deaktivieren.

Verwenden Sie die folgenden Metriken, um die Integrität des Hochverfügbarkeitsservers zu überwachen.

Anzeigename der Metrik Metrik Einheit Beschreibung
HA-Status ha_io_running Staat DER HA-Status zeigt den Status der HA-Replikation an. Der Metrikwert ist 1, wenn der E/A-Thread ausgeführt wird, und 0, falls nicht.
SQL-Status für HA ha_sql_running Staat Der HA SQL-Status zeigt den Status der HA-Replikation an. Der Metrikwert ist 1, wenn der SQL-Thread ausgeführt wird, und 0, falls nicht.
Verzögerung bei der Hochverfügbarkeitsreplikation replication_lag Sekunden Die Replikationsverzögerung ist die Anzahl der Sekunden, die der Standbyserver bei der Übergabe der Transaktionen zurück liegt, die am primären Server empfangen wurden.

Einschränkungen

Beachten Sie beim Verwenden von hoher Verfügbarkeit die folgenden Überlegungen:

  • Sie können zonenredundante hohe Verfügbarkeit nur bei der Erstellung des Servers konfigurieren.

  • Die platzbare Computeebene unterstützt keine hohe Verfügbarkeit.

  • Wenn Sie den primären Datenbankserver neu starten, um statische Parameteränderungen anzuwenden, wird auch das Standbyreplikat neu gestartet.

  • Die Lösung aktiviert den GTID-Modus, da er GTID verwendet. Überprüfen Sie, ob für Ihre Workload Einschränkungen für die Replikation mit GTID gelten.

Hinweis

Automatische Speichererweiterung ist standardmäßig für Server mit hoher Verfügbarkeit aktiviert und kann nicht deaktiviert werden.

Bekannte Probleme

Azure Database for MySQL Flexible Server verwendet die native MySQL-Replikation im Back-End. In der MySQL Community Edition 8.0 und höher ist ein bekanntes Problem aufgetreten, das die Replikation unterbrechen kann, wenn ein mehrstellbarer DELETE-Vorgang ausgeführt wird, der auf Fremdschlüsseleinschränkungen mit ON DELETE CASCADE basiert. Dieses Problem wird als MySQL Bug 102586 nachverfolgt. Wenn Sie daher hohe Verfügbarkeit auf Azure Database for MySQL Flexible Server aktivieren, vermeiden Sie die Verwendung von überlappenden Löschvorgängen mit Fremdschlüsseln, da dieses Muster zu Replikationsfehlern führen kann und sich auf die Verfügbarkeit des Servers auswirken kann.

Integritätsüberprüfungen

Wenn Sie hohe Verfügbarkeit (HA) für Azure Database for MySQL konfigurieren, spielen Integritätsprüfungen eine entscheidende Rolle bei der Aufrechterhaltung der Zuverlässigkeit und Leistung Ihrer Datenbank. Diese Überprüfungen überwachen kontinuierlich den Status und die Integrität der primären und Standby-Replikate, um sicherzustellen, dass probleme umgehend erkannt werden. Durch das Nachverfolgen verschiedener Metriken wie Serverreaktionsfähigkeit, Replikationsverzögerung und Ressourcenauslastung tragen Integritätsprüfungen dazu bei, sicherzustellen, dass Failoverprozesse nahtlos ausgeführt werden können, Ausfallzeiten minimiert und Datenverluste verhindert werden. Ordnungsgemäß konfigurierte Integritätsprüfungen sind unerlässlich, um die gewünschte Verfügbarkeit und Resilienz in Ihrer Datenbankeinrichtung zu schaffen.

Überwachen der Integrität

Sie können die Integrität Ihres HA-Setups über die Azure-Portal überwachen. Zu den wichtigsten zu beobachtenden Metriken gehören:

  • Serverreaktivität: Gibt an, ob der primäre Server erreichbar ist.
  • Replikationsverzögerung: Misst die Verzögerung zwischen primären und Standby-Replikaten, wodurch die Datenkonsistenz sichergestellt wird.
  • Ressourcennutzung: Überwacht die Nutzung von CPU, Arbeitsspeicher und Speicher, um Engpässe zu vermeiden.

Verwandte Inhalte

  • Hohe Verfügbarkeit
  • Geschäftskontinuität
  • Zonenredundante Hochverfügbarkeit
  • Sicherung und Wiederherstellung:
  • Last updated on