Übersicht über die Geschäftskontinuität mit Azure Database for MySQL – Flexible Server

  • Artikel

GILT FÜR: Azure Database for MySQL – Flexible Server

Azure Database for MySQL flexible Server ermöglicht Geschäftskontinuitätsfunktionen, die Ihre Datenbanken im Falle eines geplanten und ungeplanten Ausfalls schützen. Features wie automatische Sicherungen und Hochverfügbarkeit adressieren verschiedene Ebenen des Fehlerschutzes mit unterschiedlichen Wiederherstellungszeiten und Datenverlusten. Wenn Sie Ihre Anwendung zum Schutz vor Fehlern gestalten, sollten Sie für jede Anwendung das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO) berücksichtigen. RTO ist die Downtimetoleranz und RPO die Datenverlusttoleranz nach einer Unterbrechung des Datenbankdiensts.

In der folgenden Tabelle sind die Features dargestellt, die Azure Database für mySQL flexible Server bietet.

Feature Beschreibung Einschränkungen
Sicherung und Wiederherstellung Der Dienst führt automatisch tägliche Sicherungen Ihrer Datenbankdateien durch und sichert kontinuierlich Transaktionsprotokolle. Sicherungen können zwischen 1 und 35 Tagen aufbewahrt werden. Sie können Den Datenbankserver zu einem beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums der Sicherung wiederherstellen. Die Wiederherstellungszeit hängt von der Größe der Daten ab, die wiederhergestellt werden sollen, und der Zeit zum Durchführen der Protokollwiederherstellung. Weitere Informationen finden Sie unter Konzepte: Sicherung und Wiederherstellung. Sicherungsdaten verbleiben innerhalb der Region
Lokal redundante Sicherung Die Dienstsicherungen werden automatisch und sicher in einem lokal redundanten Speicher innerhalb einer Region sowie in derselben Verfügbarkeitszone gespeichert. Die lokal redundanten Sicherungen replizieren die Sicherungsdatendateien des Servers dreimal innerhalb eines einzelnen physischen Standorts in der primären Region. Lokal redundanter Sicherungsspeicher stellt eine Dauerhaftigkeit von mindestens 99,999999999 % (11 Neunen) für Objekte in einem bestimmten Jahr bereit. Weitere Informationen finden Sie unter Konzepte: Sicherung und Wiederherstellung. Anwendbar in allen Regionen
Georedundante Sicherung Die Dienstsicherungen können zur Erstellungszeit als georedundante Sicherungen konfiguriert werden. Durch die Aktivierung von Georedundanz werden die Sicherungsdatendateien des Servers in die gekoppelte Region der primären Region repliziert, um regionale Resilienz zu bieten. Georedundanter Sicherungsspeicher stellt eine Dauerhaftigkeit von mindestens 99,99999999999999 % (16 Neunen) für Objekte im Lauf eines Jahres bereit. Weitere Informationen finden Sie unter Konzepte: Sicherung und Wiederherstellung. In allen gekoppelten Azure-Regionen verfügbar.
Zonenredundante Hochverfügbarkeit Der Dienst kann im Hochverfügbarkeitsmodus bereitgestellt werden, bei dem primäre und Standbyserver in zwei verschiedenen Verfügbarkeitszonen innerhalb einer Region bereitgestellt werden. Die redundante Hohe Verfügbarkeit der Zone schützt vor Fehlern auf Zonenebene und hilft auch bei der Reduzierung von Anwendungsausfallzeiten während geplanter und ungeplanter Ausfallzeiten. Die Daten vom primären Server werden synchron mit dem Standbyreplikat repliziert. Bei allen Downtimeereignissen erfolgt für den Datenbankserver automatisch ein Failover auf das Standbyreplikat. Weitere Informationen finden Sie unter Konzepte: Hochverfügbarkeit. Unterstützt in universellen und unternehmenskritischen Computeebenen. Nur verfügbar in Regionen, in denen mehrere Zonen verfügbar sind.
Premium-Dateifreigaben Die Datenbankdateien werden in sehr langlebigen und zuverlässigen Azure Premium-Dateifreigaben gespeichert, die Datenredundanz mit drei Replikatkopien bieten, die in einer Verfügbarkeitszone mit automatischer Datenwiederherstellung gespeichert sind. Weitere Informationen finden Sie unter Premium-Dateifreigaben. In einer Verfügbarkeitszone gespeicherte Daten

Minimierung von geplanter Downtime

Hier folgen einige geplante Wartungsszenarien, die zu Downtime führen:

Szenario Process
Computeskalierung (Benutzer) Wenn Sie einen Computeskalierungsvorgang durchführen, wird mithilfe der skalierten Computekonfiguration ein neuer flexibler Server bereitgestellt. Auf dem vorhandenen Datenbankserver können aktive Prüfpunkte abgeschlossen werden, Clientverbindungen werden entladen, alle Transaktionen ohne Commit werden abgebrochen, und anschließend wird der Server heruntergefahren. Der Speicher wird dann an den neuen Server angefügt, und die Datenbank wird gestartet, wodurch bei Bedarf eine Wiederherstellung ausgeführt wird, bevor Clientverbindungen akzeptiert werden.
Bereitstellung neuer Software (Azure) Die Einführung neuer Features oder Behebung von Fehlern erfolgt automatisch als Teil der geplanten Wartungsarbeiten des Diensts, und Sie können planen, wann diese Aktivitäten stattfinden sollen. Weitere Informationen finden Sie in der Dokumentation und im Portal.
Upgrades auf Nebenversionen (Azure) Azure Database for MySQL flexible server automatically patches database servers to the minor version determined by Azure. Dies erfolgt im Rahmen der geplanten Wartung des Diensts. Dabei kommt es zu einer kurzen Downtime von ein paar Sekunden. Danach wird der Datenbankserver automatisch mit der neuen Nebenversion neu gestartet. Weitere Informationen finden Sie in der Dokumentation und im Portal.

Wenn der flexible Server mit zonenredundanter Hochverfügbarkeit konfiguriert ist, führt der flexible Server Vorgänge zuerst auf dem Standbyserver und dann auf dem primären Server ohne Failover durch. Weitere Informationen finden Sie unter Konzepte: Hochverfügbarkeit.

Minimierung von ungeplanter Downtime

Ungeplante Downtimes können aufgrund von unvorhergesehenen Fehlern auftreten, darunter Fehler in der zugrunde liegenden Hardware, Netzwerkprobleme und Softwarefehler. Wenn der Datenbankserver unerwartet ausfällt, wird das Standbyreplikat aktiviert, sofern er mit Hochverfügbarkeit konfiguriert ist. Wenn dies nicht der Fall ist, wird automatisch ein neuer Datenbankserver bereitgestellt. Ungeplante Downtime lässt sich zwar nicht vollständig vermeiden, wird aber vom flexiblen Server durch automatisches Ausführen von Wiederherstellungsvorgängen sowohl auf Datenbankserver- als auch Speicherebene minimiert, ohne dass ein Eingreifen durch eine Person erforderlich ist.

Ungeplante Downtime: Fehlerszenarios und Dienstwiederherstellung

Im Folgenden finden Sie einige ungeplante Fehlerszenarien und den Wiederherstellungsprozess:

Szenario Wiederherstellungsprozess [ohne Hochverfügbarkeit] Wiederherstellungsprozess [mit Hochverfügbarkeit]
Ausfall des Datenbankservers Wenn der Datenbankserver aufgrund eines Fehlers an der zugrunde liegenden Hardware ausfällt, werden die aktiven Verbindungen getrennt, und alle Transaktionen, die gerade ausgeführt werden, werden abgebrochen. Azure versucht, den Datenbankserver neu zu starten. Wenn dies erfolgreich ist, wird die Wiederherstellung der Datenbank ausgeführt. Wenn der Neustart fehlschlägt, wird der Datenbankserverneustart auf einem anderen physischen Knoten versucht.

Die Wiederherstellungszeit (RTO) hängt von verschiedenen Faktoren ab, einschließlich der Aktivität zum Zeitpunkt des Fehlers, z. B. einer großen Transaktion und der Menge der Wiederherstellung, die während des Startvorgangs des Datenbankservers ausgeführt werden soll. Das RPO ist null, da für die zugesicherten Transaktionen kein Datenverlust erwartet wird. Anwendungen, die die MySQL-Datenbanken verwenden, müssen so konzipiert sein, dass sie getrennte Verbindungen und Transaktionsfehler erkennen und entsprechende Wiederholungsversuche durchführen. Wenn die Anwendung einen erneuten Versuch unternimmt, werden die Verbindungen zu dem neu erstellten Datenbankserver geleitet.

Andere verfügbare Optionen werden aus der Sicherung wiederhergestellt. Sie können sowohl PITR als auch Geowiederherstellung aus einer gekoppelten Region verwenden.
PITR : RTO: Variiert, RPO=0sec
Geowiederherstellung: RTO: Variiert, RPO <1 Stunde.

Sie können auch das Lesereplikat als Lösung für die Notfallwiederherstellung verwenden. Sie können die Replikation beenden, wodurch das Lesereplikat lese-/schreibgeschützt wird (eigenständig und dann den Anwendungsdatenverkehr an diese Datenbank umzuleiten). Die RTO ist in den meisten Fällen ein paar Minuten und RPO < 1 h. RTO und RPO können in einigen Fällen je nach verschiedenen Faktoren, einschließlich Latenz zwischen Standorten, übertragener Datenmenge und wichtig der primären Datenbankschreibworkload, viel höher sein.		 Wenn Datenbankserverfehler oder nicht wiederherstellbare Fehler erkannt werden, wird der Standbydatenbankserver aktiviert, wodurch Ausfallzeiten reduziert werden. Weitere Details finden Sie auf der Seite "HA-Konzepte". Die RTO wird voraussichtlich 60 bis 120 Sekunden betragen, wobei RPO=0 ist.

Hinweis:Die Optionen für den Wiederherstellungsprozess [Nicht-HA] gelten auch hier.
Speicherfehler Speicherbezogene Probleme wie der Ausfall eines Datenträgers oder physische Blockbeschädigungen haben keine Auswirkungen auf Anwendungen. Da drei Kopien der Daten gespeichert werden, wird eine Kopie der Daten vom verbleibenden Speicher bereitgestellt. Blockbeschädigungen werden automatisch behoben. Wenn eine Kopie der Daten verloren geht, wird automatisch eine neue erstellt.

In einem seltenen Fall oder im schlimmsten Fall, wenn alle Kopien beschädigt sind, kann die Wiederherstellung aus der Geowiederherstellung (gekoppelte Region) verwendet werden. Die RPO beträgt < 1 Stunde, die RTO würde variieren.

Sie können das Lesereplikat auch wie oben beschrieben als Lösung für die Notfallwiederherstellung verwenden.		 In diesem Szenario sind die Optionen mit den Optionen für den Wiederherstellungsprozess [keine Hochverfügbarkeit] identisch.
Logische Fehler/Benutzerfehler Die Wiederherstellung bei Benutzerfehlern, z. B. versehentlich gelöschten Tabellen oder falsch aktualisierten Daten, umfasst das Durchführen einer Zeitpunktwiederherstellung, bei der die Daten bis zu einem Zeitpunkt kurz vor dem Fehler wiederhergestellt werden.

Sie können eine gelöschte flexible Serverressource innerhalb von fünf Tagen ab dem Zeitpunkt der Löschung des Servers wiederherstellen. Eine ausführliche Anleitung zum Wiederherstellen eines gelöschten Servers finden Sie unter [Dokumentierte Schritte] (.. /flexible-server/how-to-restore-dropped-server.md). Um Serverressourcen nach der Bereitstellung vor versehentlichem Löschen oder unerwarteten Änderungen zu schützen, können Administratoren Verwaltungssperren verwenden.		 Diese Benutzerfehler sind nicht durch Hochverfügbarkeit geschützt, weil alle Benutzervorgänge auch auf den Standbyserver repliziert werden. In diesem Szenario sind die Optionen mit den Optionen für den Wiederherstellungsprozess [keine Hochverfügbarkeit] identisch.
Verfügbarkeitszonenfehler Es ist zwar ein seltenes Ereignis, aber wenn Sie nach einem Ausfall auf Zonenebene eine Wiederherstellung durchführen möchten, können Sie die Geowiederherstellung aus einer gekoppelten Region durchführen. Die RPO beträgt < 1 Stunde, die RTO würde variieren.

Sie können das Lesereplikat auch als Lösung für die Notfallwiederherstellung verwenden, indem Sie ein Replikat in einer anderen Verfügbarkeitszone erstellen. Die RTO\RPO ist wie oben beschrieben.		 Wenn Sie zonenredundante Hochverfügbarkeit aktiviert haben, führt der flexible Server ein automatisches Failover zum Standbystandort durch. Weitere Informationen finden unter Hochverfügbarkeitskonzepte. Die RTO wird voraussichtlich 60 bis 120 Sekunden betragen, wobei RPO=0 ist.

Andere verfügbare Optionen werden aus der Sicherung wiederhergestellt. Sie können sowohl PITR als auch Geowiederherstellung aus einer gekoppelten Region verwenden.
PITR : RTO: Variiert, RPO=0 Sek.
Geowiederherstellung : RTO: Variiert, RPO <1 h

Hinweis:Wenn Sie ha mit derselben Zone aktiviert haben, sind die Optionen identisch mit dem Wiederherstellungsprozess [nicht-HA].
Regionsausfall Es ist zwar ein seltenes Ereignis, aber wenn Sie Wiederherstellung nach einem Ausfall auf Regionsebene wünschen, können Sie eine Datenbankwiederherstellung durchführen, indem Sie einen neuen Server mit der letzten georedundanten Sicherung erstellen, die unter demselben Abonnement verfügbar ist, um die neuesten Daten abzurufen. In der ausgewählten Region wird ein neuer flexibler Server bereitgestellt. Die für die Wiederherstellung benötigte Zeit hängt von der vorherigen Sicherung und der Anzahl der wiederherzustellenden Transaktionsprotokolle ab. Die RPO beträgt in den meisten Fällen < 1 Stunde, und die RTO würde variieren. In diesem Szenario sind die Optionen mit den Optionen für den Wiederherstellungsprozess [keine Hochverfügbarkeit] identisch.

Anforderungen und Einschränkungen

Regionsdatenresidenz

Standardmäßig verschiebt oder speichert azure Database for MySQL flexible Server keine Kundendaten aus der Region, in der sie bereitgestellt wird. Kunden können jedoch optional auswählen, ob georedundante Sicherungen aktiviert oder eine regionsübergreifende Replikation zum Speichern von Daten in einer anderen Region eingerichtet werden soll.

Nächste Schritte