Migrieren von „Azure Database for MySQL – Einzelserver“ zu „Flexibler Server“ mit der Azure MySQL-Import-CLI

GILT FÜR: Azure Database for MySQL – Single Server

Mit der Azure Database for MySQL-Import-CLI (allgemein verfügbar) können Sie „Azure Database for MySQL – Einzelserver“ nahtlos zu „Flexibler Server“ migrieren. Es wird Technologie zur Momentaufnahmensicherung- und -wiederherstellung verwendet, um einen einfachen und schnellen Migrationspfad zum Wiederherstellen der physischen Datendateien des Quellservers auf dem Zielserver bereitzustellen. Nach dem Importvorgang können Sie die Vorteile von „Flexibler Server“ nutzen, einschließlich besserer Preise und Leistung, einer präzisen Steuerung über die Datenbankkonfiguration und benutzerdefinierter Wartungsfenster.

Basierend auf Benutzereingaben wird die Verantwortung für die Bereitstellung Ihrer Flexible Server-Zielinstanz und dann die Sicherung des Quellservers und die Wiederherstellung des Ziels übernommen. Dabei werden die Datendateien, Serverparameter, kompatiblen Firewallregeln und Servereigenschaften (tier, version, sku-name, storage-size, location, geo-redundant-backup, public-access, tags, auto grow, backup-retention-days, admin-user, admin-password) aus der Einzelserverinstanz in die Instanz des flexiblen Servers kopiert.

Die Azure Database for MySQL-Import-CLI unterstützt eine Migration mit nahezu keiner Downtime. Dabei wird zuerst ein Offlineimportvorgang ausgeführt, und anschließend können Benutzer*innen die Datenreplikation zwischen Quelle und Ziel einrichten, um eine Onlinemigration durchzuführen.

In diesem Tutorial erfahren Sie, wie Sie mithilfe des Azure Database for MySQL-Import-CLI-Befehls Ihre Instanz von „Azure Database for MySQL – Einzelserver“ zu „Flexibler Server“ migrieren.

Neuigkeiten

• Azure Database for MySQL Import operation for Single Servers with Legacy Storage Architecture (General Purpose Storage V1) is now supported. Sie müssen den Parameter log_bin=ON für Ihre Einzelserverinstanz mit Legacyspeicher festlegen, bevor Sie den Importvorgang initiieren. Erstellen Sie dazu ein Lesereplikat für Ihre Einzelserverinstanz, und löschen Sie es dann. Dieser Vorgang legt den Parameter log_bin auf EIN fest, und Sie können dann einen Importvorgang auslösen, um zu flexiblem Server zu migrieren. (Februar 2024)

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 ermitteln. 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 mit dem Befehl az account set das spezifische Abonnement aus, in dem sich die Quelle Azure Database for MySQL – Single Server unter Ihrem Konto befindet. 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. Wenn Sie über mehrere Abonnements verfügen, wählen Sie das entsprechende Abonnement aus, in dem sich die Quelle Azure Database for MySQL – Single Server befindet. Verwenden Sie az account list, um alle Abonnements abzurufen.

az account set --subscription <subscription id>

Beschränkungen und Voraussetzungen

• Wenn Ihre Quell-Azure-Datenbank für MySQL Single Server über eine einfache SKU verfügt, sollten Sie die SKU im Importbefehl als "Allgemein" angeben, um Speicherprobleme zu verringern. Sie können die SKU nach der Migration wieder in Burstable für die migrierte Flexible Server-Instanz ändern.

• Wenn Ihre Azure Database for MySQL Single Server-Quelldatenbank die Modulversion v8.x aufweist, stellen Sie sicher, dass Sie die .NET-Clienttreiberversion Ihres Quellservers auf 8.0.32 aktualisieren, um Codierungsinkompatibilitäten nach der Migration zu Flexible Server zu vermeiden.

• Die Quelle Azure Database for MySQL – Single Server und das Ziel Azure Database for MySQL – Flexible Server müssen sich im selben Abonnement, in derselben Ressourcengruppe und Region befinden, und ihre MySQL-Version muss identisch sein. Der Import über Abonnements, Ressourcengruppen, Regionen und Versionen hinweg ist nicht möglich.

• Von der Azure Database for MySQL-Import-CLI werden die MySQL-Versionen 5.7 und 8.0 unterstützt. Wenn Sie eine andere MySQL-Hauptversion auf einem Einzelserver verwenden, stellen Sie sicher, dass Sie Ihre Version in Ihrer Einzelserverinstanz aktualisieren, bevor Sie den Importbefehl auslösen.

• Wenn in der Instanz von „Azure Database for MySQL – Einzelserver“ der Serverparameter „lower_case_table_names“ auf 2 festgelegt ist und Ihre Anwendung Partitionstabellen verwendet hat, führt der Importvorgang zu beschädigten Partitionstabellen. Es wird empfohlen, „lower_case_table_names" für Ihre Azure Database for MySQL – Single Server-Instanz auf 1 festzulegen, um den MySQL-Importvorgang fehlerfrei fortzusetzen.

• Der Import in eine vorhandene Instanz von „Azure MySQL – Flexibler Server“ wird nicht unterstützt. Der CLI-Befehl initiiert den Import einer neuen Azure MySQL Flexible Server-Instanz.

• Wenn der flexible Zielserver beim Aktualisieren der CLI-Befehlsparameter ohne Hochverfügbarkeit (Hochverfügbarkeit deaktiviert) bereitgestellt wird, kann er später auf Hochverfügbarkeit in gleicher Zone, aber nicht auf zonenredundante Hochverfügbarkeit umgestellt werden.

• Für Einzelserverinstanzen mit aktiviertem CMK erfordert der Befehl für den Azure Database for MySQL-Import, dass Sie obligatorische Eingabeparameter zum Aktivieren von CMK in der Zielinstanz von „Flexibler Server“ bereitstellen.

• Wenn in der Single Server-Instanz „Infrastructure Double Encryption“ aktiviert ist, wird empfohlen, kundenseitig verwaltete Schlüssel (CMK) in der Flexible Server-Zielinstanz zu aktivieren, um ähnliche Funktionen zu unterstützen. Sie können mit Eingabeparametern der Azure Database for MySQL-Import-CLI oder auch nach der Migration CMK auf dem Zielserver aktivieren.

• Wenn die Instanz „Abfragespeicher“ aktiviert ist, wird empfohlen, langsame Abfrageprotokolle für die Flexible Server-Zielinstanz zu aktivieren, um ähnliche Funktionen zu unterstützen. Sie können langsame Abfrageprotokolle auf dem flexiblen Zielserver konfigurieren, indem Sie die folgenden Schritte ausführen. Anschließend können Sie Abfrageerkenntnisse unter Verwendung der Arbeitsmappenvorlage anzeigen.

• Wichtige Überlegungen bei der Verwendung von Virtual Network (VNet) und Azure Database for MySQL Import CLI: - Vermeiden Sie gleichzeitige Vorgänge auf VNet: Wenn Sie einen Importvorgang ausführen, verzichten Sie darauf, alle anderen Vorgänge auf demselben VNet auszuführen. Wenn andere Vorgänge ausgeführt werden, warten Sie, bis sie vollständig abgeschlossen sind, bevor Sie den Importvorgang starten. Dies soll mögliche Konflikte oder Ressourcenkonflikte verhindern. - Beschränken Sie gleichzeitige Servermigrationen: Wenn Sie planen, mehrere Server zu migrieren, die sich unter demselben VNet befinden, initiieren Sie diese Migrationen nicht gleichzeitig. Dies kann dazu führen, dass die Vorgänge in VNet blockiert werden, was zu erweiterten Wartezeiten und sogar Timeouts führt.

• Wenn Ihre Single Server-Instanz eine Legacyspeicherarchitektur (General Purpose Storage V1) aufweist, müssen Sie den Parameter log_bin=ON für Ihre Single Server-Instanz festlegen, bevor Sie den Importvorgang initiieren. Erstellen Sie dazu ein Lesereplikat für Ihre Einzelserverinstanz, und löschen Sie es dann. Dieser Vorgang legt den Parameter log_bin auf EIN fest, und Sie können dann einen Importvorgang auslösen, um zu flexiblem Server zu migrieren.

• Wenn für Ihre Single Server-Instanz Advanced Threat Protection aktiviert ist, müssen Sie Advanced Threat Protection für die migrierte flexible Serverinstanz nach der Migration aktivieren, indem Sie die folgenden Schritte [hier] (/azure/mysql/flexible-server/advanced-threat-protection-setting?view=azure-cli-latest) ausführen.

• Wenn Ihre Single Server-Instanz über die Engine-Version v8.0 verfügt, sollten Sie die folgenden Maßnahmen ergreifen, um zu vermeiden, dass es aufgrund der geringfügigen Versionsunterschiede zwischen der Single Server- und der Flexible Server-Instanz zu Änderungen kommt:

  • Führen Sie die folgende Anweisung aus, um zu überprüfen, ob Ihre Instanz durch fehlerhafte Histogramminformationen beeinträchtigt werden könnte. Wenn die entsprechenden Tabellen ausgegeben werden, empfehlen wir, dass Sie auf https://dev.mysql.com/blog-archive/histogram-statistics-in-mysql/ verweisen, um die Histogramminformationen zu löschen, und erstellen Sie sie dann auf dem flexiblen Server neu. Es ist erwähnenswert, dass es sich bei der Histogramminformation nur um statistische Informationen über die Spalten handelt und diese Informationen nur in Systemtabellen vorhanden sind, so dass das Löschen der Histogramm-Information keine Auswirkungen auf die Tabellendaten hat.

        SELECT DISTINCT SCHEMA_NAME, TABLE_NAME FROM `information_schema`.`column_statistics`;
    

  • Führen Sie den folgenden Befehl aus, um nach Tabellen zu suchen, deren Tabellenspaltenreihenfolge durcheinander geraten sein könnte. Wenn diese Überprüfung betroffene Tabellen identifiziert, müssen Sie alle Daten aus diesen Tabellen abbilden und dann wieder importieren. Dies kann dazu führen, dass die Reihenfolge der Spalten im Binlog nicht der Reihenfolge der Spalten in den Benutzertabellen entspricht. Diese Diskrepanz kann verhindern, dass Benutzer Replikation einrichten, Daten wiederherstellen, hohe Verfügbarkeit (High Availability, HA) und andere Vorgänge aktivieren.

        SELECT table_schema, table_name, COUNT(*) AS column_count, MAX(ORDINAL_POSITION) AS max_ordinal_position
        FROM information_schema.columns
        GROUP BY table_schema, table_name
        HAVING column_count != max_ordinal_position;
    

• Nur der Import auf Instanzebene wird unterstützt. Es ist keine Option zum Importieren ausgewählter Datenbanken innerhalb einer Instanz verfügbar.

• Die folgenden Elemente sollten von Benutzer*innnen nach dem Importvorgang von der Quelle in das Ziel kopiert werden:

  • Lesereplikate
  • Einstellungen der Überwachungsseite (Warnungen, Metriken und Diagnoseeinstellungen)
  • Alle von Ihnen gehosteten Terraform-/CLI-Skripts zum Verwalten Ihrer Single Server-Instanz sollten mit Flexible Server-Verweisen aktualisiert werden.

Auslösen eines Azure Database for MySQL-Importvorgangs zum Migrieren von „Azure Database for MySQL – Einzelserver“ zu „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 eine Flexible Server-Zielinstanz und führt den Import auf Instanzebene von der Quelle zum Ziel mithilfe von Dienststandards und Werten aus dem lokalen Kontext Ihrer Azure CLI aus:

az mysql flexible-server import create --data-source-type
                                --data-source
                                --resource-group
                                --name
                                [--sku-name]
                                [--tier]
                                [--version]
                                [--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]
                                [--location]
                                [--private-dns-zone]
                                [--public-access]
                                [--resource-group]
                                [--standby-zone]
                                [--storage-auto-grow {Disabled, Enabled}]
                                [--subnet]
                                [--subnet-prefixes]
                                [--tags]
                                [--vnet]
                                [--zone]

Im folgenden Beispiel werden die Datenquelleninformationen für Single Server mit dem Namen „test-single-server“ und Flexible Server-Zielinformationen verwendet, eine Flexible Server-Instanz mit dem Namen test-flexible-server am westus-Speicherort (gleicher Speicherort wie der der Single Server-Quellinstanz) erstellt und ein Import von der Quelle zum Ziel ausgeführt. Der Azure Database for MySQL-Importbefehl ordnet die entsprechenden Eigenschaften (tier, version, sku-name, storage-size, location, geo-redundant-backup, public-access, tags, auto grow, backup-retention-days, admin-user, admin-password) vom Einzelserver dem flexiblen Server als intelligente Standardwerte zu, wenn keine Eingaben für den CLI-Befehl bereitgestellt werden. Sie können die intelligenten Standardwerte überschreiben, indem Sie Eingaben für diese optionalen Parameter bereitstellen.

az mysql flexible-server import create --data-source-type "mysql_single" --data-source "test-single-server" --resource-group "test-rg"  --name "test-flexible-server"

Im folgenden Beispiel werden die Datenquelleninformationen für den Einzelserver mit dem Namen „test-single-server“ und die Informationen für den flexiblen Zielserver verwendet, eine Zielinstanz für den flexiblen Server mit dem Namen test-flexible-server am Standort westus (gleicher Standort wie der der Single Server-Quellinstanz) mit aktivierter Zonenredundanz und Integration des virtuellen Netzwerks erstellt und ein Import von der Quelle zum Ziel ausgeführt. Weitere Informationen zur Konfiguration virtueller Netzwerke finden Sie hier.

# create vnet
az network vnet create --resource-group testGroup --name myVnet --location testLocation --address-prefixes 172.0.0.0/16

# create subnet
az network vnet subnet create --resource-group testGroup --vnet-name myVnet --address-prefixes 172.0.0.0/24 --name mySubnet

# create private dns zone
az network private-dns zone create -g testGroup -n myserver.private.contoso.com

# trigger mysql import
az mysql flexible-server import create --data-source-type "mysql_single" --data-source "test-single-server" --resource-group "test-rg"  --name "test-flexible-server" --high-availability ZoneRedundant --zone 1 --standby-zone 3  --vnet "myVnet" --subnet "mySubnet" --private-dns-zone "myserver.private.contoso.com"

Im folgenden Beispiel werden die Datenquelleninformationen für die Single Server-Instanz mit dem Namen „test-single-server“ und aktiviertem kundenseitig verwaltetem Schlüssel (CMK) sowie Flexible Server-Zielinformationen verwendet, eine Flexible Server-Instanz namens „test-flexible-server“ erstellt und ein Import von der Quelle zum Ziel ausgeführt. Für Einzelserverinstanzen mit aktiviertem CMK erfordert der Befehl für den Azure Database for MySQL-Import, dass Sie obligatorische Eingabeparameter zum Aktivieren von CMK bereitstellen: --keyIdentifierOfTestKey --identity testIdentity.

# create keyvault
az keyvault create -g testGroup -n testVault --location testLocation \
  --enable-purge-protection true

# create key in keyvault and save its key identifier
keyIdentifier=$(az keyvault key create --name testKey -p software \
  --vault-name testVault --query key.kid -o tsv)

# create identity and save its principalId
identityPrincipalId=$(az identity create -g testGroup --name testIdentity \
  --location testLocation --query principalId -o tsv)

# add testIdentity as an access policy with key permissions 'Wrap Key', 'Unwrap Key', 'Get' and 'List' inside testVault
az keyvault set-policy -g testGroup -n testVault --object-id $identityPrincipalId \
  --key-permissions wrapKey unwrapKey get list

# trigger azure database for mysql import for CMK enabled single server
az mysql flexible-server import create --data-source-type "mysql_single" --data-source "test-single-server" --resource-group "test-rg"  --name "test-flexible-server" --key $keyIdentifier --identity testIdentity

Hier sind die Details zu den obigen Argumenten aufgeführt:

Schritte für die Onlinemigration

Nach Abschluss des oben erläuterten Azure Database for MySQL-Importvorgangs:

• Melden Sie sich bei der Zielinstanz von „Azure Database for MySQL – Flexibler Server“ an, und führen Sie den folgenden Befehl aus, um den Dateinamen und die Position des Binärprotokolls entsprechend der Sicherungsmomentaufnahme abzurufen, die von der Azure Database for MySQL-Import-CLI zum Wiederherstellen auf dem Zielserver verwendet wird.

CALL mysql.az_show_binlog_file_and_pos_for_mysql_import();

• Richten Sie die Datenreplikation zwischen den Quell- und Zielserverinstanzen mithilfe der Binärprotokollposition ein, indem Sie die hier aufgeführten Schritte ausführen. Wenn der Replikationsstatus angibt, dass der Zielserver auf dem gleichen Stand wie die Quelle ist, beenden Sie die Replikation, und führen Sie den Cutover aus.

Bewährte Methoden zum Konfigurieren von Befehlsparametern für die Azure Database for MySQL-Import-CLI

Bevor Sie den Befehl der Azure Database for MySQL-Import-CLI auslösen, sollten Sie die folgenden Parameterkonfigurationsanleitungen berücksichtigen, um mithilfe der Azure Database for MySQL-Import-CLI schnellere Datenladevorgänge zu gewährleisten.

• Wenn Sie die intelligenten Standardwerte überschreiben möchten, wählen Sie die Computeebene und den SKU-Namen für die Zielinstanz des flexiblen Servers auf der Grundlage des Tarifs und der virtuellen Kerne der Einzelserverquellinstanz anhand der Details in der folgenden Tabelle aus.

  Single Server: Tarif	Single Server: Virtuelle Kerne	Flexibler Server – Ebene	Flexibler Server – SKU-Name
  Basic	1	Burstfähig	Standard_B2ms
  Basic	2	Burstfähig	Standard_B2ms
  Universell	4	Universell	Standard_D4ds_v4
  Universell	8	Universell	Standard_D8ds_v4
  Universell	16	Universell	Standard_D16ds_v4
  Universell	32	Universell	Standard_D32ds_v4
  Universell	64	Universell	Standard_D64ds_v4
  Arbeitsspeicheroptimiert	4	Arbeitsspeicheroptimiert	Standard_E4ds_v4
  Arbeitsspeicheroptimiert	8	Arbeitsspeicheroptimiert	Standard_E8ds_v4
  Arbeitsspeicheroptimiert	16	Arbeitsspeicheroptimiert	Standard_E16ds_v4
  Arbeitsspeicheroptimiert	32	Arbeitsspeicheroptimiert	Standard_E32ds_v4

• MySQL-Version, Region, Abonnement und Ressource für die Flexible Server-Zielinstanz müssen größer oder gleich denen der Single Server-Quellinstanz sein.

• Die Speichergröße für die Flexible Server-Zielinstanz sollte mindestens der auf der Single Server-Quellinstanz entsprechen.

• Wenn in der Single Server-Instanz „Infrastructure Double Encryption“ aktiviert ist, wird empfohlen, kundenseitig verwaltete Schlüssel (CMK) in der Flexible Server-Zielinstanz zu aktivieren, um ähnliche Funktionen zu unterstützen. Sie können mit Eingabeparametern der Azure Database for MySQL-Import-CLI oder auch nach der Migration CMK auf dem Zielserver aktivieren.

Wie lange dauert es, bis der Azure Database for MySQL-Import meine Einzelserverinstanz migriert hat?

Nachfolgend finden Sie die referenzierte Leistung basierend auf der Speichergröße für die universelle V2-Speicherarchitektur. (Die Migration von Servern mit universellem V1-Speicher dauert länger, da auch ein Upgrade der Speicherarchitektur erforderlich ist)

Aus der obigen Tabelle ist ersichtlich, dass mit zunehmender Speichergröße auch der Zeitaufwand für das Kopieren von Daten fast in einem linearen Verhältnis wächst. Es ist jedoch wichtig zu wissen, dass die Kopiergeschwindigkeit durch Netzwerkschwankungen erheblich beeinträchtigt werden kann. Daher sollten die hier bereitgestellten Daten nur als Referenz betrachtet werden.

Im Folgenden finden Sie die Benchmarkleistung basierend auf einer unterschiedlichen Anzahl von Tabellen für eine Speichergröße von 10 GiB.

Wenn die Anzahl der Dateien zunimmt, kann jede Datei/Tabelle in der Datenbank sehr klein werden. Dies führt zu einer konstanten Datenmenge, die übertragen wird. Aber es treten häufiger dateibezogene Vorgänge auf, die die Leistung des Azure Database for MySQL-Imports beeinträchtigen können.

Schritte nach dem Import

• Kopieren Sie die folgenden Eigenschaften aus der Einzelserverquellinstanz in die Zielinstanz des flexiblen Servers, nachdem der Azure Database for MySQL-Importvorgang erfolgreich abgeschlossen wurde:
  • Lesereplikate
  • Serverparameterwert für event_scheduler
  • Einstellungen der Überwachungsseite (Warnungen, Metriken und Diagnoseeinstellungen)
  • Alle Terraform-/CLI-Skripts, die Sie zum Verwalten Ihrer Single Server-Instanz hosten, sollten mit Flexible Server-Verweisen aktualisiert werden.

Nächster Schritt