Migration einer lokalen MySQL-Instanz zu Azure Database for MySQL: Business Continuity & Disaster Recovery (BCDR)

Die Gewährleistung der Business Continuity & Disaster Recovery ist bei der Migration von MySQL-Datenbanken von lokalen Umgebungen zur Azure Database for MySQL von entscheidender Bedeutung. Dieser Artikel befasst sich mit den Strategien und bewährten Verfahren zur Aufrechterhaltung eines unterbrechungsfreien Betriebs und zum Schutz von Daten während und nach der Migration. Durch die Nutzung der robusten BCDR-Funktionen von Azure können Sie die Downtime minimieren, sich vor Datenverlust schützen und eine schnelle Wiederherstellung im Katastrophenfall sicherstellen. Dieser Leitfaden enthält die erforderlichen Einblicke, um einen umfassenden BCDR-Plan zu entwickeln, potenzielle Risiken zu bewältigen und die erweiterten Funktionen von Azure zu nutzen, um die Ausfallsicherheit und Zuverlässigkeit zu verbessern. Unabhängig davon, ob Sie Ihre Funktionen zur Notfallwiederherstellung verbessern oder eine kontinuierliche Verfügbarkeit sicherstellen möchten, vermittelt Ihnen dieser Artikel wichtige Grundlagen für eine nahtlose und sichere Migration.

Voraussetzungen

Migrieren einer lokalen MySQL-Instanz zu Azure Database for MySQL: Optimierung

Sichern und Wiederherstellen

Wie bei jedem unternehmenskritischen System ist die Strategie für Sicherung und Wiederherstellung sowie Notfallwiederherstellung (BCDR) ein wichtiger Bestandteil Ihres gesamten Systementwurfs. Wenn ein unvorhergesehenes Ereignis eintritt, sollten Sie in der Lage sein, den Stand Ihrer Daten zu einem bestimmten Zeitpunkt (Recovery Point Objective) in einem angemessenen Zeitraum (Recovery Time Objective) wiederherzustellen.

Backup

Azure Database for MySQL unterstützt standardmäßig automatische Sicherungen für sieben Tage. Es kann sinnvoll sein, dies auf das aktuelle Maximum von 35 Tagen zu ändern. Sie müssen beachten, dass bei einer Änderung des Werts in 35 Tage Gebühren für über den zugeordneten Speicher hinausgehenden zusätzlichen Sicherungsspeicher anfallen.

Es gibt mehrere aktuelle Einschränkungen der Datenbanksicherungsfunktion, wie im Dokumentationsartikel Sicherung und Wiederherstellung in Azure Database for MySQL beschrieben. Diese müssen Sie kennen, wenn Sie entscheiden, welche zusätzlichen Strategien implementiert werden sollen.

Sie müssen z. B. Folgendes beachten:

• Kein direkter Zugriff auf die Sicherungen

• Für Ebenen, die bis zu 4 TB zulassen, wird einmal pro Woche eine vollständige Sicherung durchgeführt, zweimal täglich eine differenzielle und alle fünf Minuten Protokolle.

• Für Ebenen, die bis zu 16 TB zulassen, werden Sicherungen auf Momentaufnahmenbasis durchgeführt.

  Hinweis

  Einige Regionen unterstützen noch keinen Speicher von bis zu 16 TB.

Restore

Redundanz (lokal oder Georedundanz) muss während der Servererstellung konfiguriert werden. Eine Geowiederherstellung kann jedoch durchgeführt werden und ermöglicht die Änderung dieser Optionen während des Wiederherstellungsprozesses. Das Ausführen eines Wiederherstellungsvorgangs kann die Konnektivität vorübergehend beenden, und alle Anwendungen sind während des Wiederherstellungsvorgangs ausgeschaltet.

Während einer Datenbankwiederherstellung müssen alle unterstützenden Elemente außerhalb der Datenbank wiederhergestellt werden.
Überprüfen Sie den Migrationsprozess. Weitere Informationen finden Sie unter Durchführen der Aufgaben nach der Wiederherstellung.

Lesereplikate

Lesereplikate können verwendet werden, um den MySQL-Lesedurchsatz zu erhöhen, die Leistung für regionale Benutzer zu verbessern und die Notfallwiederherstellung zu implementieren. Beachten Sie beim Erstellen eines oder mehrerer Lesereplikate, dass zusätzliche Gebühren für die gleiche Compute- und Speichernutzung wie für den primären Server anfallen.

Gelöschte Server

Wenn ein Administrator oder ein böswilliger Benutzer den Server im Azure-Portal oder über automatisierte Methoden löscht, werden alle Sicherungen und Lesereplikate gelöscht. Es ist wichtig, dass Ressourcensperren für die Azure Database for MySQL-Ressourcengruppe erstellt werden, um den Instanzen eine zusätzliche Löschschutzebene hinzuzufügen.

Regionaler Ausfall

Wenn ein seltener regionalen Ausfall eintritt, können georedundante Sicherungen oder ein Lesereplikat verwendet werden, um die Datenworkloads wieder auszuführen. Sowohl die Georeplikation als auch ein Lesereplikat sollten zur Verfügung stehen, um den besten Schutz vor unerwarteten regionalen Ausfällen zu bieten.

Load Balancer

Wenn die Anwendung aus vielen verschiedenen Instanzen auf der ganzen Welt besteht, ist es möglicherweise nicht möglich, alle Clients zu aktualisieren. Verwenden Sie einen Azure Load Balancer oder ein Application Gateway, um eine nahtlose Failoverfunktion zu implementieren. Obwohl sie hilfreich und zeitsparend sind, sind diese Tools für regionale Failoverfunktionen nicht erforderlich.

WWI-Szenario

WWI wollte die Failoverfunktionen von Lesereplikaten testen, sodass sie die unten beschriebenen Schritte ausgeführt haben.

Erstellen eines Lesereplikats

• Öffnen Sie das Azure-Portal.

• Navigieren Sie zur Azure Database for MySQL-Instanz.

• Wählen Sie unter Einstellungen die Option Replikation aus.

• Wählen Sie Replikat hinzufügen.

• Geben Sie einen Servernamen ein.

• Wählen Sie die Region aus.

• Wählen Sie OK aus, und warten Sie, bis die Instanz bereitgestellt wurde. Je nach Größe der Hauptinstanz kann die Replikation einige Zeit dauern.

  Hinweis

  Für jedes Replikat fallen zusätzliche Gebühren an, die denen für die Hauptinstanz entsprechen.

Failover zum Lesereplikat

Sobald ein Lesereplikat erstellt und der Replikationsprozess abgeschlossen ist, kann es für ein Failover verwendet werden. Die Replikation wird während eines Failovers beendet und macht das Lesereplikat zu einer eigenen Hauptinstanz.

Failoverschritte:

• Öffnen Sie das Azure-Portal.

• Navigieren Sie zur Azure Database for MySQL-Instanz.

• Wählen Sie unter Einstellungen die Option Replikation aus.

• Wählen Sie eines der Lesereplikate aus.

• Wählen Sie Replikation beenden aus. Dadurch wird das Lesereplikat unterbrochen.

• Ändern Sie alle Anwendungsverbindungszeichenfolgen so, dass sie auf die neue Hauptinstanz verweisen.

BCDR-Prüfliste

• Ändern Sie die Sicherungshäufigkeit, um die Anforderungen zu erfüllen.

• Richten Sie Lesereplikate für leseintensive Workloads und regionales Failover ein.

• Erstellen Sie Ressourcensperren für Ressourcengruppen.

• Implementieren Sie eine Lastenausgleichsstrategie für Anwendungen für schnelles Failover.

Nächster Schritt