Übersicht über die Geschäftskontinuität mit Azure Database for MariaDB

  • Artikel

Wichtig

Azure Database for MariaDB wird demnächst eingestellt. Es wird dringend empfohlen, zu Azure Database for MySQL zu migrieren. Weitere Informationen zum Migrieren zur Azure-Datenbank für MySQL finden Sie unter Was geschieht mit Azure Database for MariaDB?.

Dieser Artikel beschreibt die Funktionen, die Azure Database for MariaDB für Geschäftskontinuität und Notfallwiederherstellung bereitstellt. Erfahren Sie etwas über Optionen für die Wiederherstellung nach Störungen, die Datenverluste nach sich ziehen oder dazu führen können, dass Ihre Datenbank und Ihre Anwendungen nicht mehr verfügbar sind. Erfahren Sie, was Sie tun müssen, wenn sich ein Benutzerfehler oder Anwendungsfehler auf die Datenintegrität auswirkt, eine Azure-Region einen Ausfall aufweist oder ihre Anwendung Standard Zusage benötigt.

Features für Geschäftskontinuität

Während Sie Ihren Geschäftskontinuitätsplan entwickeln, müssen Sie Folgendes verstehen:

  • Wiederherstellungszeitziel (RTO):Die maximale akzeptable Zeit, bevor die Anwendung nach einem störenden Ereignis vollständig wiederhergestellt wird.
  • Wiederherstellungspunktziel (RPO): Die maximale Menge der letzten Datenaktualisierungen (Zeitintervall), die die Anwendung beim Wiederherstellen nach einem störenden Ereignis tolerieren kann.

Azure-Datenbank für MariaDB bietet Funktionen für Geschäftskontinuität und Notfallwiederherstellung, die georedundante Sicherungen enthalten, mit der Möglichkeit, geowiederherstellung zu initiieren und Lesereplikate in einer anderen Region bereitzustellen. Jedes Feature weist unterschiedliche Eigenschaften für die Wiederherstellungszeit und mögliche Datenverluste auf.

Mit geowiederherstellung erstellt Azure Database for MariaDB einen neuen Server mithilfe der Sicherungsdaten, die aus einer anderen Region repliziert werden. Die Gesamtzeit für die Wiederherstellung und Wiederherstellung hängt von der Größe der Datenbank und der Menge der wiederherzustellenden Protokolldaten ab. Die Gesamtzeit zum Einrichten des Servers variiert von wenigen Minuten bis zu einigen Stunden.

Bei Lesereplikaten werden Transaktionsprotokolle aus der primären Datenbank asynchron an ein Replikat gestreamt. Wenn ein primärer Datenbankausfall aufgrund eines Fehlers auf Zonenebene oder einem Fehler auf Regionsebene vorliegt, bietet ein Ausfall des Replikats einen kürzeren RTO und einen reduzierten Datenverlust.

Hinweis

Die Verzögerung zwischen der primären Datenbank und dem Replikat hängt von der Latenz zwischen den Standorten, der zu übertragenden Datenmenge und (am wichtigsten) der Schreibworkload des primären Servers ab. Schwere Schreibarbeitslasten können einen erheblichen Verzögerungsabstand erzeugen.

Aufgrund der asynchronen Art der Replikation, die für Lesereplikate verwendet wird, sollten Sie nicht in Betracht ziehen, Replikate als Hochverfügbarkeitslösung zu lesen. Die höheren Verzögerungen können höhere RTO und RPO bedeuten. Lesereplikate können nur für Arbeitslasten, bei denen sich die verzögerungsbedingten Standard durch die Spitzen- und Off-Peak-Zeiten verkleinern, als Hochverfügbarkeitsalter fungieren. Andernfalls sind Lesereplikate für leseintensive Arbeitslasten und für Notfallwiederherstellungsszenarien vorgesehen.

In der folgenden Tabelle werden RTO und RPO in einem Szenario mit einer typischen Workload verglichen:

Funktion Grundlegend Allgemeiner Zweck Arbeitsspeicheroptimiert
Point-in-Time-Wiederherstellung aus der Sicherung Beliebiger Wiederherstellungspunkt innerhalb der Aufbewahrungsdauer
RTO variiert
RPO ist weniger als 15 Minuten		 Beliebiger Wiederherstellungspunkt innerhalb der Aufbewahrungsdauer
RTO variiert
RPO ist weniger als 15 Minuten		 Beliebiger Wiederherstellungspunkt innerhalb der Aufbewahrungsdauer
RTO variiert
RPO ist weniger als 15 Minuten
Geowiederherstellung von georeplizierten Sicherungen Nicht unterstützt RTO variiert
RPO ist größer als 24 Stunden		 RTO variiert
RPO ist größer als 24 Stunden
Lesereplikate RTO ist Minuten
RPO ist weniger als 5 Minuten		 RTO ist Minuten
RPO ist weniger als 5 Minuten		 RTO ist Minuten
RPO ist weniger als 5 Minuten

RTO und RPO können in einigen Fällen viel höher sein, abhängig von Faktoren wie Latenz zwischen Standorten, der zu übertragenden Datenmenge und der Schreibauslastung der primären Datenbank.

Wiederherstellung eines Servers nach einem Benutzer- oder Anwendungsfehler

Sie können die Sicherungen des Diensts verwenden, um einen Server nach verschiedenen Störungen wiederherzustellen. Beispielsweise kann ein Benutzer versehentlich einige Daten löschen, versehentlich eine wichtige Tabelle ablegen oder sogar eine ganze Datenbank ablegen. Eine Anwendung kann aufgrund eines Anwendungsfehlers versehentlich gute Daten mit schlechten Daten überschreiben.

Sie können eine Point-in-Time-Wiederherstellung durchführen, um eine Kopie Ihres Servers zu einem als fehlerfrei bekannten Zeitpunkt zu erstellen. Dieser Zeitpunkt muss sich innerhalb des Sicherungsaufbewahrungszeitraums befinden, den Sie für Ihren Server konfiguriert haben. Nachdem die Daten auf dem neuen Server wiederhergestellt wurden, können Sie entweder den ursprünglichen Server durch den neu wiederhergestellten Server ersetzen oder die erforderlichen Daten vom wiederhergestellten Server auf den ursprünglichen Server kopieren.

Wichtig

Sie können gelöschte Server nur innerhalb von fünf Tagen nach dem Löschen wiederherstellen. Nach fünf Tagen werden die Sicherungen gelöscht. Sie können nur über das Azure-Abonnement, auf das der Server gehostet wird, auf die Datenbanksicherung zugreifen und sie wiederherstellen. Informationen zum Wiederherstellen eines verworfenen Servers finden Sie in den dokumentierten Schritten. Wenn Serverressourcen nach der Bereitstellung vor versehentlichem Löschen oder unerwarteten Änderungen geschützt werden sollen, können Administratoren Verwaltungssperren nutzen.

Wiederherstellung von einem Ausfall eines regionalen Azure-Rechenzentrums

Obwohl es selten ist, kann ein Azure-Rechenzentrum einen Ausfall aufweisen. Wenn ein Ausfall auftritt, verursacht es eine Geschäftsunterbrechung, die nur ein paar Minuten dauern kann, aber stundenlang dauern könnte.

Eine Option besteht darin, darauf zu warten, dass Ihr Server wieder online ist, wenn der Ausfall des Rechenzentrums abgelaufen ist. Wenn das Rechenzentrum über einen Ausfall verfügt, wissen Sie nicht, wie lange der Ausfall dauern kann. Diese Option funktioniert also nur für Anwendungen, die es sich leisten können, den Server für einige Zeit offline zu haben (z. B. eine Entwicklungsumgebung).

Geowiederherstellung

Das Feature "Geowiederherstellung" stellt den Server mithilfe georedundanter Sicherungen wieder her. Die Sicherungen werden in der gekoppelten Region Ihres Servers gehostet. Auf diese Sicherungen kann auch dann zugegriffen werden, wenn die Region, in der Ihr Server gehostet wird, offline ist. Sie können diese Sicherungen in jeder anderen Region wiederherstellen und dann Ihren Server wieder online schalten. Weitere Informationen zur Geowiederherstellung finden Sie im Artikel zu Sicherungs- und Wiederherstellungskonzepten.

Wichtig

Geowiederherstellung ist nur möglich, wenn Sie den Server mit georedundanten Sicherungsspeicher bereitgestellt haben. Wenn Sie von lokal redundant zu georedundanten Sicherungen für einen vorhandenen Server wechseln möchten, müssen Sie mithilfe von mysqldump eine Sicherung Ihres vorhandenen Servers generieren. Stellen Sie dann einen neu erstellten Server wieder her, der mit georedundanten Sicherungen konfiguriert ist.

Regionsübergreifende Lesereplikate

Sie können regionsübergreifende Lesereplikate verwenden, um Ihre Planung für Geschäftskontinuität und Notfallwiederherstellung zu verbessern. Lesereplikate werden asynchron über die Replikationstechnologie von MySQL für binäre Protokolle aktualisiert. Weitere Informationen zum Lesen von Replikaten, verfügbaren Regionen und zum Fehlschlagen im Artikel zu den Replikatkonzepten.

Häufig gestellte Fragen

Wo speichert Azure Database for MariaDB Kundendaten?

Standardmäßig werden Kundendaten in der Azure-Datenbank für MariaDB nicht aus der Region verschoben oder gespeichert, in der sie bereitgestellt wird. Optional können Sie jedoch auswählen, ob georedundante Sicherungen aktiviert oder regionsübergreifende Lesereplikate zum Speichern von Daten in einer anderen Region erstellt werden sollen.

Nächste Schritte