Migrationsphasen und Überlegungen

Abgeschlossen

Eine erfolgreiche Migration gleicht Überlegungen in mehreren Phasen ab.

Migrationsphasen

Migrationen erfolgen in mehreren Phasen. Planen Sie zunächst den Migrationsumfang: Ermittlung und Bewertung von Datenbankressourcen, Geschäftsanforderungen wie Downtime und ein Fallbackplan, wenn die Migration fehlschlägt. Bereiten Sie dann die Migration vor, indem Sie geeignete Ressourcen bereitstellen und die Konnektivität zwischen Quell- und Zielumgebungen einrichten. Nachdem der Migrationsansatz festgelegt wurde und Ressourcen bereit sind, möchten Sie in der Regel einen Trockenlauf in einer Stagingumgebung durchführen, um Probleme vor der Produktionsmigration zu identifizieren. Führen Sie schließlich die endgültige Migration aus, und überprüfen Sie den laufenden Fortschritt und den erfolgreichen Abschluss.

Dieses Modul konzentriert sich auf die Vorbereitungsphasen (2) und endgültige Migration (4, 5).

Migrationsüberlegungen

Sie sollten die Anforderungen für Downtime, Versionskompatibilität, Netzwerk und Sicherheit, Leistung, Kosten und Geschäftskontinuität bewerten.

Anwendungsdowntime

Eines der ersten Punkte, die Sie berücksichtigen sollten, ist, wie viel Downtime Ihr Geschäftsszenario aufnehmen kann. Die Antwort schränkt Ihre verfügbaren Migrationsoptionen stark ein.

Die beste Downtime ist eine, die Benutzer nicht bemerken. In der Praxis sind Migrationen komplexe Verfahren, und Entscheidungen zu den Überlegungen in diesem Modul bestimmen die erforderlichen Downtime. Zu den Kompromissen gehören die Verfügbarkeit im Vergleich zu den Kosten und dem Risiko der Migration. Aufgrund der Komplexität bei der Reduzierung von Downtime auf Minuten oder sogar Sekunden ist es wichtig, Annahmen zu testen und zu bestimmen, wie viel Migrations-Downtime akzeptabel ist.

Offlinemigrationen

Bei einer Offlinemigration müssen Sie die Anwendung herunterfahren, um die Datenbank zu verschieben. Dadurch wird sichergestellt, dass während der Migration keine Änderungen an den Daten vorliegen. Dieser Ansatz erfordert jedoch, dass die Datenbank abgeschlossen wird, um den Datenexport abzuschließen. Die Downtime ist immer mindestens so lange, wie es dauert, die Daten zu übertragen. Eine Offlinemigration umfasst Folgendes:

1. Trennen aller Apps von der Quelldatenbank.
2. Exportieren des Inhalts der Quelldatenbank.
3. Importieren der Quelldaten in die Zieldatenbank.
4. Erneutes Verbinden von Anwendungen mit der Zieldatenbank nach Abschluss des Imports.

Einige Anwendungen haben Wartungsfenster in Zeiträumen mit geringem Datenverkehr geplant. Dies sind großartige Zeiten, um Offlinemigrationen durchzuführen.

Eine inkrementelle Offlinemigration reduziert Downtime, indem der Großteil der Daten verschoben wird, bevor die Anwendung offline geschaltet wird. Migrieren Sie zunächst eine vollständige Datenbanksicherung. Migrieren Sie dann die Änderungen an der Datenbank, die seit der vorherigen Migration hinzugefügt wurden. Wenn die Zeit, die zum Migrieren dieser neuen Änderungen erforderlich ist, in Ihre akzeptable Downtime passt, nehmen Sie die Anwendung offline, um die Daten zu fixieren und die Migration abzuschließen. Möglicherweise stellen Sie fest, dass ein einzelner Migrationsschritt ausreicht, um Downtime um eine Größenordnung oder mehr zu reduzieren, insbesondere für Datenbanken mit Jahrelanger Geschichte. Bei großen und ausgelasteten Datenbanken müssen Sie möglicherweise mehrere Inkremente migrieren, um akzeptable Downtime zu erreichen.

Onlinemigrationen

Mit einer Onlinemigration können Sie die Downtime erheblich reduzieren oder sogar beseitigen, indem Sie während der Migration Änderungen vom Quellserver auf den Zielserver replizieren und dann auf den Zielserver überschneiden, wenn die Replikation vollständig synchronisiert ist.

Manchmal ist Downtime unerwünscht oder sogar inakzeptabel. In diesem Fall ist es unmöglich, den Datenbankstatus zu "fixieren", indem die Anwendung deaktiviert wird. Stattdessen wird die Quelldatenbank während normaler Vorgänge in die Zieldatenbank repliziert. Wenn das Ziel vollständig mit der Quelle abgefangen wird, überschneidet die Anwendung die Zieldatenbank.

Eine Onlinemigration erfordert Folgendes:

1. Beginnen Sie mit der Replikation der Quelldatenbank in die Zieldatenbank.
2. Wenn die Zieldatenbank abgefangen wird, fixieren Sie die Quelldatenbank entweder durch Anhalten der Anwendung oder durch Erzwingen von Schreibvorgängen, indem Sie den schreibgeschützten Modus aktivieren.
3. Wenn die Zieldatenbank 100 % bei den Änderungen erfasst wird, deaktivieren Sie die Replikation im Ziel.
4. Leiten Sie alle Clients an die Zieldatenbank und nehmen Sie den Betrieb wieder auf.
5. Beenden Sie die Legacyquelldatenbank.

Vergleichen von Online- und Offlinemigration

Während Offlinemigrationen Downtime erfordern, reduziert die zuvor beschriebene inkrementelle Migrationsmethode Downtime erheblich. Mehrere Inkremente können die endgültige Migration auf einen Tageswert von Daten oder weniger verkleinern. Automatisierte Dienste wie Azure DMS minimieren Downtime, indem sie eine Reihe von immer kleineren Migrationen durchführen. Inkrementelle Offlinemigrationen können auch manuell ausgeführt werden, wenn Netzwerkeinstellungen die Automatisierung verhindern.

Onlinemigrationen koordinieren einen heiklen Vorgang über Datenbank- und Anwendungsteams hinweg. Clientanwendungen müssen ausgestattet werden, um ordnungsgemäß auf Schreibfehler zu reagieren, um Datenverluste während der Migration zu vermeiden. Clients müssen auch die Verbindung mit einem neuen Datenbankserver unterstützen, ohne die Benutzererfahrung zu unterbrechen. Wenn diese Anwendungstools noch nicht vorhanden sind, kann es ziemlich teuer sein, sie zu erstellen.

Versionskompatibilität

Die meisten Anwendungsvorgänge sind mit MySQL-Upgrades kompatibel. In einigen Fällen können Anwendungskomponenten oder Datenbankverwendung jedoch nur mit bestimmten MySQL-Versionen verwendet werden.

Überprüfen Sie, ob alle Anwendungskomponenten mit der Zieldatenbankversion kompatibel sind. Erwägen Sie, Versionsupgrades von Migrationen zu trennen, die eine Datenbank verschieben oder neu konfigurieren. Wenn Sie z. B. von der lokalen MySQL 5.7 zu einer Azure Datenbase for MySQL flexiblen Server migrieren, auf dem MySQL 8.0 ausgeführt wird, sollten Sie die Migration von der lokalen Datenbank zu einem Azure Database for MySQL flexiblen Server mit MySQL 5.7 in Betracht ziehen und dann ein Upgrade von 5.7 auf 8.0 durchführen.

Netzwerke und Sicherheit

Datenbankmigrationen erfordern das Übertragen von Daten aus der Quelldatenbank an das Ziel. Wie dies geschieht und wie schnell, hängt weitgehend von der Verbindung zwischen den beiden Netzwerken ab. Wenn Sie keine Liveverbindung von der Quelle zum Ziel herstellen können, müssen Sie physische Datendateien auf eine andere Weise übertragen, z. B. über eine Zwischenarbeitsstation oder einen Server. Stellen Sie in diesem Fall sicher, dass genügend Speicherplatz zur Speicherung der Momentaufnahmen auf jedem System vorhanden ist.

Es ist auch wichtig, sicherheitsrelevante Anforderungen während der Migration zu berücksichtigen. Sie benötigen geeignete Authentifizierung und Berechtigungen für Quell- und Zieldatenbanken. Möglicherweise möchten Sie auch Dienstkonten erstellen, um einige oder alle Migrationsschritte auszuführen, und dann können Sie den Zugriff nach Abschluss entfernen.

Unabhängig davon, ob die Quelldatenbank lokal ist oder sich auf einem anderen Cloudanbieter befindet, lassen Netzwerkeinstellungen in der Regel keine externen Verbindungen zu. Sie müssen das Netzwerk so konfigurieren, dass Verbindungen mit Azure zugelassen werden.

Wenn die Quelldatenbank lokal ist und das Datenvolumen groß ist, kann das Verschieben von Daten über eine normale Internetverbindung unpraktisch langsam sein. In diesem Szenario sollten Sie eine Azure ExpressRoute-Verbindung zwischen Ihrem Netzwerk und Azure einrichten.

Selbst wenn Sie eine ExpressRoute verwenden, wird die Verbindung, auf der sie sich befindet, wahrscheinlich auch anderen Datenverkehr dienen, und die beiden können sich gegenseitig stören. Je nach Inhalt kann der Leistungstreffer für vorhandene Anwendungen und der Migrationsprozess erheblich sein.

Leistung

Datenbankmigrationen sind eine hervorragende Möglichkeit, die Kapazität durch Größenänderung der Infrastruktur zu erhöhen. Ihre Datenbanknutzung kann von erhöhten CPU-, RAM- oder E/A-Ressourcen profitieren.

Berücksichtigen Sie vor der Bereitstellung des Zielservers die aktuelle Datenbanknutzung. Überwachen Sie Leistungsmetriken wie die CPU-Auslastung zusammen mit der Prognose für Wachstum und SLAs, um zu entscheiden, ob Sie eine größere Berechnungsgröße zuweisen sollten. Im Gegensatz dazu stellen Sie möglicherweise fest, dass Ihre Kapazität überlastet ist und dass das Senken von Kosten beeinträchtigt wird.

Kosten

Wenn Sie zu Azure migrieren, können Sie transparente Preise nutzen. Mit Ihrer ausgewählten SKU und anderen Parametern wie Redundanz und hoher Verfügbarkeit können Sie mit dem Azure-Preisrechner Ihre Kosten nach der Migration während der Planung schätzen. Sie können den Rechner auch verwenden, um Kompromisse zu informieren, z. B. Verfügbarkeit im Vergleich zu Kosten.

Geschäftskontinuität

Datenbankmigrationen sind ein guter Zeitpunkt, um Geschäftskontinuitätsmetriken und -ziele zu überprüfen. Es kann sinnvoll sein, Sicherungsaufbewahrungsrichtlinien zu ändern oder zu georedundanten Sicherungen oder hoher Verfügbarkeit zu wechseln. Berücksichtigen Sie ihre historische Betriebszeit im Vergleich zu SLA- und Ausfallwiederherstellungszeit. Migrationen bieten auch praxisnahe Beispiele für das Aufbauen einer neuen Datenbank aus physischen Datendateien, die Notfallwiederherstellungspläne informieren können.