Hochverfügbarkeit in Azure Database for MariaDB
Wichtig
Azure Database for MariaDB wird demnächst eingestellt. Wir empfehlen Ihnen dringend, zu Azure Database for MySQL zu migrieren. Weitere Informationen zum Migrieren nach Azure Database for MySQL finden Sie unter Was geschieht mit Azure Database for MariaDB?.
Der Azure Database for MariaDB-Dienst eignet sich zum Ausführen von unternehmenskritischen Datenbanken, die eine hohe Uptime erfordern. Er bietet Hochverfügbarkeit während:
- Geplanten Ereignissen, z. B. vom Benutzer initiierte Vorgänge zur Skalierungsberechnung.
- Ungeplanten Ereignissen, z. B. zugrundeliegende Hardware-, Software- oder Netzwerkfehler.
Azure Database for MariaDB bietet eine finanziell abgesicherte Vereinbarung zum Servicelevel für die Uptime. Da der Dienst auf der Azure-Architektur basiert, können Sie seine Funktionalitäten für Hochverfügbarkeit, Redundanz und Resilienz nutzen, ohne zusätzliche Komponenten zu konfigurieren.
Komponenten in Azure Database for MariaDB
Komponente | Beschreibung |
---|---|
MariaDB-Datenbankserver | Azure Database for MariaDB bietet Sicherheit, Isolation und Ressourcenschutzvorrichtungen und ermöglicht einen schnellen Neustart von Datenbankservern. Diese Funktionalitäten ermöglichen das Ausführen von Vorgängen wie Skalierung und Wiederherstellung von Datenbankservern (innert Sekunden) nach einem Ausfall. Änderungen an Daten auf dem Datenbankserver finden in der Regel im Rahmen von Datenbanktransaktionen statt. Alle Datenbankänderungen werden synchron in Form von Write-Ahead-Protokollen (ib_log-Dateien) in Azure Storage aufgezeichnet, der an den Datenbankserver angefügt ist. Während des Prüfpunktprozesses für die Datenbank werden außerdem Datenseiten aus dem Arbeitsspeicher des Datenbankservers in den Speicher geleert. |
Remotespeicher | Alle physischen MariaDB-Datendateien und -Protokolldateien werden in Azure Storage gespeichert, der drei Kopien der Daten in einer Region gespeichert werden, um die Redundanz, Verfügbarkeit und Zuverlässigkeit zu bieten. Die Speicherebene ist unabhängig vom Datenbankserver. Sie kann von einem fehlerhaften Datenbankserver getrennt und in wenigen Sekunden an einen neuen Datenbankserver angefügt werden. Azure Storage überwacht kontinuierlich auf Speicherfehler. Wenn eine Blockbeschädigung erkannt wird, wird das Problem automatisch behoben, indem eine neue Speicherkopie instanziiert wird. |
Gateway | Das Gateway fungiert als Datenbankproxy, indem alle Clientverbindungen an den Datenbankserver weitergeleitet werden. |
Risikominderung geplanter Downtime
Die Architektur von Azure Database for MariaDB bietet während geplanten Downtimevorgängen weiterhin Hochverfügbarkeit.
Hier sind einige Szenarien für geplante Wartung:
Szenario | Beschreibung |
---|---|
Hoch- oder Herunterskalieren von Compute | Wenn Sie einen Vorgang zur Hoch- oder Herunterskalierung für Compute ausführen, stellt Azure Database for MariaDB einen neuen Datenbankserver mithilfe der skalierten Computekonfiguration bereit. Auf dem alten Datenbankserver ermöglicht der Dienst das Beenden aktiver Prüfpunkte, leert Clientverbindungen und bricht alle nicht committeten Transaktionen ab. Der Dienst beendet dann den alten Datenbankserver. Er trennt den Speicher vom alten Datenbankserver und fügt den Speicher an den neuen Datenbankserver an. Wenn die Clientanwendung versucht, die Verbindung wiederherzustellen oder eine neue Verbindung zu erstellen, leitet das Gateway die Verbindungsanforderung an den neuen Datenbankserver weiter. |
Hochskalieren des Speichers | Das Hochskalieren des Speichers ist ein Onlinevorgang, bei dem der Datenbankserver nicht unterbrochen wird. |
Bereitstellung neuer Software (Azure) | Rollouts von neuen Features oder Fehlerbehebungen erfolgen automatisch im Rahmen der geplanten Wartung des Diensts. Weitere Informationen finden Sie in der Dokumentation und in Ihrem Portal. |
Upgrades von Nebenversionen | Azure Database for MariaDB patcht Datenbankserver automatisch auf die Nebenversion, die Azure festlegt. Automatisches Patchen erfolgt im Rahmen der geplanten Wartung des Diensts. Dabei kommt es zu einer kurzen Downtime von ein paar Sekunden, und der Datenbankserver wird automatisch mit der neuen Nebenversion neu gestartet. Weitere Informationen finden Sie in der Dokumentation und in Ihrem Portal. |
Entschärfung einer ungeplanter Downtime
Ungeplante Downtime kann aufgrund von unvorhergesehenen Fehlern auftreten, darunter Fehler in der zugrundeliegenden Hardware, Netzwerkprobleme und Softwarefehler. Wenn der Datenbankserver unerwartet ausfällt, wird automatisch innerhalb weniger Sekunden ein neuer Datenbankserver bereitgestellt. Der Remotespeicher wird automatisch an den neuen Datenbankserver angefügt.
Das MariaDB-Modul führt den Wiederherstellungsvorgang mithilfe von Write-Ahead-Protokoll- und Datenbankdateien durch und öffnet den Datenbankserver, damit Clients eine Verbindung herstellen können. Nicht committete Transaktionen gehen verloren, und die Anwendung muss sie erneut versuchen.
Obwohl Sie ungeplante Downtime nicht vollständig verhindern können, wird sie von Azure Database for MariaDB durch automatisches Ausführen von Wiederherstellungsvorgängen sowohl auf Ebene der Datenbankserver als auch des Speichers minimiert, ohne dass menschliches Eingreifen erforderlich ist.
Ungeplante Downtime: Fehlerszenarios und Dienstwiederherstellung
Hier sind zwei Fehlerszenarien und die Aktionen von Azure Database for MariaDB zur automatischen Wiederherstellung:
Szenario | Automatische Wiederherstellung |
---|---|
Ausfall des Datenbankservers | Wenn der Datenbankserver aufgrund eines zugrundeliegenden Hardwarefehlers ausgefallen ist, trennt Azure Database for MariaDB aktive Verbindungen und bricht alle sich in Ausführung befindlichen Transaktionen ab. Der Dienst stellt automatisch einen neuen Datenbankserver bereit und fügt den Remote-Datenspeicher an den neuen Datenbankserver an. Sobald die Wiederherstellung der Datenbank abgeschlossen ist, können Clients über das Gateway eine Verbindung mit dem neuen Datenbankserver herstellen. Anwendungen, welche die MariaDB-Datenbanken verwenden, müssen so konzipiert sein, dass sie getrennte Verbindungen und fehlerhafte Transaktionen erkennen und erneut versuchen. Wenn die Anwendung eine Verbindung erneut zu erstellen versucht, leitet das Gateway die Verbindung transparent an den neu erstellten Datenbankserver um. |
Speicherfehler | Speicherbezogene Probleme, z. B. ein Datenträgerfehler oder eine Beschädigung eines physischen Blocks, wirken sich nicht auf Anwendungen aus. Da die Daten in drei Kopien gespeichert werden, wird der verbleibende Speicher der Kopie der Daten bedienen. Azure Database for MariaDB korrigiert automatisch Blockbeschädigungen. Wenn eine Kopie der Daten verloren geht, erstellt der Dienst automatisch eine neue Kopie der Daten. |
Hier sind Fehlerszenarien, bei denen die Wiederherstellung eine Benutzeraktion erfordert:
Szenario | Plan für die Wiederherstellung |
---|---|
Regionsausfall | Regionen fallen nur selten aus. Wenn Sie jedoch Schutz vor einem Regionsausfall benötigen, können Sie ein oder mehrere Lesereplikate in anderen Regionen für die Notfallwiederherstellung konfigurieren. Weitere Informationen finden Sie in diesem Artikel über das Erstellen und Verwalten von Lesereplikaten. Wenn ein Fehler auf Regionsebene auftritt, können Sie ein in einer anderen Region konfiguriertes Lesereplikat manuell als Ihren Produktionsdatenbankserver heraufstufen. |
Logische Fehler/Benutzerfehler | Die Wiederherstellung nach Benutzerfehlern, z. B. versehentlich gelöschte Tabellen oder fehlerhaft aktualisierte Daten, benötigt das Durchführen einer Zeitpunktwiederherstellung. Durch diese Aktion werden die Daten bis zum Zeitpunkt unmittelbar vor dem Fehler wiederhergestellt. Wenn Sie anstelle aller Datenbanken auf dem Datenbankserver nur eine Teilmenge der Datenbanken oder bestimmte Tabellen wiederherstellen möchten, können Sie den Datenbankserver in einer neuen Instanz wiederherstellen, die Tabellen über mysqldump exportieren, und diese Tabellen dann über restore in Ihrer Datenbank wiederherstellen. |
Zusammenfassung
Azure Database for MariaDB verfügt über inhärente Hochverfügbarkeitsfunktionen, um Ihre Datenbanken vor häufigen Ausfällen zu schützen. Es bietet eine schnelle Neustartfunktion von Datenbankservern, redundanten Speicher und effizientes Routing über das Gateway. Um Ihre Daten zusätzlich zu schützen, können Sie Sicherungen als georepliziert konfigurieren und Lesereplikate in anderen Regionen bereitstellen.
Nächste Schritte
- Weitere Informationen zu Azure-Regionen.
- Erfahren Sie mehr über die Behandlung vorübergehender Verbindungsfehler.
- Erfahren Sie, wie Sie Ihre Daten mit Lesereplikaten replizieren.