Migrieren von Azure Database for MySQL – Einzelserver zu Azure Database for MySQL – flexibler Server mit Open-Source-Tools

  • Artikel

Sie können eine Instanz von Azure Database for MySQL – Einzelserver zu Azure Database for MySQL – flexibler Server mit minimaler Ausfallzeit für Ihre Anwendungen migrieren, indem Sie eine Kombination aus Open-Source-Tools wie mydumper/myloader und Datenreplikation nutzen.

Hinweis

Dieser Artikel enthält Verweise auf den Begriff Slave, einen Begriff, den Microsoft nicht mehr verwendet. Sobald der Begriff aus der Software entfernt wurde, wird er auch aus diesem Artikel entfernt.

Die Datenreplikation ist ein Verfahren, bei dem basierend auf der position-Methode für binäre Protokolldateien Datenänderungen vom Quellserver auf den Zielserver repliziert werden. In diesem Szenario schreibt die MySQL-Instanz, die als Quelle fungiert (und von der die Datenbankänderungen stammen), Aktualisierungen und Änderungen als „Ereignisse“ in das binäre Protokoll. Die Informationen im binären Protokoll werden je nach aufgezeichneten Datenbankänderungen in unterschiedlichen Protokollierungsformaten gespeichert. Replikate sind so konfiguriert, dass sie das binäre Protokoll aus der Quelle lesen und die Ereignisse im binären Protokoll in der lokalen Datenbank des Replikats ausführen.

Wenn Sie die Datenreplikation einrichten, um Daten aus einer Azure Database for MySQL-Instanz mit einer anderen zu synchronisieren, können Sie eine selektive Übernahme Ihrer Anwendungen vom primären Server (oder Quelldatenbank) auf den Replikatserver (oder die Zieldatenbank) durchführen.

In diesem Tutorial verwenden Sie mydumper/myloader und Datenreplikation zum Migrieren einer Beispieldatenbank (classicmodels) aus einer Instanz von Azure Database for MySQL – Einzelserver zu einer Instanz von Azure Database for MySQL – flexibler Server. Anschließend synchronisieren Sie die Daten.

In diesem Tutorial lernen Sie Folgendes:

  • Konfigurieren der Netzwerkeinstellungen für die Datenreplikation für verschiedene Szenarios
  • Konfigurieren der Datenreplikation zwischen dem primären Server und dem Replikatserver
  • Testen der Replikation
  • Übernahme zum Abschließen der Migration

Voraussetzungen

Für dieses Tutorial benötigen Sie Folgendes:

  • Eine Instanz von Azure Database for MySQL Single Server mit Version 5.7 oder 8.0

    Hinweis

    Wenn Sie Azure Database for MySQL Single Server Version 5.6 nutzen, führen Sie für Ihre Instanz ein Upgrade auf Version 5.7 durch, und konfigurieren Sie dann die Datenreplikation. Weitere Informationen finden Sie unter Hauptversionsupgrade in Azure Database for MySQL Single Server.

  • Eine Instanz von Azure Database for MySQL Flexible Server. Weitere Informationen finden Sie im Artikel Schnellstart: Verwenden des Azure-Portals zum Erstellen einer Azure Database for MySQL Flexible Server-Instanz.

    Hinweis

    Die Konfiguration der Datenreplikation für Server mit zonenredundanter Hochverfügbarkeit wird nicht unterstützt. Führen Sie die folgenden Schritte aus, wenn Sie zonenredundante Hochverfügbarkeit für Ihren Zielserver möchten:

    1. Server mit aktivierter zonenredundanter Hochverfügbarkeit erstellen
    2. Hochverfügbarkeit deaktivieren
    3. Anweisungen im Artikel zum Einrichten der Datenreplikation befolgen
    4. Konfiguration der Datenreplikation nach der Übernahme entfernen
    5. Hochverfügbarkeit aktivieren

    Stellen Sie sicher, dass GTID_Mode auf den Quell- und Zielservern über die gleiche Einstellung verfügt.

  • Herstellen einer Verbindung und Erstellen einer Datenbank mithilfe von MySQL Workbench. Weitere Informationen finden Sie im Artikel Schnellstart: Verwenden von MySQL Workbench zum Herstellen einer Verbindung und zum Abfragen von Daten in Azure Database for MySQL – Flexible Server.

  • Sicherstellen, dass Sie in derselben Region (oder im gleichen VNet mit privatem Zugriff) über eine Azure-VM verfügen, auf der Linux ausgeführt wird und die Ihre Quell- und Zieldatenbanken hostet

  • Installieren des mysql-Clients oder von MySQL Workbench (Clienttools) auf Ihrer Azure-VM. Stellen Sie sicher, dass Sie sowohl mit dem primären Server als auch dem Replikatserver eine Verbindung herstellen können. Im Rahmen dieses Artikels wird der MySQL-Client installiert.

  • Installieren von mydumper/myloader auf Ihrer Azure-VM. Weitere Informationen finden Sie im Artikel zu mydumper/myloader.

  • Herunterladen und Ausführen des Beispieldatenbankskripts für die classicmodels-Datenbank auf dem Quellserver

  • Konfigurieren Sie binlog_expire_logs_seconds auf dem Quellserver, um sicherzustellen, dass Binärprotokolle nicht bereinigt werden, bevor das Replikat die Änderungen committet. Nach einem erfolgreichen Umstieg können Sie den Wert zurücksetzen.

Konfigurieren von Netzwerkanforderungen

Sie müssen zum Konfigurieren der Datenreplikation sicherstellen, dass das Ziel über Port 3306 eine Verbindung mit der Quelle herstellen kann. Führen Sie basierend auf dem Typ des in der Quelle eingerichteten Endpunkts die entsprechenden folgenden Schritte aus.

Konfigurieren der Datenreplikation

Führen Sie die folgenden Schritte aus, um die Datenreplikation zu konfigurieren:

  1. Melden Sie sich bei der Azure-VM an, auf der Sie das mysql-Clienttool installiert haben.

  2. Stellen Sie mithilfe des mysql-Clienttools eine Verbindung zwischen Quelle und Ziel her.

  3. Verwenden Sie das mysql-Clienttool, um zu bestimmen, ob log_bin für die Quelle aktiviert ist, indem Sie den folgenden Befehl ausführen:

    SHOW VARIABLES LIKE 'log_bin';

    Hinweis

    Im Fall von Azure Database for MySQL Single Server mit dem großen Speicher, der bis zu 16 TB unterstützt, ist diese Option standardmäßig aktiviert.

    Tipp

    Bei Azure Database for MySQL Single Server mit Unterstützung für bis zu 4 TB ist die Option nicht standardmäßig aktiviert. Wenn Sie jedoch ein Lesereplikat für den Quellserver höher stufen und dann das Lesereplikat löschen, wird der Parameter auf „ON“ festgelegt.

  4. Erstellen Sie basierend auf der SSL-Erzwingung für den Quellserver einen Benutzer auf dem Quellserver mit der Replikationsberechtigung, indem Sie den entsprechenden Befehl ausführen.

    Führen Sie bei Verwendung von SSL den folgenden Befehl aus:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;

    Wenn Sie SSL nicht verwenden, führen Sie den folgenden Befehl aus:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

  5. Führen Sie zum Sichern der Datenbank mithilfe von mydumper den folgenden Befehl auf der Azure-VM aus, auf der mydumper\myloader installiert ist:

    mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<Password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl  --regex '^(classicmodels\.)' -L mydumper-logs.txt

    Tipp

    Die Option --trx-consistency-only ist für die Transaktionskonsistenz während der Sicherung erforderlich.

    • Dies ist das Äquivalent von mydumper für „--single-transaction“ von mysqldump.
    • Die Option ist nützlich, wenn es sich bei all Ihren Tabellen um InnoDB handelt.
    • Der Hauptthread muss die globale Sperre nur so lange speichern, bis die Sicherungsthreads eine Transaktion starten können.
    • Die Option bietet die kürzeste Dauer der globalen Sperre.

    Der Hauptthread muss die globale Sperre nur so lange speichern, bis die Sicherungsthreads eine Transaktion starten können.

    Die Variablen in diesem Befehl werden im Folgenden erläutert:

    HOW-TO-MANAGE-FIREWALL-PORTAL --host: Name des primären Servers

    • --user: Dies ist der Name eines Benutzers (im Format username@servername , da auf dem primären Server Azure Database for MySQL Single Server ausgeführt wird). Sie können den Serveradministrator oder einen Benutzer mit SELECT- und RELOAD-Berechtigungen verwenden.
    • --Password: Dies ist das Kennwort des zuvor genannten Benutzers.

    Weitere Informationen zur Verwendung von mydumper finden Sie im Artikel zu mydumper/myloader.

  6. Lesen Sie die Metadatendatei, um den Namen und Versatz der binären Protokolldatei zu ermitteln, indem Sie den folgenden Befehl ausführen:

    cat ./backup/metadata

    In diesem Befehl bezieht sich ./backup auf das Ausgabeverzeichnis, das im vorherigen Schritt im Befehl verwendet wurde.

    Die Ergebnisse sollten wie in der folgenden Abbildung dargestellt angezeigt werden:

    Continuous sync with the Azure Database Migration Service

    Notieren Sie sich unbedingt den Namen der Binärdatei für die nachfolgenden Schritte.

  7. Stellen Sie die Datenbank mithilfe von myloader wieder her, indem Sie den folgenden Befehl ausführen:

    myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<Password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txt

    Die Variablen in diesem Befehl werden im Folgenden erläutert:

    • --host: Dies ist der Name des Replikatservers
    • --user: Dies ist der Name eines Benutzers. Sie können den Serveradministrator oder einen Benutzer mit Lese- bzw. Schreibberechtigung verwenden, um die Schemas und Daten in der Datenbank wiederherzustellen.
    • --Password: Dies ist das Kennwort für den zuvor genannten Benutzer.

  8. Stellen Sie abhängig von der SSL-Erzwingung auf dem primären Server mithilfe des mysql-Clienttools eine Verbindung mit dem Replikatserver her, und führen Sie die folgenden Schritte aus.

    • Wenn die SSL-Erzwingung aktiviert ist, gilt Folgendes:

      i. Laden Sie hier das Zertifikat herunter, das für die Kommunikation mit Ihrem Azure Database for MySQL-Server über SSL erforderlich ist.

      ii. Öffnen Sie die Datei in Editor, und fügen Sie den Inhalt in den Abschnitt „PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE“ ein.

      SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE
-----END CERTIFICATE-----'

      iii. Führen Sie zum Konfigurieren der Datenreplikation den folgenden Befehl aus:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, @cert);

      Hinweis

      Bestimmen Sie die Position und den Dateinamen anhand der Informationen, die Sie in Schritt 6 erhalten haben.

    • Wenn die SSL-Erzwingung nicht aktiviert ist, führen Sie den folgenden Befehl aus:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, ‘’);

  9. Rufen Sie die unten aufgeführte gespeicherte Prozedur auf, um die Replikation vom Replikatserver aus zu starten.

    call  mysql.az_replication_start;

  10. Führen Sie auf dem Replikatserver den folgenden Befehl aus, um den Replikationsstatus zu überprüfen:

    show slave status \G;

    Hinweis

    Wenn Sie MySQL Workbench verwenden, ist der \G-Modifizierer nicht erforderlich.

    Wenn der Status von Slave_IO_Running und Slave_SQL_Running „Yes“ (Ja) lautet und der Wert von Seconds_Behind_Master 0 entspricht, funktioniert die Replikation problemlos. Seconds_Behind_Master gibt an, welche Verzögerung das Replikat aufweist. Wenn der Wert nicht 0 ist, verarbeitet das Replikat Updates.

Testen der Replikation (optional)

Sie können überprüfen, ob die Änderungen an den Tabellen auf dem primären Server in das Replikat repliziert wurden, um sicherzustellen, dass die Datenreplikation ordnungsgemäß funktioniert.

  1. Wählen Sie eine Tabelle aus, die zum Testen verwendet werden soll (z. B. die Customers-Tabelle), und vergewissern Sie sich dann, dass die Anzahl der darin enthaltenen Einträge auf dem primären Server und dem Replikatserver identisch ist, indem Sie auf jedem Server den folgenden Befehl ausführen:

    select count(*) from customers;

  2. Notieren Sie sich die Anzahl der Einträge für einen späteren Vergleich.

    Versuchen Sie zum Testen der Replikation, den customers-Tabellen auf dem primären Server einige Daten hinzuzufügen, und überprüfen Sie dann, ob die neuen Daten repliziert werden. In diesem Fall fügen Sie einer Tabelle auf dem primären Server zwei Zeilen hinzu und überprüfen dann, ob sie auf den Replikatserver repliziert wurden.

  3. Fügen Sie in der customers-Tabelle auf dem primären Server Zeilen ein, indem Sie den folgenden Befehl ausführen:

    insert  into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values
(<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');

  4. Rufen Sie zum Überprüfen des Replikationsstatus show slave status \G auf, um zu bestätigen, dass die Replikation wie erwartet durchgeführt wird.

  5. Führen Sie auf dem Replikatserver den folgenden Befehl aus, um zu bestätigen, dass die Anzahl identisch ist:

    select count(*) from customers;

Sicherstellen einer erfolgreichen Übernahme

Führen Sie die folgenden Aufgaben aus, um eine erfolgreiche Übernahme sicherzustellen:

  1. Konfigurieren Sie die entsprechenden Firewallregeln und VNET-Regeln auf Serverebene, um eine Verbindung mit dem Zielserver herzustellen. Sie können die Firewallregeln für die Quelle und das Ziel über das Portal vergleichen.
  2. Konfigurieren Sie die entsprechenden Anmeldedaten und Berechtigungen auf Datenbankebene auf dem Zielserver. Sie können zum Vergleich SELECT FROM mysql.user; auf dem Quell- und Zielserver ausführen.
  3. Stellen Sie sicher, dass alle eingehenden Verbindungen mit Azure Database for MySQL Single Server beendet werden.

    Tipp

    Sie können für Azure Database for MySQL Single Server den schreibgeschützten Zugriff festlegen.

  4. Stellen Sie sicher, dass die Vorgänge auf dem primären Server und dem Replikatserver ohne Zeitverzögerung ausgeführt werden, indem Sie show slave status \G ausführen und bestätigen, dass der Wert für den Parameter Seconds_Behind_Master 0 lautet.
  5. Leiten Sie Clients und Clientanwendungen an die Zielinstanz von Azure Database for MySQL Flexible Server um.
  6. Führen Sie die letzte Übernahme durch, indem Sie die gespeicherte Prozedur „mysql.az_replication_stop“ ausführen, die die Replikation vom Replikatserver beendet.
  7. Verwenden Sie Call mysql.az_replication_remove_master, um die Konfiguration für die Datenreplikation zu entfernen.

An diesem Punkt sind Ihre Anwendungen mit der neuen Instanz von Azure Database for MySQL Flexible Server verbunden, und Änderungen in der Quelle werden nicht mehr auf den Zielserver repliziert. Erstellen und Verwalten von Firewallregeln für Azure Database for MySQL mithilfe des Azure-Portals

Nächste Schritte