Freigeben über

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

  • Artikel

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

Azure Database for MySQL Flexible Server ermöglicht Funktionen für die Geschäftskontinuität, 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 for MySQL – Flexibler 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 Ihren Datenbankserver auf jeden beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums Ihrer Sicherung wiederherstellen. Die Wiederherstellungszeit hängt von der Größe der wiederherzustellenden Daten und der Zeit für die Durchführung der Protokollwiederherstellung ab. 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. Zonenredundante Hochverfügbarkeit schützt vor Fehlern auf Zonenebene und hilft auch bei der Reduzierung der Downtime von Anwendungen während geplanten und ungeplanten Downtimeereignissen. 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, die bei Bedarf eine Wiederherstellung durchführt, bevor sie Clientverbindungen akzeptiert.
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 – Flexibler Server patcht Datenbankserver automatisch auf die von Azure festgelegte Nebenversion. 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 Neustart des Datenbankservers auf einem anderen physischen Knoten versucht.

Die Wiederherstellungszeit (Recovery Time Objective, RTO) hängt von verschiedenen Faktoren ab, z. B. der Aktivität zum Zeitpunkt des Fehlers. Zu diesen Aktivitäten zählen große Transaktionen und die Anzahl der Wiederherstellungsvorgänge, die während des Starts des Datenbankservers ausgeführt werden müssen. Der RPO-Wert ist Null, da für die committete 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 in den Status Lesen-Schreiben versetzt wird (eigenständig, und dann können Sie den Anwendungsdatenverkehr an diese Datenbank umleiten). Die RTO beträgt in den meisten Fällen einige Minuten und die RPO < 1 Stunde. RTO und RPO können in einigen Fällen in Abhängigkeit von verschiedenen Faktoren wie der Latenz zwischen den Standorten, der Menge der zu übertragenden Daten und vor allem der Schreibworkload in der primären Datenbank deutlich höher sein.		 Wenn ein Datenbankserverfehler oder nicht wiederherstellbare Fehler erkannt werden, wird der Standby-Datenbankserver aktiviert, wodurch die Downtime verringert wird. Weitere Informationen finden Sie auf der Seite für Hochverfügbarkeitskonzepte. Die RTO wird voraussichtlich 60 bis 120 Sekunden betragen, wobei RPO=0 ist.

Hinweis: Die Optionen für den Wiederherstellungsprozess [keine Hochverfügbarkeit] 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). Zum Schutz von Serverressourcen vor versehentlicher Löschung oder unerwarteten Änderungen nach der Bereitstellung können Administrator*innen 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 Stunde

Hinweis: Wenn Sie Hochverfügbarkeit in der gleichen Zonen aktiviert haben, sind die Optionen die gleichen wie für den Wiederherstellungsprozess [keine Hochverfügbarkeit].
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 speichert oder verschiebt Azure Database for MySQL – Flexibler Server Kundendaten nicht außerhalb der Region, in der die Instanz bereitgestellt wurde. Kunden können jedoch optional georedundante Sicherungen aktivieren oder eine regionsübergreifende Replikation zum Speichern von Daten in einer anderen Region einrichten.

Nächste Schritte