Tutorial: Onlinemigrieren von MySQL zu Azure Database for MySQL – Flexibler Server mithilfe von DMS über das Azure-Portal

Sie können mit dem Azure Database Migration Service (DMS) Ihre lokalen oder anderen Clouddienst-MySQL-Server zu Azure Database for MySQL – Flexibler Server migrieren, einem vollständig verwalteten Dienst, der für nahtlose Migrationen von mehreren Datenbankquellen zu Azure-Datenplattformen entwickelt wurde. In diesem Tutorial führen Sie mithilfe einer DMS-Migrationsaktivität eine Onlinemigration einer Beispieldatenbank von einem lokalen MySQL-Server zu einer Instanz von Azure Database for MySQL – Flexibler Server (beide mit Version 5.7) durch.

Hinweis

Die DMS-Onlinemigration ist jetzt allgemein verfügbar. DMS unterstützt die Migration zu MySQL-Versionen 5.7 und 8.0 und unterstützt auch die Migration von MySQL-Servern (v5.6 und höher) zu höheren Versionsservern. Darüber hinaus unterstützt DMS regionsübergreifende, ressourcenübergreifende und abonnementübergreifende Migrationen, sodass Sie eine Region, Ressourcengruppe und ein Abonnement für den Zielserver auswählen können, der sich von dem für Den Quellserver unterscheidet.

In diesem Tutorial erfahren Sie, wie:

• Implementieren Sie bewährte Methoden zum Erstellen eines flexiblen Servers für schnelleres Laden von Daten mithilfe von DMS.
• Erstellen und konfigurieren Sie einen flexiblen Zielserver.
• Erstellen Sie eine DMS-Instanz.
• Erstellen Sie ein MySQL-Migrationsprojekt in DMS.
• Migrieren Sie ein MySQL-Schema mithilfe von DMS.
• Ausführen der Migration
• Überwachen der Migration
• Führen Sie die Schritte nach der Migration durch.
• Implementieren Sie bewährte Methoden für die Durchführung einer Migration.

Voraussetzungen

Für dieses Tutorial benötigen Sie Folgendes:

• Erstellen Sie eine MySQL-Instanz, oder verwenden Sie eine bestehende (den Quellserver).

• Um die Onlinemigration erfolgreich abzuschließen, stellen Sie sicher, dass die folgenden Voraussetzungen vorhanden sind:

  • Verwenden Sie das Befehlszeilentool MySQL Ihrer Wahl, um zu überprüfen, ob log_bin auf dem Quellserver aktiviert ist, indem Sie den Befehl ausführen: SHOW VARIABLES LIKE 'log_bin' Wenn log_bin diese Option nicht aktiviert ist, müssen Sie sie vor dem Starten der Migration aktivieren.

  • Stellen Sie sicher, dass der Benutzer REPLICATION CLIENT und REPLICATION REPLICA-Berechtigungen auf dem Quellserver hat, um das Binärprotokoll zu lesen und anzuwenden.

  • Wenn Sie eine Onlinemigration anstreben, müssen Sie die Ablaufeinstellungen für Binlog-Dateien auf dem Quellserver konfigurieren, um sicherzustellen, dass diese Dateien nicht gelöscht werden, bevor das Replikat die Änderungen abschließt. Wir empfehlen mindestens zwei Tage für den Anfang. Der Parameter hängt von der Version Ihres MySQL-Servers ab. Für MySQL 5.7 lautet expire_logs_days der Parameter (standardmäßig ist er auf 0 festgelegt, was keine automatische Bereinigung ist). Für MySQL 8.0 ist es binlog_expire_logs_seconds (standardmäßig auf 30 Tage festgelegt). Nach einem erfolgreichen Cutover können Sie den Wert zurücksetzen.

• Um eine Schemamigration erfolgreich abzuschließen, benötigt der Benutzer, der die Migration durchführt, die folgenden Berechtigungen auf dem Quellserver:

  • SELECT-Berechtigung auf Serverebene auf der Quelle.

  • Wenn Ansichten migriert werden, muss der Benutzer über die BERECHTIGUNG SHOW VIEW auf dem Quellserver und über die CREATE VIEW-Berechtigung auf dem Zielserver verfügen.

  • Wenn Sie Trigger migrieren, muss der Benutzer über die TRIGGER-Berechtigung auf dem Quell- und Zielserver verfügen.

  • Wenn Routinen (Prozeduren und/oder Funktionen) migriert werden, muss der Benutzer über die BERECHTIGUNGEN CREATE ROUTINE und ALTER ROUTINE verfügen, die auf Serverebene auf dem Ziel gewährt werden.

  • Wenn Ereignisse migriert werden, muss der Benutzer über die EREIGNISberechtigung auf dem Quell- und Zielserver verfügen.

  • Wenn Benutzer/Anmeldungen migriert werden, muss der Benutzer über die BERECHTIGUNG CREATE USER auf dem Zielserver verfügen.

  • DROP-Berechtigung auf Serverebene auf dem Zielsystem, um Tabellen zu löschen, die möglicherweise bereits vorhanden sind. Beispiel: Wiederholen einer Migration.

  • Berechtigung REFERENCES auf Serverebene für das Ziel, um Tabellen mit Fremdschlüsseln zu erstellen.

  • Wenn Sie zu MySQL 8.0 migrieren, muss der Benutzer über die SESSION_VARIABLES_ADMIN Berechtigungen auf dem Zielserver verfügen.

  • CREATE-Berechtigung auf Serverebene auf dem Zielserver.

  • INSERT-Berechtigung auf Serverebene des Ziels.

  • Berechtigung UPDATE für das Ziel auf Serverebene.

  • Berechtigung DELETE für das Ziel auf Serverebene.

Einschränkungen

Bei der Vorbereitung der Migration sollten Sie die folgenden Einschränkungen beachten.

• Wenn Sie Nicht-Tabellenobjekte migrieren, unterstützt DMS das Umbenennen von Datenbanken nicht.

• Wenn Sie zu einem Zielserver mit aktiviertem bin_log migrieren, stellen Sie sicher, dass log_bin_trust_function_creators aktiviert ist, um die Erstellung von Routinen und Triggern zu ermöglichen.

• Derzeit unterstützt DMS die Migration der DEFINER-Klausel für Objekte nicht. Alle Objekttypen mit Definern aus der Quelle werden am Ziel gelöscht. Nach der Migration wird der Standarddefinierer für alle Objekte, die eine Definerklausel unterstützen und während der Schemamigration erstellt werden, auf die Anmeldung festgelegt, die zum Ausführen der Migration verwendet wird.

• Derzeit unterstützt DMS nur die Migration eines Schemas als Teil der Datenverschiebung. Wenn nichts für die Datenverschiebung ausgewählt ist, tritt die Schemamigration nicht auf. Bei Auswahl einer Tabelle für die Schemamigration, wird diese auch für die Datenverschiebung ausgewählt.

• Die Unterstützung der Onlinemigration ist auf das ROW-Binlog-Format beschränkt.

• Azure-Datenbank für MySQL – Flexible Server unterstützt keine Gemischtfalldatenbanken. Datenbanken mit gemischter Groß-/Kleinschreibung auf der Quelle werden bei einer Online-Migration nicht berücksichtigt.

• Die Onlinemigration unterstützt jetzt die DDL-Anweisungsreplikation bei der Migration zu einem Zielserver mit Azure Database for MySQL – Flexibler Server v8.0 oder v5.7.

  • Die Anweisungsreplikation wird für Datenbanken, Tabellen und Schemaobjekte (Ansichten, Routinen, Trigger) unterstützt, die bei der Konfiguration einer Azure DMS-Migrationsaktivität für die Schemamigration ausgewählt sind. Datendefinitions- und Verwaltungsanweisungen für Datenbanken, Tabellen und Schemaobjekte, die nicht ausgewählt sind, werden nicht repliziert. Wenn Sie einen gesamten Server für die Migration auswählen, werden Anweisungen für alle Tabellen, Datenbanken und Schemaobjekte repliziert, die auf dem Quellserver erstellt werden, nachdem die anfängliche Last abgeschlossen wurde.

  • Die Azure DMS-Anweisungsreplikation unterstützt alle Datendefinitionsanweisungen, mit Ausnahme der folgenden Befehle:

    • LOGFILE GROUP-Anweisungen
    • SERVER-Anweisungen
    • SPATIAL REFERENCE SYSTEM-Anweisungen
    • TABLESPACE-Anweisungen

  • Die Azure DMS-Anweisungsreplikation unterstützt alle Datenverwaltungsanweisungen – Kontoverwaltungsanweisungen, mit Ausnahme der folgenden Befehle:

    • SET DEFAULT ROLE
    • SET PASSWORD

  • Die Azure DMS-Anweisungsreplikation unterstützt alle Datenverwaltung – Tabellenwartungsanweisungen, mit Ausnahme der folgenden Befehle:

    • REPARATUR TABELLE
    • ANALYSIEREN DER TABELLE
    • PRÜFSUMMENTABELLE

  • Die Azure DMS-Anweisung oder binlog-Replikation unterstützt die folgende Syntax nicht: CREATE TABLE 'b' as SELECT * FROM 'a';. Die Replikation dieser DDL führt zu folgendem Fehler: "Nur BINLOG INSERT-, COMMIT- und ROLLBACK-Anweisungen sind nach CREATE TABLE mit START TRANSACTION-Anweisung zulässig."

• Die Migrationsdauer kann durch die Computewartung im Back-End beeinflusst werden, und der Fortschritt kann dabei zurückgesetzt werden.

Bewährte Methoden zum Erstellen eines flexiblen Servers für schnelleres Laden von Daten mithilfe von DMS

DMS unterstützt regionsübergreifende, ressourcenübergreifende und abonnementübergreifende Migrationen, sodass Sie die gewünschte Region, Ressourcengruppe und das Abonnement für Ihren flexiblen Zielserver auswählen können. Bevor Sie Ihren flexiblen Zielserver erstellen, sollten Sie die folgenden Konfigurationsanweisungen beachten, um ein schnelleres Laden der Daten unter Verwendung von DMS sicherzustellen.

• Wählen Sie die Rechengröße und Rechenebene für den flexiblen Zielserver basierend auf der Konfiguration des MySQL-Quellservers aus.

  ¹ Wählen Sie für die Migration als bewährte Methode die Berechnung von General Purpose 16 vCores oder höher für den flexiblen Zielserver für schnellere Migrationen aus. Skalieren Sie die Rechengröße für den Zielserver nach Abschluss der Migration auf die gewünschte Größe zurück.

• Die MySQL-Version für den flexiblen Zielserver muss größer oder gleich dem des MySQL-Quellservers sein.

• Wenn Sie den flexiblen Zielserver nicht in einer bestimmten Zone bereitstellen müssen, legen Sie den Wert des Parameters "Availability Zone " auf "No preference" fest.

• Wählen Sie für die Netzwerkkonnektivität auf der Registerkarte "Netzwerk" die Option "Privater Zugriff" aus. Andernfalls wählen Sie "Öffentlicher Zugriff" aus und konfigurieren Sie die Firewall-Regeln, um den Zugriff auf den flexiblen Zielserver zu ermöglichen.

Erstellen und Konfigurieren des flexiblen Zielservers

Unter Berücksichtigung dieser bewährten Methoden erstellen Sie Ihren flexiblen Zielserver und konfigurieren ihn anschließend.

• Erstellen Sie den flexiblen Zielserver. Anleitungsschritte finden Sie im Schnellstart: Erstellen einer Instanz von Azure Database for MySQL über das Azure-Portal.

• Konfigurieren Sie den neuen flexiblen Zielserver wie folgt:

  • Der Benutzer, der die Migration durchführt, benötigt die folgenden Berechtigungen:

    • Stellen Sie sicher, dass Benutzer auf dem Zielserver über die Berechtigung REPLICATION_APPLIER oder BINLOG_ADMIN zum Anwenden des Bin-Protokolls verfügen.

    • Stellen Sie sicher, dass der Benutzer die REPLICATION REPLICA Berechtigung auf dem Zielserver hat.

    • Stellen Sie sicher, dass der Benutzer über die Berechtigungen REPLICATION CLIENT und REPLICATION REPLICA auf dem Quellserver zum Lesen und Anwenden des Bin-Protokolls verfügt.

    • Um Tabellen für das Ziel zu erstellen, muss der Benutzer über die CREATE Berechtigung verfügen.

    • Wenn Sie eine Tabelle mit DATA DIRECTORY oder INDEX DIRECTORY Partitionsoptionen migrieren, muss der Benutzer über die FILE Berechtigung verfügen.

    • Wenn Sie eine Tabelle mit einer UNION-Option migrieren, muss der Benutzer über die SELECTBerechtigungen UPDATE und DELETE für die Tabellen verfügen, die Sie einer MERGE-Tabelle zuordnen.

    • Wenn Sie Sichten migrieren, benötigen Sie die Berechtigung CREATE VIEW.

    Beachten Sie, dass je nach Inhalt der Sichten bestimmte Berechtigungen erforderlich sein können. Ausführliche Informationen finden Sie in den MySQL-Dokumenten, die für Ihre Version CREATE VIEW STATEMENT spezifisch sind.

    • Wenn Ereignisse migriert werden, muss der Benutzer über die EVENT Berechtigung verfügen.
    • Bei der Migration von Triggern muss der Benutzer über die TRIGGER Berechtigung verfügen.
    • Wenn Routinen migriert werden, muss der Benutzer über die CREATE ROUTINE Berechtigung verfügen.

  • Konfigurieren Sie die Serverparameter auf dem flexiblen Zielserver wie folgt:

    • Legen Sie die Serverparameter für die TLS-Version und „require_secure_transport“ so fest, dass sie mit den Werten auf dem Quellserver übereinstimmen.

    • Legen Sie den Serverparameter „sql_mode“ so fest, dass er mit dem Werten auf dem Quellserver übereinstimmt.

    • Konfigurieren Sie die Serverparameter auf dem Zielserver so, dass sie mit den auf dem Quellserver verwendeten Werten übereinstimmen, die nicht den Standardwerten entsprechen.

    • Um ein schnelleres Laden der Daten zu gewährleisten, wenn Sie DMS verwenden, konfigurieren Sie die folgenden Serverparameter wie beschrieben.

      • max_allowed_packet – auf 1073741824 (d. h. 1 GB) festgelegt, um Verbindungsprobleme aufgrund großer Zeilen zu verhindern.

      • slow_query_log – auf OFF setzen, um das langsame Abfrageprotokoll zu deaktivieren. Dadurch wird der Aufwand beseitigt, der durch die langsame Abfrageprotokollierung beim Laden von Daten verursacht wird.

      • innodb_buffer_pool_size – kann nur durch Erhöhung der Rechenleistung für den Azure-Datenbankserver für MySQL erhöht werden. Skalieren Sie den Server im Portal auf der Tarifseite während der Migration auf die SKU „Universell“ mit 64 virtuellen Kernen hoch, um innodb_buffer_pool_size zu erhöhen.

      • innodb_io_capacity und innodb_io_capacity_max – Ändern Sie die Serverparameter im Azure-Portal auf 9000, um die E/A-Nutzung zu verbessern und die Migrationsgeschwindigkeit zu optimieren.

      • innodb_write_io_threads – Wechseln Sie zu 4 aus den Serverparametern im Azure-Portal, um die Geschwindigkeit der Migration zu verbessern.

  • Konfigurieren Sie die Replikate auf dem Zielserver so, dass sie den Replikaten auf dem Quellserver entsprechen.

Einrichten von DMS

Nachdem Ihr zielflexibler Server bereitgestellt und konfiguriert wurde, müssen Sie als Nächstes DMS einrichten, um Ihren Quell-MySQL-Server auf einen flexiblen Server zu migrieren.

Registrieren des Ressourcenanbieters

Führen Sie die folgenden Schritte aus, um den Microsoft.DataMigration-Ressourcenanbieter zu registrieren.

1. Bevor Sie Ihre erste DMS-Instanz erstellen, melden Sie sich am Azure-Portal an, suchen Sie nach Abonnements und wählen Sie diese aus.

   

2. Wählen Sie das Abonnement aus, das Sie zum Erstellen der DMS-Instanz verwenden möchten, und wählen Sie dann Ressourcenanbieter aus.

   

3. Suchen Sie nach dem Begriff „Migration“, und wählen Sie dann für Microsoft.DataMigration die Option Registrieren aus.

   

Erstellen einer DMS-Instanz (Database Migration Service)

1. Wählen Sie im Azure-Portal die Option + Ressource erstellen aus, suchen Sie nach „Azure Database Migration Service“, und wählen Sie dann Azure Database Migration Service aus der Dropdownliste aus.

   Screenshot der Suche im Azure Database Migration Service.

2. Wählen Sie auf dem Bildschirm Azure Database Migration Service die Schaltfläche Erstellen aus.

   

3. Wählen Sie auf der Seite Wählen Sie das Migrationsszenario und den Datenbankmigrationsdienst aus unter Migrationsszenario die Option MySQL als Quellservertyp, anschließend Azure Database for MySQL als Zielservertyp und dann Auswählen aus.

   

4. Wählen Sie auf der Seite Migrationsdienst erstellen auf der Registerkarte Grundlagen unter Projektdetails das entsprechende Abonnement und dann eine bestehende Ressourcengruppe aus oder erstellen Sie eine neue.

5. Geben Sie unter Instanzdetails einen Namen für den Dienst an, wählen Sie eine Region aus und stellen Sie sicher, dass Azure als Dienstmodus ausgewählt ist.

6. Wählen Sie rechts von Tarif die Option Tarif konfigurieren aus.

   

7. Wählen Sie auf der Seite Konfigurieren den Tarif Premium mit 4 virtuellen Kernen für Ihre DMS-Instanz und dann Übernehmen aus.

   DMS Premium 4-vCore ist für sechs Monate (183 Tage) ab dem Erstellungsdatum des DMS-Dienstes kostenlos, bevor Gebühren anfallen. Weitere Informationen zu DMS-Kosten und Tarifen finden Sie in der Preisübersicht.

   

   Als Nächstes müssen wir das virtuelle Netzwerk angeben, das die DMS-Instanz mit Zugriff auf den flexiblen Zielserver bereitstellt.

8. Wählen Sie auf der Seite " Migrationsdienst erstellen " die Option "Weiter: Netzwerk >>" aus.

9. Wählen Sie auf der Registerkarte " Netzwerk " ein vorhandenes virtuelles Netzwerk aus der Liste aus, oder geben Sie den Namen des zu erstellenden neuen virtuellen Netzwerks an, und wählen Sie dann "Überprüfen+ Erstellen" aus.

   Weitere Informationen finden Sie im Artikel Erstellen eines virtuellen Netzwerks über das Azure-Portal.

   

   Ihr virtuelles Netzwerk muss mit Zugriff auf den Quell-MySQL-Server und den zielflexiblen Server konfiguriert werden. Achten Sie daher darauf:

   • Erstellen Sie eine Firewallregel auf Serverebene oder konfigurieren Sie das Netzwerk sowohl für den Quell-MySQL-Server als auch für die Azure-Datenbank für MySQL-Server, damit das virtuelle Netzwerk des Azure-Datenbankmigrationsdienstes auf die Quell- und Zieldatenbanken zugreifen kann.
   • Stellen Sie sicher, dass Ihre Regeln für die Netzwerksicherheitsgruppe (Virtual Network Security Group, NSG) den ausgehenden Port 443 von ServiceTag für ServiceBus, Storage und Azure Monitor nicht blockieren. Weitere Informationen zur NSG-Datenverkehrsfilterung für virtuelle Netzwerke finden Sie unter Filtern des Netzwerkdatenverkehrs mit Netzwerksicherheitsgruppen.

   Hinweis

   Um dem Dienst Tags hinzuzufügen, wechseln Sie zur Registerkarte "Kategorien ", indem Sie "Weiter: Tags" auswählen. Das Hinzufügen von Tags zum Dienst ist optional.

10. Navigieren Sie zur Registerkarte Überprüfen und erstellen, überprüfen Sie die Konfigurationen, sehen Sie sich die Begriffe an, und wählen Sie dann Erstellen aus.

    

    Die Bereitstellung Ihrer DMS-Instanz beginnt jetzt. Die Meldung Bereitstellung wird durchgeführt wird für einige Minuten angezeigt, dann ändert sich die Meldung in Ihre Bereitstellung ist abgeschlossen.

11. Wählen Sie Zu Ressource wechseln aus.

    

12. Identifizieren Sie die IP-Adresse der DMS-Instanz auf der Ressourcenübersichtsseite, und erstellen Sie eine Firewallregel für Ihren MySQL-Quellserver und flexiblen Zielserver, die die IP-Adresse der DMS-Instanz zulässt.

Erstellen eines Migrationsprojekts

Führen Sie die folgenden Schritte aus, um ein Migrationsprojekt zu erstellen.

1. Wählen Sie im Azure-Portal Alle Dienste, suchen Sie nach Azure Database Migration Service, und wählen Sie dann Azure Database Migration Service aus.

   

2. Wählen Sie in den Suchergebnissen die DMS-Instanz aus, die Sie erstellt haben, und wählen Sie dann + Neues Migrationsprojekt aus.

   

3. Geben Sie auf der Seite Neues Migrationsprojekt einen Namen für das Projekt an, wählen Sie im Auswahlfeld Quellservertyp die Option MySQL, im Auswahlfeld Zielservertyp die Option Azure Database for MySQL – Flexibler Server und dann im Auswahlfeld Migrationsaktivitätstyp die Option Onlinedatenmigration aus. Abschließend wählen Sie die Option Aktivität erstellen und ausführen aus.

   Wenn Sie "Projekt erstellen" nur als Migrationsaktivitätstyp auswählen, wird das Migrationsprojekt erstellt. Sie können das Migrationsprojekt zu einem späteren Zeitpunkt ausführen.

   

Konfigurieren des Migrationsprojekts

Führen Sie die folgenden Schritte aus, um Ihr DMS-Migrationsprojekt zu konfigurieren.

1. Auf dem Bildschirm "Quelle auswählen " müssen wir sicherstellen, dass sich DMS im virtuellen Netzwerk befindet, das über eine Verbindung mit dem Quellserver verfügt. Hier geben Sie den Quellservernamen, den Serverport, den Benutzernamen und das Kennwort für Ihren Quellserver ein.

   

2. Wählen Sie "Weiter" aus. Wählen Sie "Ziel>>" aus, und suchen Sie dann auf dem Bildschirm "Ziel auswählen" den Server basierend auf dem Abonnement, standort und der Ressourcengruppe. Der Benutzername wird automatisch ausgefüllt. Geben Sie das Kennwort für den flexiblen Zielserver an.

   

3. Wählen Sie "Weiter" aus: Wählen Sie Datenbanken >>aus, und wählen Sie dann auf der Registerkarte "Datenbanken auswählen" unter "Servermigrationsoptionen" die Option "Alle zutreffenden Datenbanken migrieren" oder unter "Datenbanken auswählen" die Serverobjekte aus, die Sie migrieren möchten.

   Dort wird jetzt die Option Alle anwendbaren Datenbanken migrieren angezeigt. Wenn diese Option ausgewählt ist, werden alle vom Benutzer erstellten Datenbanken und Tabellen migriert. Da Azure Database for MySQL – Flexibler Server gemischte Groß- und Kleinschreibung von Datenbanken nicht unterstützt, werden Datenbanken mit gemischter Groß- und Kleinschreibung an der Quelle bei einer Onlinemigration nicht einbezogen.

   

4. Wählen Sie im Abschnitt "Datenbanken auswählen" unter "Quelldatenbank" die zu migrierenden Datenbanken aus.

   Die Nicht-Tabellenobjekte in den von Ihnen angegebenen Datenbanken werden migriert, während die elemente, die Sie nicht ausgewählt haben, übersprungen werden. Sie können nur die Quell- und Zieldatenbanken auswählen, deren Namen mit denen auf dem Quell- und Zielserver übereinstimmen.

   Wenn Sie eine Datenbank auf dem Quellserver auswählen, die auf dem Zielserver nicht vorhanden ist, wird sie auf dem Zielserver erstellt.

5. Wählen Sie "Weiter" aus: Wählen Sie Tabellen >> aus, um zur Registerkarte "Tabellen auswählen" zu navigieren.

   Bevor die Registerkarte aufgefüllt wird, ruft DMS die Tabellen aus den ausgewählten Datenbanken aus der Quelle und dem Ziel ab und bestimmt dann, ob die Tabelle vorhanden ist und Daten enthält.

6. Wählen Sie die Tabellen aus, die Sie migrieren möchten.

   Wenn die ausgewählte Quelltabelle auf dem Zielserver nicht vorhanden ist, stellt der Onlinemigrationsprozess sicher, dass das Tabellenschema und die Daten auf den Zielserver migriert werden.

   

   DMS überprüft Ihre Eingaben, und wenn die Überprüfung erfolgreich ist, können Sie die Migration starten.

7. Wählen Sie nach der Konfiguration für die Schemamigration die Option Migration überprüfen und starten aus.

   Sie müssen nur zur Registerkarte Migrationseinstellungen konfigurieren navigieren, wenn Sie versuchen, Probleme mit fehlerhaften Migrationen zu beheben.

8. Geben Sie auf der Registerkarte Zusammenfassung im Textfeld Aktivitätsname einen Namen für die Migrationsaktivität ein, und überprüfen Sie anschließend die Zusammenfassung, um sicherzustellen, dass die Ziel- und Quelldetails Ihren vorherigen Angaben entsprechen.

   

9. Wählen Sie Migration starten aus.

   Das Fenster „Migrationsaktivität“ wird angezeigt, und der Status der Aktivität lautet „Wird initialisiert“. Der Status ändert sich in „Wird ausgeführt“, wenn die Tabellenmigration startet.

   

Überwachen der Migration

1. Wenn die Aktivität Anfängliches Laden abgeschlossen ist, navigieren Sie zur Registerkarte Anfängliches Laden, um den Abschlussstatus und die Anzahl der abgeschlossenen Tabellen anzuzeigen.

   

   Sobald die Aktivität Anfängliches Laden abgeschlossen ist, werden Sie automatisch zur Registerkarte Datenänderungen replizieren weitergeleitet. Sie können den Migrationsstatus überwachen, da der Bildschirm alle 30 Sekunden automatisch aktualisiert wird.

2. Wählen Sie Aktualisieren aus, um die Anzeige zu aktualisieren und bei Bedarf die Zeitverzögerung gegenüber der Quelle (in Sekunden) anzuzeigen.

   

3. Überwachen Sie den Wert für Sekunden hinter Quelle. Wenn er sich dem Wert 0 nähert, starten Sie den Cutover, indem Sie oben auf dem Bildschirm der Migrationsaktivität auf die Menüregisterkarte Cutover starten klicken.

4. Folgen Sie den Schritten im Cutover-Fenster, bis Sie bereit sind, einen Cutover durchzuführen.

5. Wählen Sie nach Abschluss aller Schritte die Option Bestätigen und dann Übernehmen aus.

   

Durchführen von Aktivitäten nach der Migration

Wenn die Migration abgeschlossen ist, führen Sie die folgenden Aktivitäten nach der Migration aus.

• Testen Sie zur Zertifizierung der Migration die Integrität der Anwendung mit der Zieldatenbank.

• Aktualisieren Sie die Verbindungszeichenfolge, um auf den neuen flexiblen Server zu verweisen.

• Wenn Sie den flexiblen Zielserver für eine schnellere Migration hochskaliert haben, skalieren Sie ihn zurück, indem Sie die Rechengröße und die Rechenebene für den flexiblen Server basierend auf der Konfiguration des MySQL-Quellservers auswählen.

  • Führen Sie die folgenden Schritte aus, um die DMS-Ressourcen zu bereinigen:

    1. Wählen Sie im Azure-Portal Alle Dienste, suchen Sie nach Azure Database Migration Service, und wählen Sie dann Azure Database Migration Service aus.

    2. Wählen Sie in den Suchergebnissen Ihre Migrationsdienstinstanz und anschließend Dienst löschen aus.

    3. Geben Sie im Bestätigungsdialogfeld im Textfeld DATABASE MIGRATION SERVICE-NAME EINGEBEN den Namen der Instanz an, und wählen Sie dann Löschen aus.

Bewährte Methoden für die Migration

Wenn Sie eine Migration durchführen, sollten Sie die folgenden bewährten Methoden beachten.

• Im Rahmen der Erkundung und Bewertung sollten Sie die SKU des Servers, die CPU-Auslastung, den Speicherplatz, die Datenbankgrößen und die Nutzung von Erweiterungen als einige der wichtigsten Daten für die Migration betrachten.

• Führen Sie Testmigrationen vor der Migration für die Produktion aus:

  • Testmigrationen sind wichtig, um sicherzustellen, dass alle Aspekte der Datenbankmigration abgedeckt werden, einschließlich Anwendungstests. Die bewährte Methode besteht darin, eine Migration vollständig für Testzwecke auszuführen. Nachdem eine neu gestartete Migration mit minimaler Verzögerung in die Phase „Datenänderungen replizieren“ eintritt, verwenden Sie Ihr Flexible Server-Ziel nur noch zum Ausführen von Testworkloads. Verwenden Sie dieses Ziel zum Testen der Anwendung, um die gewünschte Leistung und die erwarteten Ergebnisse sicherzustellen. Testen Sie bei einer Migration zu einer höheren MySQL-Version die Anwendungskompatibilität.

  • Nach Abschluss des Tests können Sie die Produktionsdatenbanken migrieren. An diesem Punkt müssen Sie den Tag und die Uhrzeit der Produktionsmigration endgültig festlegen. Idealerweise wird die Anwendung zu diesem Zeitpunkt nur wenig genutzt. Alle Beteiligten, die einbezogen werden müssen, sollten verfügbar und bereit sein. Die Produktionsmigration erfordert eine sorgfältige Überwachung. Bei einer Onlinemigration muss die Replikation beendet worden sein, bevor Sie der Cutovervorgang ausgeführt wird, um Datenverlust zu verhindern.

• Leiten Sie alle abhängigen Anwendungen um, sodass sie auf die neue primäre Datenbank zugreifen, und legen Sie den Quellserver als schreibgeschützt fest. Öffnen Sie dann die Anwendungen für den Einsatz in der Produktion.

• Nachdem die Anwendung auf dem flexiblen Zielserver ausgeführt wurde, überwachen Sie die Leistung der Datenbank genau, um festzustellen, ob eine Leistungsoptimierung erforderlich ist.

Verwandte Inhalte

• Was ist Azure Database for MySQL – Flexibler Server?
• Was ist Azure Database Migration Service?
• Bekannte Probleme bei der Migration zu Azure Database for MySQL
• Problembehandlung häufig auftretender Probleme und Fehler bei Azure Database Migration Service (klassisch)
• Troubleshoot DMS errors when connecting to source databases (Beheben von DMS-Fehlern beim Herstellen der Verbindung mit Quelldatenbanken)