Teilen über

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

  • Artikel

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?.

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 zu tun ist, wenn ein Benutzerfehler oder ein Anwendungsfehler die Datenintegrität beeinträchtigt, eine Azure-Region einen Ausfall erfährt oder Ihre Anwendung gewartet werden muss.

Features für Geschäftskontinuität

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

  • Recovery Time Objective (RTO): Die maximale akzeptable Zeit, bis die Anwendung nach einem störenden Ereignis vollständig wiederhergestellt ist.
  • Recovery Point Objective (RPO): Die maximale Menge der letzten Datenaktualisierungen (Zeitintervall), deren Verlust die Anwendung beim Wiederherstellen nach einem störenden Ereignis tolerieren kann.

Azure Database for MariaDB bietet Features für Business Continuity & Disaster Recovery (Geschäftskontinuität und Notfallwiederherstellung), die georedundante Sicherungen mit der Möglichkeit zum Initiieren der Geowiederherstellung und zum Bereitstellen von Lesereplikaten in einer anderen Region umfassen. 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 hängt von der Größe der Datenbank und der Anzahl der wiederherzustellenden Protokolldaten ab. Die Gesamtzeit zum Einrichten des Servers variiert von wenigen Minuten bis zu einigen Stunden.

Mit Lesereplikaten werden Transaktionsprotokolle vor primären Datenbank asynchron an das Replikat gestreamt. Bei einem Ausfall einer primären Datenbank aufgrund eines Fehlers auf Zonen- oder Regionsebene bietet ein Failover auf das Replikat eine kürzere RTO und reduziert Datenverluste.

Hinweis

Die Verzögerung zwischen der primären Datenbank und dem Replikat hängt von der Latenz zwischen den Standorten, der Menge der zu übertragenden Daten und (vor allem) vom Schreibworkload des primären Servers ab. Schreibintensive Workloads können eine erhebliche Verzögerung verursachen.

Aufgrund der asynchronen Art der Replikation, die für Lesereplikate verwendet wird, sollten Sie Lesereplikate nicht als Hochverfügbarkeitslösung betrachten. Die höheren Verzögerungen können höhere RTO und RPO bedeuten. Lesereplikate können nur für Workloads als Hochverfügbarkeitsalternative dienen, bei denen die Verzögerung während der Spitzen- und Nebenzeiten geringer bleibt. Ansonsten sind Lesereplikate für echte Leseskalierung bei leseintensiven Workloads und für Notfallwiederherstellungsszenarien vorgesehen.

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

Funktion Basic Allgemeiner Zweck Arbeitsspeicheroptimiert
Zeitpunktwiederherstellung aus einer 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 wenige Minuten
RPO ist weniger als 5 Minuten		 RTO ist wenige Minuten
RPO ist weniger als 5 Minuten		 RTO ist wenige Minuten
RPO ist weniger als 5 Minuten

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.

Wiederherstellen eines Servers nach einem Benutzer- oder Anwendungsfehler

Sie können die Sicherungen des Diensts verwenden, um einen Server nach verschiedenen Störungen wiederherzustellen. Beispiel: Ein Benutzer könnte versehentlich einige Daten löschen oder eine wichtige Tabelle oder sogar eine ganze Datenbank löschen. Eine Anwendung könne aufgrund eines Anwendungsfehlers versehentlich gültige Daten mit ungültigen Daten überschreibt.

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 innerhalb des Aufbewahrungszeitraums der Sicherungen liegen, die Sie für Ihren Server konfiguriert haben. Nach der Wiederherstellung der Daten auf dem neuen Server können Sie entweder den ursprünglichen Server durch den wiederhergestellten Server ersetzen oder die benötigten 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, das den Server hostet, auf die Datenbanksicherung zugreifen und sie wiederherstellen. Informationen zum Wiederherstellen eines gelöschten 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 nach einem Ausfall eines regionalen Azure-Rechenzentrums

Auch wenn es selten vorkommt, kann es in einem Azure-Rechenzentrum zu Ausfällen kommen. Ein Ausfall kann einen Geschäftsunterbruch von einigen wenigen Minuten verursachen, er kann aber auch mehrere Stunden dauern.

Eine Option ist, darauf zu warten, bis Ihr Server wieder online ist, wenn der Rechenzentrumsausfall behoben wurde. Wenn das Rechenzentrum einen Ausfall erfährt, wissen Sie nicht, wie lange der Ausfall dauern könnte. Diese Option funktioniert also nur bei Anwendungen, die es sich leisten können, den Server für einige Zeit offline zu haben (z. B. eine Entwicklungsumgebung).

Geowiederherstellung

Das Feature für Geowiederherstellung stellt den Server mithilfe von georedundanten Sicherungen wieder her. Die Sicherungen werden in der gekoppelten Region Ihres Servers gehostet. Auf diese Sicherungen kann selbst dann zugegriffen werden, wenn die Region, in der Ihr Server gehostet wird, offline ist. Sie können eine Wiederherstellung aus diesen Sicherungen in eine beliebige andere Region ausführen und dann Ihren Server wieder online bringen. Weitere Informationen zur Geowiederherstellung finden Sie im Artikel zu Sicherungs- und Wiederherstellungskonzepten.

Wichtig

Die Geowiederherstellung ist nur dann möglich, wenn Sie den Server mit einem georedundanten Sicherungsspeicher bereitgestellt haben. Wenn Sie von lokal redundanten 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 Business Continuity & Disaster Recovery zu verbessern. Lesereplikate werden asynchron über die Replikationstechnologie von MySQL für binäre Protokolle aktualisiert. Weitere Informationen zu Lesereplikaten, zu verfügbaren Regionen und zum Failover finden Sie im Artikel über Lesereplikatkonzepte.

Häufig gestellte Fragen

Wo speichert Azure Database for MariaDB Kundendaten?

Standardmäßig verschiebt oder speichert Azure Database for MariaDB keine Kundendaten aus der Region, in der sie bereitgestellt werden. Sie können jedoch optional georedundante Sicherungen aktivieren oder regionsübergreifende Lesereplikate zum Speichern von Daten in einer anderen Region erstellen.

Nächste Schritte