Vergleich der Optionen für Business Continuity & Disaster Recovery

  • 10 Minuten

Azure Database for MySQL – Flexible Server bietet Business Continuity-Features, um Ihre Datenbank bei geplanten oder ungeplanten Ausfallen zu schützen. Um verschiedene Arten von Ausfallen zu adressieren, können Sie unterschiedliche Fehlerschutzebenen mit unterschiedlichen Wiederherstellungszeiten oder unterschiedlichem Risiko für Datenverlust anwenden.

Downtimebeispiele

Ein paar Beispielszenarios für geplante und ungeplante Ausfallzeiten folgen.

Geplante Downtimeszenarios

Die beiden häufigsten geplanten Downtimeszenarios sind die vom Benutzer initiierte Computeskalierung und die von Azure durchgeführte geplante Wartung.

Wenn Sie einen Computeskalierungsvorgang ausführen, stellt Azure einen neuen flexiblen MySQL-Server mit der angeforderten Computekonfiguration bereit. Auf dem vorhandenen Server können aktive Prüfpunkte abgeschlossen werden, vorhandene Verbindungen geleert, nicht übermittelte Transaktionen abgebrochen und dann der vorhandene Server heruntergefahren werden. An diesem Punkt fügt Azure den Speicher des vorhandenen Servers an den neuen Server an und startet die Datenbank. Anschließend führt die Datenbank eine Wiederherstellung durch, die erforderlich ist, bevor Sie weitere Clientverbindungen akzeptieren.

Neue Features und Fehlerbehebungen erfolgen automatisch im Zuge der geplanten Wartung des Diensts. Nebenversionsupgrade-Patches werden auch während der geplanten Wartung angewendet, was ein paar Sekunden Downtime verursacht. Sie können diese Aktivitäten wie im folgenden Abschnitt „Geplante Downtime und Wartungsfenster“ beschrieben planen.

Ungeplante Ausfallzeiten

Die Datenbank kann aus mehreren Gründen unerwartet ausfallen, z. B.:

  • Datenbankhardwarefehler
  • Speicherlaufwerkfehler
  • Anwendungs- oder Benutzerfehler (z. B. versehentliches Löschen von Tabellen)
  • Verfügbarkeitszonen- und Regionsfehler

Wenn Hochverfügbarkeit (High Availability, HA) nicht aktiviert ist, versucht Azure eine Wiederherstellung z. B. durch das Kopieren verlorener Daten, den Neustart des Servers oder sogar das Starten des Servers auf einem anderen physischen Knoten. Die Aktivierung von HA kann diese Arten von Downtime reduzieren oder sogar beseitigen, wie im folgenden Abschnitt beschrieben.

Hochverfügbarkeit

Azure Database for MySQL – Flexible Server bietet HA mit automatischem Failover. Diese Lösung ist darauf ausgelegt, übertragene Daten niemals zu verlieren und zu verhindern, dass die Datenbank ein Single Point of Failure ist. Wenn Sie HA konfiguriert haben, stellt der flexible MySQL-Server automatisch ein Standbyreplikat bereit und verwaltet es.

Es gibt zwei Arten von Hochverfügbarkeit mit unterschiedlichen Fehlertoleranz- und Latenzkonflikten: zonenredundant und zonengleich.

Zonenredundante Hochverfügbarkeit

Zonenredundant HA bietet Redundanz über mehrere Verfügbarkeitszonen hinweg und ist die höchste Verfügbarkeitsebene, die auch dann wiederhergestellt werden kann, wenn eine gesamte Zone ausfällt. Durch die Verwendung einer zonenredundanten HA-Konfiguration entsteht zusätzliche Latenz. Sie sollten sich daher sicher sein, dass das für Ihre Anwendung akzeptabel ist. Darüber hinaus erfordert die Verwendung einer zonenredundanten HA-Konfiguration, dass Datenbankclientanwendungen zonenredundant sein müssen, um sicherzustellen, dass der allgemeine Betrieb fortgesetzt wird.

Hochverfügbarkeit in gleicher Zone

In zonengleichen HA-Konfiguration befinden sich die primären und Standbyserver in derselben Verfügbarkeitszone, wodurch die Latenz minimiert wird. Während in einigen Anwendungsfällen möglicherweise eine niedrige Latenz erforderlich ist, ist bei einer zonengleichen HA-Konfiguration die resultierende Downtime länger, wenn die Verfügbarkeitszone ausfällt und der flexible MySQL-Server wiederhergestellt wird.

Im Gegensatz zu zonenredundanter HA ist die zonengleiche HA in allen Regionen verfügbar, die Azure Database for MySQL – Flexible Server unterstützen.

Sichern und Wiederherstellen

Serversicherungen sind eine wichtige Komponente jeder Business Continuity-Strategie. Azure Database for MySQL – Flexible Server erstellt automatisch Sicherungen und speichert diese sicher in lokalen redundantem Speicher innerhalb der Region, die die Datenbank hostet. Sie können diese Sicherungen verwenden, um die Datenbank zu einem bestimmten Zeitpunkt wiederherzustellen, im Falle eines Fehlers oder einer Datenbeschädigung (z. B. Anwendungsfehler oder Entwicklungsfehler).

Es gibt zwei Arten von Sicherungen. Bei automatisierten Sicherungen übernimmt der flexible MySQL-Server Momentaufnahmen von Datenbankdatendateien sowie die zugehörigen Transaktionsprotokollen. Automatisierte Momentaufnahmensicherungen erfolgen einmal täglich, und Transaktionsprotokollsicherungen erfolgen alle fünf Minuten. Wenn eine Sicherung fehlschlägt, versucht der Server es alle 20 Minuten erneut, bis die Sicherung erfolgreich ist.

Mit On-demand-Sicherungen können Sie jederzeit eine Datenbanksicherung erstellen. Bei beiden Sicherungstypen werden Sicherungsdateien standardmäßig sieben Tage lang aufbewahrt. Basierend auf Ihren geschäftlichen Anforderungen können Sie jedoch den Wert des Aufbewahrungszeitraums zwischen einem und 35 Tagen konfigurieren.

Sie können Sicherungen bis zu zehn Jahre mit dem Feature „Langzeitaufbewahrung“ aufbewahren, das sich derzeit in der Public Preview befindet. Die langfristige Sicherungslösung kann separat oder zusätzlich zu automatisierten Azure Database for MySQL-Sicherungen verwendet werden. Langfristige Sicherungen können nach einem vom Kunden kontrollierten Zeitplan oder nach Bedarf erfolgen. Sicherungen werden in verwalteten Azure Backup-Speicherkonten in separaten Sicherheits- und Fehlerdomänen gespeichert.

Zusätzlich zum Sichern der Datenbank können Sie Sicherungsdateien in Azure Blob Storage exportieren und Sie dann für Migrationen, Datenwiederherstellung oder Archivierung verwenden. On-demand-Exporte befinden sich derzeit in der Public Preview und sind nur in Public Cloud-Regionen verfügbar.

Um die Sicherungsdateien zu speichern, können Sie aus mehreren Speicheroptionen wählen:

  • Mit lokal redundantem Speicher (dasselbe Rechenzentrum, dieselbe Zone) werden Sicherungsdateien im selben Rechenzentrum wie die Datenbank gespeichert. Diese Option bietet eine Dauerhaftigkeit von 99,999999999 % für Sicherungsobjekte im Laufe eines Jahres. Standardmäßig verwenden Server ohne HA oder mit zonengleicher HA lokal redundanten Speicher.

  • Mit zonenredundantem Sicherungsspeicher (unterschiedliche Zone, gleiche Region) werden Sicherungsdateien in der Verfügbarkeitszone des Servers gespeichert und in eine andere Verfügbarkeitszone in derselben Region repliziert. Diese Option bietet eine Dauerhaftigkeit von 99,9999999999 % für ein bestimmtes Jahr. Zonenredundanter Speicher ist wichtig für zonenredundante HA und erforderlich, wenn Daten innerhalb einer einzelnen Region verbleiben müssen.

  • Mit georedundantem Sicherungsspeicher (unterschiedliche Regionen) werden Sicherungsdateien in der Region des Servers gespeichert und dann in eine andere geogekoppelte Region repliziert. Diese Option bietet eine Dauerhaftigkeit von 99,99999999999999 % für ein bestimmtes Jahr. Georedundanter Speicher wird nur in gekoppelten Azure-Regionen unterstützt.

Hinweis: Mit Azure Database for MySQL – Flexible Server steht Sicherungsspeicherplatz von bis zu 100 % des bereitgestellten Speicherplatzes zur Verfügung. Zusätzlicher Speicher wird in GB pro Monat berechnet. Weitere Informationen finden Sie in der Preisdokumentation.

Nachdem Sie über eine Sicherung verfügen, können Sie die Sicherung auf einem neuen flexiblen MySQL-Server wiederherstellen. Es gibt drei Möglichkeiten für die Sicherung: manuell eine vollständige Sicherung auswählen, den neuesten Wiederherstellungspunkt automatisch auswählen oder den schnellsten Wiederherstellungspunkt automatisch auswählen. Wenn Sie über georedundante Sicherungen verfügen, können Sie auch die gekoppelte Region (übergreifende Region) wiederherstellen.

Geplante Downtime und Wartungsfenster

Regelmäßige Wartung ist erforderlich, um den verwalteten Server stabil, sicher und auf dem neuesten Stand zu halten. Während der Wartungsfenster empfängt der Dienst Bereitstellungen neuer Features, Updates und Patches. Normalerweise sind Wartungsfenster mindestens alle 30 Tage geplant, kritische Sicherheitspatches werden jedoch innerhalb von sieben Tagen oder weniger angewendet.

Sie können einen vom System verwalteten Zeitplan auswählen oder einen benutzerdefinierten Zeitplan für jeden flexiblen MySQL-Server in Ihrem Azure-Abonnement definieren.

Sie können Benachrichtigungen zu geplanter Wartung auf eine von mehreren Arten empfangen. Mögliche Benachrichtigungen:

  • E-Mail an eine bestimmte Adresse oder Azure Resource Manager-Rolle
  • Textnachricht (SMS)
  • Azure-Pushbenachrichtigung
  • Sprachnachricht

Benutzerdefinierte Wartungsfenster

Standardmäßig wählt das System bei einem vom System verwalteten Zeitplan ein einstündiges Fenster zwischen 23:00 und 7:00 Uhr in der Zeitzone der Region des flexiblen MySQL-Servers aus. Mit einem benutzerdefinierten Zeitplan können Sie Ihr Wartungsfenster für den Server angeben, indem Sie den Wochentag und ein einstündiges Zeitfenster auswählen.

Wartung mit Quasi-Null-Downtime für HA-Server (Public Preview)

HA-fähige Server profitieren von der Wartung mit Quasi-Null-Downtime, einem neuen Feature, das Wartungsausfallzeiten erheblich reduziert. Die erwartete Downtime liegt zwischen 40 und 60 Sekunden. Die Wartung mit Quasi-Null-Downtime ist für Anwendungen mit sehr hohen Verfügbarkeitsanforderungen von entscheidender Bedeutung, die minimale Unterbrechungen für die Datenbankkonnektivität voraussetzen.

Umplanen der Wartung (Public Preview)

Sie können die Wartung umplanen, wenn Sie die Dienstebenen „Universell“ oder „Unternehmenskritisch“ verwenden. Im Wartungsabschnitt des Azure-Portals können Sie die nächste geplante Wartung auf ein anderes Datum und eine andere Uhrzeit umplanen. Sie können die Wartung auch nach Bedarf initiieren, indem Sie Auf jetzt umplanen auswählen.