Migrieren einer lokalen oder VM-basierten MySQL-Workload zu Azure Database for MySQL mithilfe der Azure Database for MySQL-Import-CLI
Mit der Import-CLI von Azure Database for MySQL für externe Migrationen können Sie Ihre lokale oder VM-basierte MySQL-Workload nahtlos zu Azure Database for MySQL – Flexibler Server migrieren. Es wird eine benutzerseitig bereitgestellte physische Sicherungsdatei verwendet, und die physischen Datendateien des Quellservers werden auf dem Zielserver wiederhergestellt. Somit wird ein einfacher und schneller Migrationspfad bereitgestellt. Nach dem Importvorgang können Sie die Vorteile eines flexiblen Servers nutzen. Hierzu gehören besserer Preise und bessere Leistung, eine präzise Steuerung über die Datenbankkonfiguration und benutzerdefinierte Wartungsfenster.
Auf der Grundlage von Benutzereingaben übernimmt das Feature die Verantwortung für die Bereitstellung Ihres flexiblen Zielservers und die anschließende Wiederherstellung des benutzerseitig bereitgestellten physischen Backups des Quellservers, das im Azure Blob Storage-Konto gespeichert ist, in der Zielinstanz des flexiblen Servers.
In diesem Tutorial wird gezeigt, wie Sie den Befehl der Azure Database for MySQL-Import-CLI verwenden, um eine lokale oder VM-basierte MySQL-Workload zu Azure Database for MySQL – Flexibler Server migrieren.
Starten von Azure Cloud Shell
Azure Cloud Shell ist eine kostenlose interaktive Shell, mit der Sie die Schritte in diesem Artikel durchführen können. Sie verfügt über allgemeine vorinstallierte Tools und ist für die Verwendung mit Ihrem Konto konfiguriert.
Wählen Sie zum Öffnen von Cloud Shell oben rechts in einem Codeblock die Option Ausprobieren aus. Sie können Cloud Shell auch auf einer separaten Browserregisterkarte öffnen, indem Sie zu https://shell.azure.com/bash navigieren. Wählen Sie Kopieren aus, um die Codeblöcke zu kopieren. Fügen Sie die Blöcke anschließend in Cloud Shell ein, und wählen Sie Eingabe, um sie auszuführen.
Wenn Sie die Befehlszeilenschnittstelle lieber lokal installieren und verwenden möchten, benötigen Sie für dieses Tutorial die Azure CLI-Version 2.54.0 oder höher. Führen Sie az --version aus, um die Version zu finden. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.
Einstellung
Sie müssen sich mit dem Befehl az sign-in bei Ihrem Konto anmelden. Beachten Sie die Eigenschaft ID, die auf die Abonnement-ID Ihres Azure-Kontos verweist.
az login
Wählen Sie mithilfe des Befehls az account set das entsprechende Abonnement unter Ihrem Konto aus, in dem Sie den flexiblen Zielserver bereitstellen möchten. Notieren Sie aus der Ausgabe von az login den Wert für ID, um ihn im Befehl als Wert für das Argument subscription zu verwenden. Verwenden Sie az account list, um alle Abonnements abzurufen.
az account set --subscription <subscription id>
Voraussetzungen
Der Quellserver sollte über die folgenden Parameter verfügen:
- Lower_case_table_names = 1
- Innodb_file_per_table = ON
- Der Name des Systemtabellenbereichs muss „ibdata1“ lauten.
- Die Größe des Systemtabellenbereichs muss größer oder gleich 12 MB sein. (MySQL-Standardwert)
- Innodb_page_size = 16348 (MySQL-Standardwert)
- Nur die INNODB-Engine wird unterstützt.
Nehmen Sie mithilfe von Percona XtraBackup eine physische Sicherung Ihrer MySQL-Workload vor. Im Folgenden sind die Schritte für die Verwendung von Percona XtraBackup zum Erstellen einer vollständigen Sicherung aufgeführt:
Installieren Sie Percona XtraBackup auf der lokalen oder VM-Workload. Installieren Sie für die MySQL-Modulversion v5.7 Percona XtraBackup, Version 2.4, siehe Installieren von Percona XtraBackup 2.4. Installieren Sie für die MySQL-Modulversion v8.0 Percona XtraBackup, Version 8.0, siehe Installieren von Percona XtraBackup 8.0.
Anweisungen zum Erstellen einer vollständigen Sicherung mit Percona XtraBackup 2.4 finden Sie unter Vollständige Sicherung. Anweisungen zum Erstellen einer vollständigen Sicherung mit Percona XtraBackup 8.0 finden Sie unter [Vollständige Sicherung] (https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html). Führen Sie während der vollständigen Sicherung die folgenden Befehle in der folgenden Reihenfolge aus:
- ** xtrabackup --backup --host={host} --user={user} --password={password} --target-dir={backup__dir_path}**
- ** xtrabackup --prepare --{backup_dir_path}** (Geben Sie hier den gleichen Sicherungspfad wie im vorherigen Befehl an.)
Überlegungen beim Verwenden von Percona XtraBackup:
- Stellen Sie sicher, dass Sie sowohl den Sicherungs- als auch den Vorbereitungsschritt ausführen.
- Stellen Sie sicher, dass keine Fehler im Sicherungs- und Vorbereitungsschritt vorhanden sind.
- Bewahren Sie die Sicherung auf, und bereiten Sie Schrittprotokolle für den Azure-Support vor, die im Fall von Fehlern benötigt werden.
Wichtig
Der Versuch, auf beschädigte Tabellen zuzugreifen, die von einem Quellserver importiert wurden, kann dazu führen, dass ein flexibler Server abstürzt. Daher wird dringend empfohlen, vor dem Erstellen einer Sicherung mit dem Hilfsprogramm Percona XtraBackup den Vorgang „mysqlcheck / Optimize Table“ auf dem Quellserver auszuführen.
Erstellen Sie einen Azure-Blobcontainer, und rufen Sie das SAS-Token (über das Azure-Portal oder die Azure CLI) für den Container ab. Erteilen Sie über die Dropdownliste Berechtigungen unbedingt die Berechtigungen „Hinzufügen“, „Erstellen“ und „Schreiben“. Kopieren Sie die Werte für das SAS-Token und die URL des Blobs, und fügen Sie sie an einem sicheren Ort ein. Diese Angaben werden nur einmal angezeigt und können nicht mehr abgerufen werden, nachdem das Fenster geschlossen wurde.
Laden Sie die Datei mit der vollständigen Sicherung unter {backup_dir_path} in Ihre Azure Blob Storage-Instanz hoch. Führen Sie die folgenden Schritte aus, um eine Datei hochzuladen.
Um eine Onlinemigration durchzuführen, erfassen und speichern Sie die Bin-Protokollposition der Sicherungsdatei, die mithilfe von Percona XtraBackup erstellt wurde. Führen Sie dazu den Befehl cat xtrabackup_info aus, und kopieren Sie die Positionsausgabe von „bin_log“.
Das Azure Storage-Konto sollte über das SAS-Token öffentlich zugänglich sein. Azure Storage-Konto mit VNET-Konfiguration wird nicht unterstützt.
Begrenzungen
- Die Quellserverkonfiguration wird nicht migriert. Sie müssen den flexiblen Zielserver entsprechend konfigurieren.
- Die Migration für verschlüsselte Sicherungen wird nicht unterstützt.
- Benutzer*innen und Berechtigungen werden nicht als Teil des Azure Database for MySQL-Imports migriert. Sie müssen eine manuelle Sicherungsdatei von Benutzer*innen und Berechtigungen erstellen, bevor Sie den Azure Database for MySQL-Import initiieren, um Anmeldungen nach dem Importvorgang zu migrieren, indem Sie sie auf dem flexiblen Zielserver wiederherstellen.
- user1@localhost kann nicht migriert werden, da die Erstellung von localhost-Benutzern in Flexibler Server nicht unterstützt wird.
- Flexible Server mit aktivierter Hochverfügbarkeit (High Availability, HA) werden als Server mit deaktivierter Hochverfügbarkeit zurückgegeben, um die Geschwindigkeit des Migrationsvorgangs nach der Importmigration zu erhöhen. Aktivieren Sie Hochverfügbarkeit für den flexiblen Zielserver nach der Migration.
Empfehlungen für eine optimale Migration
- Erwägen Sie, die Bereitstellung des Azure Blob Storage-Kontos und des flexiblen Zielservers in derselben Region beizubehalten, um eine bessere Importleistung zu erzielen.
- Empfohlene SKU-Konfiguration für die Zielinstanz von Azure Database for MySQL – Flexibler Server:
- Es wird nicht empfohlen, die SKU „Burstfähig“ für das Ziel festzulegen, um die Migrationszeit zu optimieren, wenn der Azure Database for MySQL-Importvorgang ausgeführt wird. Es wird empfohlen, die Skalierung auf „Universell“ oder „Unternehmenskritisch“ für den Importvorgang durchzuführen. Nach dem Import können Sie auf die SKU „Burstfähig“ herunterskalieren.
Auslösen eines Azure Database for MySQL-Importvorgangs zum Migrieren von Azure Database for MySQL – Flexibler Server
Lösen Sie mit dem az mysql flexible-server import create-Befehl einen Azure Database for MySQL-Importvorgang aus. Der folgende Befehl erstellt einen flexiblen Zielserver und führt den Import auf Instanzebene von der Sicherungsdatei zum Ziel mithilfe des lokalen Kontexts der Azure CLI aus:
az mysql flexible-server import create --data-source-type
--data-source
--data-source-sas-token
--resource-group
--name
--sku-name
--tier
--version
--location
[--data-source-backup-dir]
[--storage-size]
[--mode]
[--admin-password]
[--admin-user]
[--auto-scale-iops {Disabled, Enabled}]
[--backup-identity]
[--backup-key]
[--backup-retention]
[--database-name]
[--geo-redundant-backup {Disabled, Enabled}]
[--high-availability {Disabled, SameZone, ZoneRedundant}]
[--identity]
[--iops]
[--key]
[--private-dns-zone]
[--public-access]
[--resource-group]
[--standby-zone]
[--storage-auto-grow {Disabled, Enabled}]
[--subnet]
[--subnet-prefixes]
[--tags]
[--vnet]
[--zone]
The following example takes in the data source information for your source MySQL server's backup file and target Flexible Server information, creates a target Flexible Server named `test-flexible-server` in the `westus` location and performs an import from backup file to target.
azurecli-interactive
az mysql flexible-server import create --data-source-type "azure_blob" --data-source "https://onprembackup.blob.core.windows.net/onprembackup" --data-source-backup-dir "mysql_backup_percona" –-data-source-token "{sas-token}" --resource-group "test-rg" --name "test-flexible-server" –-sku-name Standard_D2ds_v4 --tier GeneralPurpose –-version 5.7 -–location "westus"
Hier sind die Details zu den obigen Argumenten aufgeführt:
| Einstellung | Beispielwert | Beschreibung |
|---|---|---|
| data-source-type | azure_blob | Der Typ der Datenquelle, die als Quellziel zum Auslösen des Azure Database for MySQL-Imports dient. Zulässige Werte: [azure_blob]. Beschreibung der zulässigen Werte: azure_blob: Azure Blob Storage |
| data-source | {resourceID} | Die Ressourcen-ID des Azure-Blobcontainers |
| data-source-backup-dir | mysql_percona_backup | Das Verzeichnis des Azure Blob Storage-Containers, in den die Sicherungsdatei hochgeladen wurde. Dieser Wert ist nur erforderlich, wenn die Sicherungsdatei nicht im Stammordner des Azure Blob-Containers gespeichert ist. |
| data-source-sas-token | {sas-token} | Das SAS-Token (Shared Access Signature), das generiert wird, um Zugriff auf den Import über den Azure Blob Storage-Container zu gewähren. |
| resource-group | test-rg | Der Name der Azure-Ressourcengruppe für die Zielinstanz von Azure Database for MySQL – Flexibler Server. |
| Modus | Offline | Der Modus des Azure Database for MySQL-Imports. Akzeptierte Werte: [Offline]; Standardwert: Offline. |
| location | westus | Der Azure-Standort für die Quellinstanz von Azure Database for MySQL – Flexible Server. |
| name | test-flexible-server | Geben Sie einen eindeutigen Namen für Ihre Azure Database for MySQL Flexible Server-Instanz ein. Der Servername darf nur Kleinbuchstaben, Zahlen und den Bindestrich (-) enthalten. Es muss zwischen drei und 63 Zeichen lang sein. Hinweis: Dieser Server wird in demselben Abonnement, derselben Ressourcengruppe und derselben Region wie die Quelle bereitgestellt. |
| admin-user | adminuser | Der Benutzername für die Administratoranmeldung für Ihr Azure Database for MySQL Flexible Server-Ziel. Dieser darf nicht azure_superuser, admin, administrator, root, guest oder public lauten. |
| admin-password | *password- | Das Administratorbenutzer-Kennwort für Ihr Azure Database for MySQL Flexible Server-Ziel. Es muss zwischen acht und 128 Zeichen lang sein. Ihr Kennwort muss Zeichen aus drei Kategorien enthalten: englische Großbuchstaben, englische Kleinbuchstaben, Zahlen und nicht alphanumerische Zeichen. |
| sku-name | GP_Gen5_2 | Geben Sie den Namen des Tarifs und der Computekonfiguration für Ihr Azure Database for MySQL Flexible Server-Ziel ein. Folgt der Konvention „{Tarif} {Computegeneration} {virtuelle Kerne}“ in Kurzform. Weitere Informationen hierzu finden Sie unter den Tarifen. |
| Ebene | Burstfähig | Computeebene des Azure Database for MySQL Flexible Server-Ziels. Akzeptierte Werte: Burstable, GeneralPurpose, MemoryOptimized; Standardwert: Burstable. |
| public-access | 0.0.0.0 | Bestimmt den öffentlichen Zugriff für das Azure Database for MySQL Flexible Server-Ziel. Geben Sie eine einzelne IP-Adresse oder einen IP-Adressbereich an, die/der in der Liste zulässiger IP-Adressen enthalten sein soll. Der IP-Adressbereich muss durch Bindestriche getrennt sein und darf keine Leerzeichen enthalten. Die Angabe von 0.0.0.0 ermöglicht den öffentlichen Zugriff von allen in Azure bereitgestellten Ressourcen auf Ihren Server. Wenn sie auf „Keine“ festgelegt wird, wird der Server im öffentlichen Zugriffsmodus festgelegt, aber es wird keine Firewallregel erstellt. |
| Virtuelles Netzwerk | myVnet | Name oder ID eines neuen oder vorhandenen virtuellen Netzwerks. Wenn Sie ein VNet aus einer anderen Ressourcengruppe oder einem anderen Abonnement verwenden möchten, geben Sie eine Ressourcen-ID an. Der Name muss zwischen 2 und 64 Zeichen lang sein. Der Name muss mit einem Buchstaben oder einer Ziffer beginnen, auf einen Buchstaben, eine Ziffer oder einen Unterstrich enden und darf nur Buchstaben, Ziffern, Unterstriche, Punkte und Bindestriche enthalten. |
| subnet | mySubnet | Name oder Ressourcen-ID eines neuen oder vorhandenen Subnetzes. Wenn Sie ein Subnetz aus einer anderen Ressourcengruppe oder einem anderen Abonnement verwenden möchten, geben Sie anstelle des Namens die Ressourcen-ID an. Das Subnetz wird an flexibleServers delegiert. Nach der Delegierung kann dieses Subnetz nicht für andere Typen von Azure-Ressourcen verwendet werden. |
| private-dns-zone | myserver.private.contoso.com | Der Name oder die ID der neuen oder vorhandenen privaten DNS-Zone. Sie können die private DNS-Zone aus derselben Ressourcengruppe, einer anderen Ressourcengruppe oder einem anderen Abonnement verwenden. Wenn Sie eine Zone aus einer anderen Ressourcengruppe oder einem anderen Abonnement verwenden möchten, geben Sie eine Ressourcen-ID an. Die CLI erstellt eine neue private DNS-Zone innerhalb derselben Ressourcengruppe, in der sich auch das virtuelle Netzwerk befindet, wenn sie nicht von Benutzer*innen bereitgestellt wird. |
| Schlüssel | Schlüsselbezeichner von testKey | Die Ressourcen-ID des primären Schlüsseltresors für die Datenverschlüsselung. |
| identity | testidentity | Der Name oder die Ressourcen-ID der vom Benutzer zugewiesenen Identität für die Datenverschlüsselung. |
| storage-size | 32 | Die Speicherkapazität des Azure Database for MySQL Flexible Server-Ziels. Der Mindestwert beträgt 20 GiB, der Höchstwert 16 TiB. |
| tags | key=value | Geben Sie den Namen der Azure-Ressourcengruppe an. |
| version | 5.7 | Serverhauptversion des Azure Database for MySQL Flexible Server-Ziels. |
| Hochverfügbarkeit | ZoneRedundant | Aktivieren (ZoneRedundant oder SameZone) oder deaktivieren Sie die Hochverfügbarkeitsfunktion für das Azure Database for MySQL Flexible Server-Ziel. Akzeptierte Werte: Disabled, SameZone, ZoneRedundant; Standardwert: Disabled. |
| Zone | 1 | Verfügbarkeitszone, in der die Ressource bereitgestellt werden soll. |
| standby-zone | 3 | Die Verfügbarkeitszoneninformationen des Standbyservers, wenn Hochverfügbarkeit aktiviert ist. |
| storage-auto-grow | Aktiviert | Aktivieren oder deaktivieren Sie das automatische Speicherwachstum für das Azure Database for MySQL Flexible Server-Ziel. Der Standardwert ist „Enabled“. Akzeptierte Werte: Disabled, Enabled; Standardwert: Enabled. |
| iops | 500 | Anzahl der IOPS, die für das Azure Database for MySQL Flexible Server-Ziel zugeordnet werden sollen. Sie erhalten eine bestimmte Menge an kostenlosen IOPS basierend auf der Compute- und Speicherbereitstellung. Der Standardwert für IOPS sind kostenlose IOPS. Weitere Informationen zu IOPS basierend auf Compute und Speicher finden Sie unter „IOPS in Azure Database for MySQL Flexible Server“. |
Migration zu Flexibler Server mit minimaler Downtime
Um eine Onlinemigration nach Abschluss des anfänglichen Seedings aus der Sicherungsdatei mithilfe des Azure Database for MySQL-Imports durchzuführen, können Sie die Datenreplikation zwischen Quelle und Ziel mit diesen Schritten konfigurieren. Sie können die Bin-Protokollposition verwenden, die beim Erstellen der Sicherungsdatei mithilfe von Percona XtraBackup erfasst wird, um die auf der Bin-Protokollposition basierende Replikation einzurichten.
Wie lange dauert es, bis der Azure Database for MySQL-Import meine SQL-Instanz migriert hat?
Benchmarkleistung basierend auf der Speichergröße
| Speichergröße für Sicherungsdatei | Importdauer |
|---|---|
| 1 GiB | 0 Min. 23 Sek. |
| 10 GiB | 4 Min. 24 Sek. |
| 100 GB | 10 Min. 29 Sek. |
| 500 GiB | 13 Min. 15 Sek. |
| 1 TB | 22 Min. 56 Sek. |
| 10 TB | 2 Std. 5 Min. 30 Sek. |
Mit zunehmender Speichergröße wächst auch der Zeitaufwand für das Kopieren von Daten fast in einem linearen Verhältnis. Es ist jedoch wichtig zu wissen, dass Netzwerkschwankungen die Kopiergeschwindigkeit erheblich beeinträchtigen können. Daher sollten die hier bereitgestellten Daten nur als Referenz betrachtet werden.