Freigeben über

Sicherung und Wiederherstellung in Azure Database for MySQL – Flexible Server

  • Artikel

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

Azure Database for MySQL – Flexibler Server erstellt automatisch Serversicherungen und speichert diese sicher in lokalen redundanten Speichern in der Region. Sicherungen können verwendet werden, um für Ihren Server den Stand zu einem bestimmten Zeitpunkt wiederherzustellen. Sicherungen und Wiederherstellungen sind wesentliche Bestandteile jeder Strategie für Geschäftskontinuität, da Ihre Daten so vor versehentlichen Beschädigungen und Löschungen geschützt werden.

Übersicht über Azure Backup

Azure Database for MySQL – Flexibler Server unterstützt zwei Typen von Sicherungen, um mehr Flexibilität in Bezug auf die Aufbewahrung von Sicherungen unternehmenskritischer Daten zu ermöglichen.

Automatisierte Sicherung

Azure Database for MySQL – Flexibler Server erstellt Momentaufnahmesicherungen der Datendateien und speichert sie in einem lokalen redundanten Speicher. Der Server führt auch eine Sicherung der Transaktionsprotokolle durch und speichert diese ebenfalls in einem lokalen redundanten Speicher. Dank dieser Sicherungen können Sie für einen Server den Stand zu einem beliebigen Zeitpunkt wiederherstellen, der innerhalb Ihres konfigurierten Aufbewahrungszeitraums für Sicherungen liegt. Die Standardaufbewahrungsdauer für Sicherungen beträgt sieben Tage. Sie können die Sicherung der Datenbank optional von 1 bis 35 Tagen konfigurieren. Alle Sicherungen werden mithilfe der AES 256-Bit-Verschlüsselung für die ruhenden Daten verschlüsselt.

Bedarfsgesteuerte Sicherung

Mit Azure Database for MySQL – Flexibler Server können Sie zusätzlich zu den vom Dienst automatisch ausgeführten Sicherungen On-Demand-Sicherungen der Produktionsworkload auslösen und entsprechend der Backup-Aufbewahrungsrichtlinie des Servers speichern. Sie können diese Sicherungen als schnellsten Wiederherstellungspunkt verwenden, um eine Zeitpunktwiederherstellung auszuführen und Wiederherstellungszeiten um bis zu 90 % zu reduzieren. Die Standardaufbewahrungsdauer für Sicherungen beträgt sieben Tage. Sie können die Sicherung der Datenbank optional von 1 bis 35 Tagen konfigurieren. Sie können insgesamt 50 bedarfsgesteuerte Sicherungen über das Portal auslösen. Alle Sicherungen werden mithilfe der AES 256-Bit-Verschlüsselung für die ruhenden Daten verschlüsselt.

Diese Sicherungsdateien können nicht exportiert werden. Die Sicherungen können nur für Wiederherstellungsvorgänge in Azure Database for MySQL – Flexibler Server verwendet werden. Sie können auch mysqldump von einem MySQL-Client aus verwenden, um eine Datenbank zu kopieren.

Sicherungshäufigkeit

Sicherungen für flexible Server basieren auf Momentaufnahmen. Die erste Momentaufnahmensicherung ist für unmittelbar nach Erstellung des Servers geplant. Momentaufnahmesicherungen werden einmal täglich erstellt. Transaktionsprotokollsicherungen finden alle fünf Minuten statt. Wenn bei einer geplanten Sicherung ein Fehler auftritt, versucht unser Sicherungsdienst alle 20 Minuten, eine Sicherung zu erstellen, bis eine erfolgreiche Sicherung erstellt wurde. Diese Sicherungsfehler sind auf hohe Transaktionsproduktionslasten auf der Serverinstanz zurückzuführen.

Hinweis

  • Wenn der Server eine hohe Transaktionslast aufweist und dadurch die binlog-Dateien immer schneller immer größer werden, führt der Sicherungsdienst mehrere Sicherungen pro Tag durch, um eine zuverlässige und schnellere Wiederherstellung mithilfe dieser Sicherungen zu gewährleisten.
  • Bei Servern mit Version 5.7 können große Transaktionen oder solche mit langer Ausführungszeit verhindern, dass globale Sperren auf Instanzenebene erworben werden, die für eine erfolgreiche tägliche Sicherung erforderlich sind. In solchen Szenarien können die täglichen Sicherungen zu Fehlern führen. Um dies zu beheben, beenden Sie entweder die lange ausgeführte Transaktion, ODER starten Sie den Server neu. Um einen reibungsloseren Betrieb sicherzustellen, empfiehlt es sich, Ihre MySQL 5.7-Server mithilfe eines Hauptversionsupgrades auf Version 8.0 zu aktualisieren.

Optionen für Sicherungsredundanz

Azure Database for MySQL – Flexibler Server speichert immer mehrere Kopien der Sicherungen, damit die Daten vor geplanten und ungeplanten Ereignissen geschützt sind – von vorübergehend auftretenden Hardwarefehlern über Netzwerk- oder Stromausfälle bis hin zu schweren Naturkatastrophen. Bei Azure Database for MySQL – Flexibler Server können Sie in den Dienstebenen „Basic“, „Universell“ und „Unternehmenskritisch“ flexibel zwischen lokal redundantem, zonenredundantem und georedundantem Sicherungsspeicher wählen. Standardmäßig ist der Sicherungsspeicher von Azure Database for MySQL – Flexibler Server für Server mit Hochverfügbarkeit in gleicher Zone oder ohne Hochverfügbarkeitskonfiguration lokal redundant und für Server mit zonenredundanter Hochverfügbarkeitskonfiguration zonenredundant.

Die Sicherungsredundanz stellt sicher, dass die Datenbank ihre Verfügbarkeits- und Dauerhaftigkeitsziele auch bei Ausfällen erfüllt, und Azure Database for MySQL – Flexibler Server bietet drei Optionen für Benutzer*innen:

  • Lokal redundanter Sicherungsspeicher: Wenn die Sicherungen in einem lokal redundanten Sicherungsspeicher gespeichert werden, werden mehrere Kopien von Sicherungen im selben Rechenzentrum gespeichert. Diese Option schützt Ihre Daten vor Serverrack- und Laufwerkfehlern. Darüber hinaus bietet dies eine Dauerhaftigkeit von mindestens 99,999999999 % (11 9en) von Sicherungsobjekten für die Dauer eines Jahres. Standardmäßig ist Sicherungsspeicher für Server mit Hochverfügbarkeit in gleicher Zone oder ohne Hochverfügbarkeitskonfiguration auf lokal redundant festgelegt.

  • Zonenredundanter Sicherungsspeicher: Wenn die Sicherungen in zonenredundantem Sicherungsspeicher gespeichert werden, werden nicht nur in der Verfügbarkeitszone, in der Ihr Server gehostet wird, mehrere Kopien gespeichert, sondern auch in eine andere Verfügbarkeitszone in derselben Region repliziert. Diese Option kann für Szenarien genutzt werden, die Hochverfügbarkeit erfordern, oder um die Replikation von Daten in einem Land bzw. einer Region einzuschränken, um Anforderungen an Datenresidenz zu erfüllen. Darüber hinaus bietet dies eine Dauerhaftigkeit von mindestens 99,9999999999 % (12 9en) von Sicherungsobjekten für die Dauer eines Jahres. Sie können die Option „Zonenredundante Hochverfügbarkeit“ zum Zeitpunkt der Servererstellung auswählen, um zonenredundanten Sicherungsspeicher sicherzustellen. Hochverfügbarkeit kann für einen Server nach der Erstellung deaktiviert werden, der Sicherungsspeicher bleibt jedoch zonenredundant.

  • Georedundanter Sicherungsspeicher: Beim Speichern der Sicherungen in einem georedundanten Sicherungsspeicher werden nicht nur mehrere Kopien innerhalb der Region gespeichert, in der Ihr Server gehostet wird, sondern auch in die geografisch gekoppelte Region repliziert. Dies erhöht den Schutz und ermöglicht in einem Notfall die Wiederherstellung Ihres Servers in einer anderen Region. Darüber hinaus bietet dies eine Dauerhaftigkeit von mindestens 99,99999999999999 % (16 Neunen) von Sicherungsobjekten für die Dauer eines Jahres. Sie können die Option „Georedundanz“ zum Zeitpunkt der Servererstellung aktivieren, um georedundanten Sicherungsspeicher sicherzustellen. Darüber hinaus können Sie nach der Servererstellung vom lokal redundanten Speicher zum georedundanten Speicher wechseln. Georedundanz wird für Server unterstützt, die in einer der gekoppelten Azure-Regionen gehostet werden.

Hinweis

Zonenredundante Hochverfügbarkeit zur Unterstützung von Zonenredundanz wird derzeit nur als Vorgang zur Erstellungszeit zur Verfügung gestellt. Derzeit kann Georedundanz für die zonenredundante Hochverfügbarkeit von Servern nur zum Zeitpunkt der Servererstellung aktiviert/deaktiviert werden.

Umstieg von anderen Sicherungsspeicheroptionen auf georedundanten Sicherungsspeicher

Sie können Ihren vorhandenen Sicherungsspeicher mithilfe der folgenden vorgeschlagenen Methoden in georedundanten Speicher verschieben:

  • Wechsel von lokal redundantem zu georedundantem Sicherungsspeicher: Um Ihren Sicherungsspeicher von lokal redundantem Speicher auf georedundanten Speicher umzustellen, können Sie die Serverkonfiguration „Compute + Speicher“ im Azure-Portal ändern, um Georedundanz für den lokal redundanten Quellserver zu aktivieren. Zonenredundante Hochverfügbarkeitsserver derselben Zone können auch auf ähnliche Weise wie ein georedundanter Server wiederhergestellt werden, da der zugrunde liegende Sicherungsspeicher lokal redundant ist.

  • Wechsel von zonenredundantem zu georedundantem Sicherungsspeicher: Azure Database for MySQL – Flexibler Server unterstützt keine Konvertierung von zonenredundantem Speicher in georedundanten Speicher durch Änderung von Einstellungen von „Compute und Speicher“, nachdem der Server bereitgestellt wurde. Um Ihren Sicherungsspeicher von zonenredundantem Speicher in georedundanten Speicher zu ändern, gibt es zwei Optionen: a) Verwenden Sie PITR (Point-in-Time-Restore, Zeitpunktwiederherstellung), um den Server mit der gewünschten Konfiguration wiederherzustellen. b) Erstellen Sie einen neuen Server mit der gewünschten Konfiguration, und migrieren Sie die Daten mithilfe von Sichern und Wiederherstellen.

Sicherungsaufbewahrung

Sicherungen werden basierend auf der Einstellung für den Aufbewahrungszeitraum der Sicherung auf dem Server beibehalten. Sie können einen Aufbewahrungszeitraum von 1 bis 35 Tagen auswählen, wobei die standardmäßige Beibehaltungsdauer sieben Tage beträgt. Sie können den Aufbewahrungszeitraum bei der Servererstellung oder später festlegen, indem Sie die Sicherungskonfiguration mithilfe des Azure-Portals aktualisieren.

Der Aufbewahrungszeitraum für Sicherungen legt fest, wie weit zurück in der Zeit ein Zeitpunktwiederherstellungsvorgang durchgeführt werden kann, da er auf verfügbaren Sicherungen basiert. Der Aufbewahrungszeitraum kann auch als Wiederherstellungsfenster im Hinblick auf die Wiederherstellung behandelt werden. Alle Sicherungen, die zum Durchführen einer Zeitpunktwiederherstellung innerhalb des Aufbewahrungszeitraums für die Sicherung erforderlich sind, werden im Sicherungsspeicher beibehalten. Wenn der Aufbewahrungszeitraum für Sicherungen z. B. auf sieben Tage festgelegt ist, entspricht das Wiederherstellungsfenster einer Dauer von sieben Tagen. In diesem Szenario bleiben alle Sicherungen erhalten, die zum Wiederherstellen des Servers in den letzten sieben Tagen erforderlich sind. Bei einem Fenster für die Aufbewahrung von Sicherungen von sieben Tagen werden Datenbankmomentaufnahmen und Transaktionsprotokollsicherungen für die letzten acht Tage (ein Tag vor dem Fenster) gespeichert.

Kosten für Sicherungsspeicher

Azure Database for MySQL – Flexibler Server bietet bis zu 100 % des bereitgestellten Serverspeichers ohne zusätzliche Kosten als Sicherungsspeicher an. Wenn zusätzlicher Sicherungsspeicher verwendet wird, wird dies in GB pro Monat berechnet. Beispiel: Wenn Sie einen Server mit 250 GB bereitgestellt haben, verfügen Sie über 250 GB an Speicher, der ohne zusätzliche Kosten für Serversicherungen zur Verfügung steht. Wenn die tägliche Sicherheitsauslastung 25 GB beträgt, können Sie für bis zu 10 Tage über kostenlosen Sicherungsspeicher verfügen. Der für Sicherungen verwendete Speicher über 250 GB wird gemäß dem Preismodell abgerechnet.

Sie können die im Azure-Portal in Azure Monitor verfügbare Metrik für den verwendeten Sicherungsspeicher zum Überwachen des von einem Server genutzten Sicherungsspeichers verwenden. Die Metrik für den belegten Sicherungsspeicher stellt den gesamten Speicherplatz dar, der von allen Datenbank- und Protokollsicherungen beansprucht wurde, die auf Grundlage des für den Server festgelegten Aufbewahrungszeitraums für Sicherungen aufbewahrt wurden. Eine hohe Transaktionsaktivität auf dem Server kann dazu führen, dass die Sicherungsspeicherauslastung unabhängig von der Gesamtgröße der Datenbank zunimmt. Der für einen georedundanten Server verwendete Sicherungsspeicher ist doppelt so groß wie für einen lokal redundanten Server.

Das primäre Mittel zur Kostenkontrolle bei der Speicherung von Sicherungen ist die Festlegung eines angemessenen Aufbewahrungszeitraums für Sicherungen. Sie können einen Aufbewahrungszeitraum zwischen 1 und 35 Tagen auswählen.

Wichtig

Sicherungen von einem Datenbankserver, der in einer zonenredundanten Hochverfügbarkeitskonfiguration konfiguriert ist, erfolgen vom primären Datenbankserver, da der Mehraufwand bei Momentaufnahmensicherungen minimal ist.

Anzeigen verfügbarer vollständiger Sicherungen

Das Blatt „Sicherung und Wiederherstellung“ im Azure-Portal bietet eine vollständige Liste der vollständigen Sicherungen, die Ihnen zu einem bestimmten Zeitpunkt zur Verfügung stehen. Dazu gehören automatisierte Sicherungen sowie die bedarfsgesteuerten Sicherungen. Auf diesem Blatt können Sie die Abschlusszeitstempel für alle verfügbaren vollständigen Sicherungen innerhalb des Aufbewahrungszeitraums des Servers anzeigen und Wiederherstellungsvorgänge mit diesen vollständigen Sicherungen ausführen. Die Liste der verfügbaren Sicherungen umfasst alle vollständigen Sicherungen innerhalb des Aufbewahrungszeitraums, einen Zeitstempel mit dem erfolgreichen Abschluss, einen Zeitstempel, der angibt, wie lange eine Sicherung aufbewahrt wird, und eine Wiederherstellungsaktion.

Restore

Wenn in Azure Database for MySQL – Flexibler Server eine Wiederherstellung durchgeführt wird, wird aus den Sicherungen des ursprünglichen Servers ein neuer Server erstellt. Es gibt zwei Arten der Wiederherstellung:

  • Zeitpunktwiederherstellung: Ist für beide Sicherungsredundanzoptionen verfügbar. Es wird ein neuer Server in derselben Region wie der ursprüngliche Server erstellt.
  • Geowiederherstellung: nur verfügbar, wenn Sie Ihren Server für georedundanten Speicher konfiguriert haben. Sie können den Server dann in einer geografisch gekoppelten Region oder in einer anderen von Azure unterstützten Region wiederherstellen, in der ein flexibler Server verfügbar ist.

Die geschätzte Zeit für die Wiederherstellung des Servers ist von mehreren Faktoren abhängig:

  • Größe der Datenbanken
  • Anzahl der beteiligten Transaktionsprotokolle
  • Menge der erneut auszuführenden Aktivitäten, um den Wiederherstellungspunkt wiederherzustellen
  • Netzwerkbandbreite, sofern die Wiederherstellung in einer anderen Region erfolgt
  • Anzahl der gleichzeitigen Wiederherstellungsanforderungen, die aktuell in der Zielregion verarbeitet werden
  • Vorhandensein eines Primärschlüssels in den Tabellen in der Datenbank. Um die Wiederherstellung zu beschleunigen, sollten Sie für alle Tabellen in der Datenbank einen Primärschlüssel hinzufügen.

Hinweis

Ein für Hochverfügbarkeit aktivierter Server wird nach der Wiederherstellung sowohl bei der Zeitpunktwiederherstellung als auch bei der Geowiederherstellung zu einem Server ohne Hochverfügbarkeit (Hochverfügbarkeit deaktiviert).

Point-in-Time-Wiederherstellung

In Azure Database for MySQL – Flexibler Server wird bei der Zeitpunktwiederherstellung ein neuer Server aus den Sicherungen des flexiblen Servers in derselben Region wie der Quellserver erstellt. Bei der Erstellung werden die Konfiguration für die Computeebene, die Anzahl der virtuellen Kerne, die Speichergröße, der Aufbewahrungszeitraum für Sicherungen und die Option für Sicherungsredundanz des ursprünglichen Servers verwendet. Außerdem werden Tags und Einstellungen wie „Virtuelles Netzwerk“ und „Firewall“ vom Quellserver übernommen. Die Compute- und Speicherebene, die Konfiguration und die Sicherheitseinstellungen des wiederhergestellten Servers können nach Abschluss der Wiederherstellung geändert werden.

Hinweis

Es gibt zwei Serverparameter, die nach dem Wiederherstellungsvorgang auf Standardwerte zurückgesetzt werden (und nicht vom primären Server übernommen werden).

  • time_zone: Dieser Wert wird auf den DEFAULT-Wert SYSTEM festgelegt.
  • event_scheduler: Bei MySQL-Servern mit Version 5.7 wird der Serverparameter event_scheduler automatisch deaktiviert, wenn die Sicherung initiiert wird. Außerdem wird der Serverparameter event_scheduler nach erfolgreichem Abschluss der Sicherung wieder auf „EIN“ zurückgesetzt. In MySQL Version 8.0 für Azure Database for MySQL – Flexibler Server ist „event_scheduler“ während Sicherungen nicht betroffen. Um einen reibungsloseren Betrieb sicherzustellen, empfiehlt es sich, Ihre MySQL 5.7-Server mithilfe eines Hauptversionsupgrades auf Version 8.0 zu aktualisieren.

Die Point-in-Time-Wiederherstellung ist für viele Szenarien hilfreich. Einige der üblichen Anwendungsfälle sind:

  • Wenn ein Benutzer versehentlich Daten in der Datenbank löscht
  • Der Benutzer löscht eine wichtige Tabelle oder Datenbank
  • Eine Benutzeranwendung überschreibt aufgrund eines Anwendungsfehlers versehentlich gültige Daten mit ungültigen Daten

Sie können zwischen dem neuesten Wiederherstellungspunkt, dem benutzerdefinierten Wiederherstellungspunkt und dem schnellsten Wiederherstellungspunkt (Wiederherstellung mit vollständiger Sicherung) über Azure-Portal wählen.

  • Letzter Wiederherstellungspunkt: Mit der Option „letzter Wiederherstellungspunkt“ können Sie den Server auf den Zeitstempel zurücksetzen, zu dem der Wiederherstellungsvorgang ausgelöst wurde. Diese Option ist hilfreich, um den Server schnell auf den aktuellsten Stand zu bringen.
  • Benutzerdefinierter Wiederherstellungspunkt: Mithilfe dieser Option können Sie einen beliebigen Zeitpunkt innerhalb des für diesen Server definierten Aufbewahrungszeitraums wählen. Diese Option ist nützlich, um den Server genau zu dem Zeitpunkt wiederherzustellen, zu dem ein Benutzerfehler aufgetreten ist.
  • Schnellster Wiederherstellungspunkt: Mit dieser Option können Benutzer*innen den Server innerhalb des für ihren Server definierten Aufbewahrungszeitraums für einen bestimmten Tag so schnell wie möglich wiederherstellen. Die schnellste Wiederherstellung ist möglich, indem Sie den Zeitpunkt der Wiederherstellung auswählen, zu dem die vollständige Sicherung abgeschlossen wurde. Dieser Wiederherstellungsvorgang stellt einfach die vollständige Momentaufnahmesicherung wieder her und garantiert keine Wiederherstellung oder Wiedergewinnung von Protokollen, wodurch sie erst schnell wird. Für einen erfolgreichen Wiederherstellungsvorgang wird empfohlen, einen vollständigen Sicherungszeitstempel auszuwählen, der größer als der früheste Wiederherstellungszeitpunkt.

Die geschätzte Wiederherstellungszeit hängt von mehreren Faktoren ab, einschließlich der Datenbankgrößen, der Größe der Sicherung des Transaktionsprotokolls, der Computegröße der SKU und auch der Zeit der Wiederherstellung. Die Wiederherstellung des Transaktionsprotokolls ist der zeitaufwendigste Teil des Wiederherstellungsprozesses. Wenn die Wiederherstellungszeit näher am Zeitplan der Momentaufnahmensicherung gewählt wird, erfolgen die Wiederherstellungsabläufe schneller, da die Anwendung des Transaktionsprotokolls minimal ist. Um die genaue Wiederherstellungszeit für Ihren Server zu schätzen, wird dringend empfohlen, ihn in Ihrer Umgebung zu testen, da er zu viele umgebungsspezifische Variablen aufweist.

Wichtig

Wenn Sie eine Instanz von Azure Database for MySQL – Flexibler Server wiederherstellen, die mit zonenredundanter Hochverfügbarkeit konfiguriert ist, wird der wiederhergestellte Server in derselben Region und Zone wie der primäre Server konfiguriert und als einzelner Server in einem Modus ohne Hochverfügbarkeit bereitgestellt. Weitere Informationen finden Sie unter Zonenredundante Hochverfügbarkeit für flexible Server.

Wichtig

Sie können eine gelöschte Ressource von Azure Database for MySQL – Flexibler Server innerhalb von 5 Tagen ab dem Zeitpunkt der Löschung des Servers wiederherstellen. Eine detaillierte Anleitung zur Wiederherstellung eines gelöschten Servers finden Sie in den dokumentierten Schritten. Um Serverressourcen nach der Bereitstellung vor versehentlichem Löschen oder unerwarteten Änderungen zu schützen, können Administratoren Verwaltungssperren nutzen.

Geowiederherstellung

Sie können einen Server in seiner geografisch gekoppelten Region wiederherstellen, in der der Dienst verfügbar ist, wenn Sie den Server für georedundante Sicherungen oder eine andere von Azure unterstützte Region konfiguriert haben, in der Azure Database for MySQL – Flexibler Server verfügbar ist. Die Möglichkeit zum Wiederherstellen einer nicht gekoppelten von Azure unterstützten Region (mit Ausnahme von Brazil South, USGov Virginia und West US 3)) wird als „Universelle Geowiederherstellung“ bezeichnet.

Die Geowiederherstellung ist die Standardoption für die Wiederherstellung, wenn Ihr Server aufgrund eines Incidents in der Region, in der der Server gehostet wird, nicht verfügbar ist. Wenn Ihre Datenbankanwendung wegen eines umfangreichen Incidents in einer Region nicht mehr verfügbar ist, können Sie einen Server aus den georedundanten Sicherungen auf einem Server in einer beliebigen anderen Region wiederherstellen. Bei der Geowiederherstellung wird die aktuellste Sicherung des Servers verwendet. Zwischen der Erstellung einer Sicherung und der Replikation in einer anderen Region kommt es zu einer Verzögerung. Diese Verzögerung kann bis zu einer Stunde betragen. Folglich kann bei einem Notfall ein Datenverlust von bis zu einer Stunde auftreten.

Die Geowiederherstellung kann mithilfe der Azure CLI auch auf einem beendeten Server ausgeführt werden. Weitere Informationen zur Geowiederherstellung eines Servers mit der Azure CLI finden Sie unter Wiederherstellen einer Instanz von Azure Database for MySQL – Flexibler Server mithilfe der Azure CLI.

Die geschätzte Wiederherstellungszeit hängt von verschiedenen Faktoren ab, z.B. der Datenbankgröße, Transaktionsprotokollgröße und Netzwerkbandbreite sowie der Gesamtzahl von Datenbanken, die gleichzeitig in derselben Region wiederhergestellt werden müssen.

Hinweis

Wenn Sie eine Geowiederherstellung für eine Instanz von Azure Database for MySQL – Flexibler Server durchführen, die mit zonenredundanter Hochverfügbarkeit konfiguriert ist, wird der wiederhergestellte Server in der geografisch gekoppelten Region und derselben Zone wie der primäre Server konfiguriert und als Einzelinstanz von Azure Database for MySQL – Flexibler Server in einem Modus ohne Hochverfügbarkeit bereitgestellt. Weitere Informationen finden Sie unter Zonenredundante Hochverfügbarkeit für Azure Database for MySQL – Flexibler Server.

Wichtig

Wenn die primäre Region ausfällt, können Sie keine georedundanten Server in der jeweiligen geografisch gekoppelten Region erstellen, da der Speicher nicht in der primären Region bereitgestellt werden kann. Sie müssen warten, bis die primäre Region verfügbar ist, um georedundante Server in der geografisch gekoppelten Region bereitstellen zu können. Wenn die primäre Region ausfällt, können Sie für den Quellserver weiterhin Geowiederherstellungen in der geografisch gekoppelten Region ausführen, indem Sie die Option „Georedundanz“ unter den Einstellungen „Compute und Speicher“ zum Konfigurieren von Servern im Wiederherstellungsportal deaktivieren und die Wiederherstellung als lokal redundanter Server durchführen, um Geschäftskontinuität sicherzustellen.

Durchführen der Aufgaben nach der Wiederherstellung

Nach beiden Wiederherstellungsverfahren (neuester Wiederherstellungspunkt oder Benutzerdefinierter Wiederherstellungspunkt) sollten Sie die folgenden Aufgaben durchführen, um Ihre Benutzer und Anwendungen wieder in den betriebsbereiten Zustand zu versetzen:

  • Umleiten von Clients und Clientanwendungen an den neuen Server, wenn der neue Server den ursprünglichen Server ersetzen soll.
  • Sicherstellen, dass geeignete Firewallregeln auf Serverebene und Regeln von virtuellen Netzwerken vorhanden sind, damit Benutzer eine Verbindung herstellen können.
  • Sicherstellen, dass geeignete Anmeldungen und Berechtigungen auf Datenbankebene vorhanden sind.
  • Konfigurieren der erforderlichen Warnungen.

Langzeitaufbewahrung (Vorschau)

Mit den Diensten für Azure Backup und Azure Database for MySQL – Flexibler Server wurde eine langfristige Sicherungslösung der Unternehmensklasse für Instanzen von Azure Database for MySQL Flexibler Server geschaffen, die Sicherungen für bis zu 10 Jahre aufbewahrt. Sie können die Langzeitaufbewahrung unabhängig oder zusätzlich zu der automatischen, von Azure Database for MySQL – Flexibler Server angebotenen Sicherungslösung verwenden, die eine Aufbewahrung von bis zu 35 Tagen bietet. Automatisierte Sicherungen sind Sicherungen von Momentaufnahmen, die für operative Wiederherstellungen geeignet sind – insbesondere, wenn Sie etwas aus den neuesten Sicherungen wiederherstellen möchten. Langfristige Sicherungen helfen Ihnen bei Ihren Complianceanforderungen und Überwachungsanforderungen. Neben der Langzeitaufbewahrung bietet die Lösung auch folgende Funktionen:

  • Vom Kunden kontrollierte geplante und bedarfsgesteuerte Sicherungen
  • Verwalten und überwachen Sie alle sicherungsbezogenen Vorgänge und Aufträge auf Servern, Ressourcengruppen, Speicherorten, Abonnements und Mandanten aus einem einzigen Glasbereich, der als Backup Center bezeichnet wird.
  • Sicherungen werden in separaten Sicherheits- und Fehlerdomänen gespeichert. Wenn der Quellserver oder das Abonnement kompromittiert wird, sind die Sicherungen im Azure Backup-Tresor (in von Azure Backup verwalteten Speicherkonten) weiterhin sicher.

Einschränkungen und Aspekte

  • In der Vorschauphase ist die LTR-Wiederherstellung derzeit als „RestoreasFiles“ für Speicherkonten verfügbar. Die Funktion „RestoreasServer“ wird später noch hinzugefügt.
  • Die Unterstützung für die LTR-Erstellung und -Verwaltung über Azure CLI wird derzeit nicht unterstützt.

Weitere Informationen zur langfristigen Sicherung finden Sie in der Schrittanleitung

On-Demand-Sicherung und -Export (Vorschau)

Azure Database for MySQL – Flexibler Server bietet jetzt die Möglichkeit, flexibel eine physische On-Demand-Zeitpunktsicherung des Servers auszulösen und in ein Azure Storage-Konto (Azure Blob Storage) zu exportieren. Nach dem Export können diese Sicherungen für Datenwiederherstellung, Migration und Redundanz verwendet werden. Diese exportierten physischen Sicherungsdateien können verwendet werden, um eine Wiederherstellung auf einem lokalen MySQL-Server durchzuführen und so die Anforderungen an Überwachung, Compliance und/oder Archivierung einer Organisation zu erfüllen. Dieses Feature befindet sich derzeit in der Public Preview-Phase und ist nur in öffentlichen Cloudregionen verfügbar.

Weitere Informationen zum Exportieren von Sicherungen finden Sie in der Schrittanleitung

Häufig gestellte Fragen (FAQs)

  • Wie sichere ich meinen Server?

    Azure Database for MySQL – Flexibler Server ermöglicht standardmäßig automatische Sicherungen des gesamten Servers (einschließlich aller erstellten Datenbanken) mit einem standardmäßigen Aufbewahrungszeitraum von 7 Tagen. Sie können mit dem Feature „Bedarfsgesteuerte Sicherung“ auch eine manuelle Sicherung auslösen. Eine andere Möglichkeit für das Erstellen manueller Sicherungen ist die Verwendung von Community-Tools wie mysqldump (hier dokumentiert) oder mydumper (hier dokumentiert). Wenn Sie eine Instanz von Azure Database for MySQL – Flexibler Server in einem Blobspeicher sichern möchten, lesen Sie den Tech Community-Blogbeitrag Backup Azure Database for MySQL flexible server to a Blob Storage (Sichern von Azure Database for MySQL – Flexibler Server in einem Blobspeicher).

  • Kann ich automatische Sicherungen so konfigurieren, dass sie langfristig aufbewahrt werden?

    Nein, derzeit unterstützen wir nur eine automatisierte Sicherungsaufbewahrung von maximal 35 Tagen. Sie können manuelle Sicherungen zur langfristigen Aufbewahrung durchführen.

  • Welche Sicherungsfenster gibt es für meinen Server? Kann ich sie anpassen?

    Die erste Momentaufnahmensicherung ist für unmittelbar nach Erstellung des Servers geplant. Momentaufnahmesicherungen werden einmal täglich erstellt. Transaktionsprotokollsicherungen finden alle fünf Minuten statt. Sicherungsfenster werden grundsätzlich von Azure verwaltet und können nicht angepasst werden.

  • Werden meine Sicherungen verschlüsselt?

    Alle Daten, Sicherungen und temporären Dateien für Azure Database for MySQL – Flexibler Server, die im Zuge der Abfrageausführung erstellt werden, werden mithilfe der AES-256-Bit-Verschlüsselung verschlüsselt. Die Speicherverschlüsselung ist immer aktiviert und kann nicht deaktiviert werden.

  • Kann ich einzelne oder mehrere Datenbanken wiederherstellen?

    Das Wiederherstellen einzelner oder mehrerer Datenbanken oder Tabellen wird nicht unterstützt. Falls Sie bestimmte Datenbanken wiederherstellen möchten, führen Sie eine Point-in-Time-Wiederherstellung durch und extrahieren Sie dann die benötigten Tabellen oder Datenbanken.

  • Ist mein Server während des Sicherungsfensters verfügbar?

    Ja. Sicherungen sind Onlinevorgänge und momentaufnahmebasiert. Der Momentaufnahmevorgang dauert nur wenige Sekunden und beeinträchtigt keine Produktionsworkloads, sodass Hochverfügbarkeit für den Server sichergestellt ist.

  • Müssen wir beim Einrichten des Wartungsfensters für den Server das Sicherungszeitfenster berücksichtigen?

    Nein, Sicherungen werden intern als Teil des verwalteten Diensts ausgelöst und haben keinen Einfluss auf das verwaltete Wartungsfenster.

  • Wo werden meine automatisierten Sicherungen gespeichert, und wie verwalte ich deren Aufbewahrung?

    Azure Database for MySQL – Flexibler Server erstellt automatisch Serversicherungen und speichert sie in einem benutzerseitig konfigurierten, lokal redundanten oder georedundanten Speicher. Diese Sicherungsdateien können nicht exportiert werden. Die Standardaufbewahrungsdauer für Sicherungen beträgt sieben Tage. Sie können die Sicherung der Datenbank optional von 1 bis 35 Tagen konfigurieren.

  • Wie kann ich meine Sicherungen validieren?

    Die beste Möglichkeit, die Verfügbarkeit erfolgreich abgeschlossener Sicherungen zu überprüfen, besteht in der Anzeige der vollständigen automatisierten Sicherungen, die innerhalb des Aufbewahrungszeitraums auf dem Blatt „Sicherung und Wiederherstellung“ erstellt wurden. Wenn bei einer Sicherung ein Fehler auftritt, wird sie nicht in der Liste der verfügbaren Sicherungen aufgeführt, und der Sicherungsdienst versucht alle 20 Minuten, eine Sicherung zu erstellen, bis eine erfolgreiche Sicherung erstellt wird. Diese Sicherungsfehler sind auf hohe Transaktionsproduktionslasten auf dem Server zurückzuführen.

  • Wo kann ich die Sicherungsverwendung einsehen?

    Im Azure-Portal finden Sie auf der Registerkarte „Überwachung“ im Abschnitt „Metriken“ die Metrik Verwendeter Sicherungsspeicher, die den gesamten Verbrauch für Sicherungen anzeigt.

  • Was geschieht mit meinen Sicherungen, wenn ich meinen Server lösche?

    Wenn Sie den Server löschen, werden auch alle zugehörigen Sicherungen gelöscht und können nicht wiederhergestellt werden. Zum Schutz von Serverressourcen vor versehentlicher Löschung oder unerwarteten Änderungen nach der Bereitstellung können Administrator*innen Verwaltungssperren verwenden.

  • Was geschieht mit meinen Sicherungen, wenn ich einen Server wiederherstelle?

    Wenn Sie einen Server wiederherstellen, wird immer ein neuer Server erstellt, der mithilfe der Sicherungen des ursprünglichen Servers wiederhergestellt wurde. Die alte Sicherung vom ursprünglichen Server wird nicht auf den neu wiederhergestellten Server kopiert und verbleibt beim ursprünglichen Server. Für den neu erstellten Server wird jedoch die erste Momentaufnahmesicherung unmittelbar nach der Erstellung geplant, und der Dienst stellt sicher, dass tägliche automatisierte Sicherungen erstellt und gemäß dem konfigurierten Serveraufbewahrungszeitraum gespeichert werden.

  • Wie wird meine Verwendung von Sicherungen in Rechnung gestellt?

    Azure Database for MySQL – Flexibler Server bietet bis zu 100 % des bereitgestellten Serverspeichers ohne zusätzliche Kosten als Sicherungsspeicher. Zusätzlich genutzter Sicherungsspeicher wird gemäß dem Preismodell in GB pro Monat in Rechnung gestellt. Die Abrechnung des Sicherungsspeichers hängt auch vom ausgewählten Aufbewahrungszeitraum für Sicherungen und von der ausgewählten Redundanzoption ab – abgesehen von der Transaktionsaktivität auf dem Server, die sich direkt auf den gesamten verwendeten Sicherungsspeicher auswirkt.

  • Wie werden Sicherungen für beendete Server beibehalten?

    Für beendete Server werden keine neuen Sicherungen ausgeführt. Alle älteren Sicherungen (innerhalb des Aufbewahrungszeitfensters) zum Zeitpunkt des Beendens des Servers werden bis zum Neustart des Servers aufbewahrt, wonach die Aufbewahrung der Sicherungen für den aktiven Server durch dessen Aufbewahrungszeitfenster bestimmt wird.

  • Wie werden mir Sicherungen angehaltener Server in Rechnung gestellt?

    Während Ihre Serverinstanz angehalten wird, werden Ihnen der bereitgestellte Speicher (einschließlich bereitgestellter IOPS) und der Sicherungsspeicher (Sicherungen, die im angegebenen Aufbewahrungszeitfenster gespeichert sind) in Rechnung gestellt. Der kostenlose Sicherungsspeicher ist auf die Größe Ihrer bereitgestellten Datenbank beschränkt und gilt nur für aktive Server.

  • Wie werden meine Sicherungsdaten geschützt?

    Azure Database for MySQL – Flexibler Server schützt Ihre Sicherungsdaten, indem alle Vorgänge blockiert werden, die zu Verlust von Wiederherstellungspunkten für die Dauer des konfigurierten Aufbewahrungszeitraums führen könnten. Die während des Aufbewahrungszeitraums vorgenommenen Sicherungen können nur zum Zweck der Wiederherstellung gelesen werden. Sie werden nach dem Aufbewahrungszeitraum gelöscht. Darüber hinaus werden alle Sicherungen in Azure Database for MySQL – Flexibler Server mit AES 256-Bit-Verschlüsselung für die ruhenden Daten verschlüsselt.

  • Wie wirkt sich ein PITR-Vorgang (Point-In-Time Restore, Zeitpunktwiederherstellung) auf den IOPS-Verbrauch aus?

    Während eines PITR-Vorgangs in Azure Database for MySQL – Flexibler Server wird ein neuer Server erstellt, und es werden Daten aus dem Speicher des Quellservers in den Speicher des neuen Servers kopiert. Dieser Prozess führt zu einem höheren IOPS-Verbrauch auf dem Quellserver. Dieser höhere IOPS-Verbrauch ist normal und kein Anzeichen für Probleme mit dem Quellserver oder dem PITR-Vorgang. Nach Abschluss des PITR-Vorgangs fällt der IOPS-Verbrauch auf dem Quellserver wieder auf den üblichen Wert.

  • Wie kann ich meinen Server wiederherstellen? Das Azure-Portal unterstützt die Zeitpunktwiederherstellung für alle Server, sodass Benutzer*innen den neuesten oder einen benutzerdefinierten Wiederherstellungspunkt wiederherstellen können. Weitere Informationen zum manuellen Wiederherstellen Ihres Servers aus den Sicherungen, die mit mysqldump/myDumper erstellt wurden, finden Sie unter Wiederherstellen Ihrer Datenbank mit myLoader.

  • Warum dauert meine Wiederherstellung so lange?

    Die geschätzte Zeit für die Wiederherstellung des Servers ist von mehreren Faktoren abhängig:

    • Größe der Datenbanken Im Rahmen des Wiederherstellungsprozesses muss die Datenbank mit Daten aus der letzten physischen Sicherung aufgefüllt werden. Daher ist der Zeitaufwand der Wiederherstellung proportional zur Größe der Datenbank.
    • Der aktive Teil der Transaktionsaktivität, der zur Wiederherstellung erneut durchgeführt werden muss Die Wiederherstellung kann abhängig von der zusätzlichen Transaktionsaktivität seit dem letzten erfolgreichen Prüfpunkt länger dauern.
    • Netzwerkbandbreite, sofern die Wiederherstellung in einer anderen Region erfolgt
    • Anzahl der gleichzeitigen Wiederherstellungsanforderungen, die aktuell in der Zielregion verarbeitet werden
    • Vorhandensein eines Primärschlüssels in den Tabellen in der Datenbank. Um die Wiederherstellung zu beschleunigen, sollten Sie für alle Tabellen in der Datenbank Primärschlüssel hinzufügen.

  • Wirkt sich das Ändern von Datenbankvariablen auf Sitzungsebene auf die Wiederherstellung aus?

    Das Ändern von Variablen auf Sitzungsebene und das Ausführen von DML-Anweisungen in der MySQL-Clientsitzung kann sich auf den PITR-Vorgang (Point-In-Time Restore, Zeitpunktwiederherstellung) auswirken, da diese Änderungen nicht im binären Protokoll erfasst werden, das für Sicherungs- und Wiederherstellungsvorgänge verwendet wird. foreign_key_checks ist beispielsweise eine solche Variable auf Sitzungsebene. Sie führt zu einem Fehler bei der Zeitpunktwiederherstellung, wenn sie für die Ausführung einer DML-Anweisung deaktiviert wird, die gegen die Fremdschlüsseleinschränkung verstößt. Die einzige Problemumgehung in einem solchen Szenario besteht darin, einen PITR-Zeitpunkt auszuwählen, der vor dem Zeitpunkt liegt, zu dem foreign_key_checks deaktiviert wurde. Unsere Empfehlung besteht darin, für einen erfolgreichen PITR-Vorgang KEINE Sitzungsvariablen zu ändern.

Nächste Schritte