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.
Mit 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 Compute- und Speicherbereitstellung sowohl für primäre als auch für sekundäre Replikate. Es stehen zwei Hochverfügbarkeitsarchitekturmodelle zur Verfügung:
Zonenredundant 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 HA 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 zonenredundante HA nur aktivieren, wenn Sie den Server erstellen. Die zonenredundante Hochverfügbarkeit ist nur in Azure-Regionen verfügbar, die mehrere Verfügbarkeitszonen und zonenredundante Premium-Dateifreigaben unterstützen.
Hohe Verfügbarkeit in derselben Zone. Diese Option bietet Infrastrukturredundanz mit geringerer Netzwerklatenz, da sich die primären und Standbyserver in derselben Verfügbarkeitszone befinden. Es bietet hohe Verfügbarkeit, ohne dass Anwendungsredundanz über Zonen hinweg konfiguriert werden muss. Wählen Sie den ha-Wert der gleichen Zone aus, wenn Sie die höchste Verfügbarkeitsstufe innerhalb einer einzelnen Verfügbarkeitszone mit der niedrigsten Netzwerklatenz erreichen möchten. Die Hochverfügbarkeit in gleicher Zone steht in allen Azure-Regionen zur Verfügung, in denen Sie Azure Database for MySQL – Flexibler Server verwenden können.
Zonenredundante Hochverfügbarkeitsarchitektur (HA)
Wenn Sie einen Server mit zonenredundanter Hochverfü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 Computeebene, der Computegröß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 dabei, sich auf Notfallwiederherstellungssituationen und „Zone-Down“-Szenarien vorzubereiten.
Die Daten- und Protokolldateien werden in zonenredundantem Speicher (ZRS) gehostet. Der Standbyserver liest und gibt die Protokolldateien kontinuierlich aus dem Speicherkonto des primären Servers wieder, das die Replikation auf Speicherebene schü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 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-Updates, sodass Clientverbindungen direkt an die neue primäre Adresse gesendet werden, wenn der Client erneut eine Verbindung herstellen kann. 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 macht keine Standbyreplikatinformationen für den direkten Zugriff verfügbar. Commits und Schreibvorgänge werden bestätigt, nachdem die Protokolldateien im ZRS des primären Servers geleert wurden. Aufgrund der bei ZRS verwendeten synchronen Replikationstechnologie müssen Sie mit einer um 5–10 % höheren Latenz bei Schreibvorgängen und Commits durch die Anwendung rechnen.
Automatische Sicherungen (sowohl Momentaufnahmen als auch Protokollsicherungen) werden in zonenredundantem Speicher auf dem primären Datenbankserver durchgeführt.
Hochverfügbarkeitsarchitektur (Same-Zone High Availability, HA)
Wenn Sie einen Server mit ha derselben Zone 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 mit einem separaten virtuellen Computer (Compute). Durch diese Redundanz werden die Failoverzeit und die Netzwerklatenz zwischen der Anwendung und dem Datenbankserver aufgrund der Colocation reduziert.
Die Daten- und Protokolldateien werden in lokal redundantem Speicher (LRS) gehostet. Der Standbyserver liest und gibt die Protokolldateien kontinuierlich aus dem Speicherkonto des primären Servers ab, das durch die 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 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 die binären Protokolle angewandt 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. Die Informationen des Standbyreplikats werden nicht für den Direktzugriff verfügbar gemacht. 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. Die Einrichtung derselben Zone 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.
Automatische Sicherungen (sowohl Momentaufnahmen als auch Protokollsicherungen) werden in lokal redundantem Speicher des primären Datenbankservers durchgeführt.
Hinweis
Sowohl für zonenredundante Hochverfügbarkeit als auch für Hochverfügbarkeit in gleicher Zone gilt Folgendes:
- 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 eine IP-Adresse in der Verbindungszeichenfolge verwendet wird.
Failoverprozess
Während des Failoverprozesses in der Azure-Datenbank für MySQL wechselt das System automatisch vom primären Server zum Standby-Replikat. 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.
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 demselben 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 im linken Bereich im Bereich Ressourcenintegrität ausgewählt sind. Der Status stellt ein vom Benutzer initiiertes oder manuelles Failover als „Nicht verfügbar“ dar und markiert als „Geplant“. Beispiel: „Ein Failovervorgang wurde von einem autorisierten Benutzer ausgelöst (Geplant)“. Wenn Ihre Ressource für einen längeren Zeitraum in diesem Zustand verbleibt, öffnen Sie ein Supportticket und wir unterstützen Sie.
Ungeplant: automatisches Failover
Ungeplante Dienstausfallzeiten können aufgrund von Softwarefehlern oder Infrastrukturfehlern auftreten, z. B. Rechen-, Netzwerk- oder Speicherfehler. 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 Ressourcenintegrität im linken Bereich 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 Supportticket 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: Dieser Endpunkt wird intern für die Dienstkommunikation mit Verwaltungskomponenten und zum Herstellen einer Verbindung mit Back-End-Speicher 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 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 Integritätsprüfung behandelt Szenarien wie MySQL-Daemonabstürzen, Stopps oder Blockaden sowie Back-End-Speicherprobleme 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 clientseitiger Seite auftreten. Wenn Sie den privaten Zugriff verwenden, stellen Sie sicher, dass die NSG-Regeln für das virtuelle Netzwerk keine Kommunikation mit dem Instanzkundennetzwerkendpunkt am Port 3306 blockieren. Stellen Sie für den öffentlichen Zugriff sicher, dass die Firewallregeln festgelegt sind und der Netzwerkdatenverkehr am Port 3306 zulässig ist (wenn der Netzwerkpfad über andere Firewalls verfügt). Sie müssen sich auch um die DNS-Auflösung von clientanwendungsseitiger Seite kümmern.
Überwachen der hohen Verfü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 IO |
ha_io_running | Staat | DER HA-Status IO 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 bei Verwendung von hoher Verfügbarkeit die folgenden Überlegungen:
Sie können zonenredundante Hochverfügbarkeit nur während der Servererstellung konfigurieren.
Die burstfähige 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
Die automatische Speichervergrößerung ist standardmäßig für einen konfigurierten Server mit hoher Verfügbarkeit aktiviert und kann nicht deaktiviert werden.
Integritätsüberprüfungen
Wenn Sie hohe Verfügbarkeit (HA) für Die Azure-Datenbank für 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 den Status Ihres HA-Setups über das 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.
- Ressourcenauslastung: Überwacht die CPU-, Arbeitsspeicher- und Speicherauslastung, um Engpässe zu vermeiden.