Teilen über

Migrieren von Azure Database for MySQL – Einzelserver zu flexibler Server

  • Artikel

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

Die direkte automatische Migration von Azure Database for MySQL – Single Server zu Flexible Server ist eine vom Dienst initiierte direkte Migration innerhalb eines geplanten Wartungsfensters für Single Server-Datenbankworkloads mit einer der SKUs Basic, Universal oder Memory Optimized, verwendetem Datenspeicher < = 100 GiB und ohne aktivierte komplexe Features (CMK, Microsoft Entra ID, Lesereplikat, virtuelles Netzwerk, doppelte Verschlüsselung der Infrastruktur, Dienstendpunkt/Regeln für virtuelle Netzwerke). Die berechtigten Server werden vom Dienst identifiziert und erhalten eine Benachrichtigung, in der die Schritte zum Überprüfen der Migrationsdetails beschrieben werden.

Die direkte Migration bietet eine äußerst resiliente Offlinemigration mit Selbstreparatur während eines geplanten Wartungsfensters mit weniger als 5 Minuten Ausfallzeit. Dabei wird Sicherungs- und Wiederherstellungstechnologie zur Beschleunigung der Migration eingesetzt. Mit dieser Migration entfällt der Aufwand für die manuelle Migration Ihres Servers, und es wird sichergestellt, dass Sie die Vorteile von Flexibler Server nutzen können, wie z. B. besserer Preis und bessere Leistung, eine genauere Kontrolle über die Datenbankkonfiguration und benutzerdefinierte Wartungsfenster. Im Folgenden werden die wichtigsten Phasen der Migration beschrieben:

  • Die Zielinstanz von flexibler Server wird bereitgestellt und erbt alle Features und Eigenschaften (einschließlich Serverparametern und Firewallregeln) von der Einzelserver-Quellinstanz. Die Einzelserver-Quellinstanz wird schreibgeschützt, und die Sicherung der Einzelserver-Quellinstanz wird auf die Zielinstanz von flexibler Server kopiert.
  • DNS-Umstellung und -Übernahme werden innerhalb des geplanten Wartungsfensters mit minimaler Ausfallzeit erfolgreich durchgeführt, sodass nach der Migration dieselbe Verbindungszeichenfolge beibehalten werden kann. Clientanwendungen stellen ohne benutzergesteuerte manuelle Updates nahtlos eine Verbindung mit der Zielinstanz von flexibler Server her. Auf dem auf migrierten flexiblen Server werden nicht nur die beiden Verbindungszeichenfolgenformate (Einzelserver und flexibler Server), sondern auch die beiden Benutzernamensformate – „username@server_name“ und „username“ – unterstützt.
  • Der migrierte flexible Server ist online und kann jetzt über Azure-Portal/CLI verwaltet werden. Der beendete Einzelserver wird sieben Tage nach der Migration gelöscht.

Hinweis

Wenn Ihre Single Server-Instanz über Universal V1-Speicher verfügt, wird Ihre geplante Instanz 12 Stunden vor dem geplanten Migrationszeitpunkt einem zusätzlichen Neustartvorgang unterzogen. Dieser Vorgang dient dazu, den Serverparameter log_bin zu aktivieren, der für das Upgrade der Instanz auf den Universal V2-Speicher benötigt wird, bevor die direkte automatische Migration durchgeführt wird.

Berechtigung

Wenn Sie eine Single Server-Workload mit Basic- oder GP-SKU besitzen, einen Datenspeicher von <= 100 GiB nutzen und keine komplexen Features (CMK, Microsoft Entra ID, Lesereplikat, Virtual Network, Mehrfachverschlüsselung, Dienstendpunkt-/VNet-Regeln) aktiviert haben, können Sie sich jetzt für die automatische Migration vormerken lassen (falls nicht bereits vom Dienst geplant), indem Sie Ihre Serverdaten über dieses Formular übermitteln.

Konfigurieren der Migrationsbenachrichtigungen

Server, die zur direkten automatischen Migration berechtigt sind, werden vom Dienst vorab benachrichtigt.

Im Folgenden wird beschrieben, wie Sie Benachrichtigungen über die automatische Migration überprüfen und konfigurieren können:

  • Abonnementbesitzer von Einzelservern, für die eine automatische Migration geplant ist, erhalten eine E-Mail-Benachrichtigung.
  • Konfigurieren Sie Dienstintegritätswarnungen, um einen Zeitplan für die direkte Migration und Statusbenachrichtigungen per E-Mail/SMS zu empfangen, indem Sie die folgenden Schritte hier ausführen.
  • Überprüfen Sie die Benachrichtigung über die direkte Migration im Azure-Portal, indem Sie die folgenden Schritte hier ausführen.

Überprüfung des Zeitplans für die Migration

Im Folgenden werden die Möglichkeiten beschrieben, wie Sie Ihren Migrationszeitplan überprüfen können, nachdem Sie eine Benachrichtigung über die direkte automatische Migration erhalten haben:

Hinweis

Der Migrationszeitplan wird 7 Tage vor dem geplanten Migrationsfenster gesperrt. Danach können Sie den Zeitplan nicht mehr ändern.

  • Auf der Übersichtsseite „Einzelserver“ für Ihre Instanz wird ein Portalbanner mit Informationen zu Ihrem Migrationszeitplan angezeigt.
  • Für Einzelserver, für die eine automatische Migration geplant ist, wird im Portal ein neues Blatt namens „Migration“ angezeigt. Sie können den Migrationszeitplan überprüfen, indem Sie zum Blatt „Migration“ Ihrer Einzelserverinstanz navigieren.
  • Wenn Sie die Migration zurückstellen möchten, können Sie sie jeweils um einen Monat verschieben, indem Sie im Azure-Portal zum Blatt „Migration“ Ihrer Einzelserverinstanz navigieren und die Migration durch Auswahl eines anderen Migrationsfensters innerhalb eines Monats neu planen.
  • Wenn Ihr Einzelserver über eine Universell-SKU verfügt, haben Sie die Option, Hochverfügbarkeit zu aktivieren, wenn Sie den Migrationszeitplan überprüfen. Da Hochverfügbarkeit nur während der Erstellung für eine Instanz von MySQL – flexibler Server aktiviert werden kann, wird dringend empfohlen, dieses Feature beim Überprüfen des Migrationszeitplans zu aktivieren.
  • Wenn Ihr Einzelserver über private Endpunkteverfügt, führen Sie die folgenden obligatorischen Schritte aus, wenn Sie den Zeitplan für die Migration 7 Tage vor der geplanten Migration überprüfen:
    • Überprüfen sie die privaten Endpunkte, die migriert werden sollen. Stellen Sie sicher, dass sie als Bereit zum Migrierengekennzeichnet sind. Wenn sie als nicht auswählbar gekennzeichnet sind, wählen Sie das entsprechende Abonnement und die private DNS-Zone aus.
    • Aktivieren Sie die Option Bestätigung, nachdem sie die aufgeführten erforderlichen Prüfungen für die Migration privater Endpunkte durchgeführt haben.
    • Klicken Sie auf die Schaltfläche Authentifizieren, um die ARM-Verbindung zu authentifizieren, die zum Migrieren der privaten Endpunkte vom Quell- zum Zielserver erforderlich ist.

Erforderliche Überprüfungen für die direkte automatische Migration

Überprüfen Sie die folgenden Voraussetzungen, um eine erfolgreiche direkte automatische Migration sicherzustellen:

  • Die Einzelserverinstanz sollte sich im Status „Bereit“ und sich während des geplanten Wartungsfensters nicht im Status „Beendet“ befinden, damit die automatische Migration stattfindet.
  • Stellen Sie für die Einzelserverinstanz mit aktiviertem SSL sicher, dass alle drei Zertifikate (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2-Stammzertifikat und DigiCertGlobalRootCA-Stammzertifikat) im vertrauenswürdigen Stammspeicher verfügbar sind. Wenn Sie das Zertifikat an die Verbindungszeichenfolge angeheftet haben, erstellen Sie vor der geplanten automatischen Migration ein kombiniertes Zertifizierungsstellenzertifikat mit allen drei Zertifikaten, um die Geschäftskontinuität nach der Migration sicherzustellen.
  • Die MySQL-Engine garantiert keine Sortierreihenfolge, wenn in Abfragen keine SORT-Klausel vorhanden ist. Nach der direkten automatischen Migration können Sie eine Änderung der Sortierreihenfolge feststellen. Wenn das Beibehalten der Sortierreihenfolge entscheidend ist, stellen Sie sicher, dass Ihre Abfragen vor der geplanten direkten automatischen Migration aktualisiert werden und die SORT-Klausel enthalten.
  • 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.
  • Wenn Ihr Quell-Einzelserver von Azure DB for MySQL die Modulversion v8.x aufweist, stellen Sie sicher, dass die TLS-Version ihres Quellservers vor der Migration von v1.0 oder v1.1 auf TLS v1.2 aktualisiert wird, da die älteren TLS-Versionen für flexible Server veraltet sind.
  • Wenn die Quellinstanz von Azure Database for MySQL – Einzelserver über Firewallregelnamen mit mehr als 80 Zeichen verfügt, benennen Sie sie um, um sicherzustellen, dass die Namen weniger als 80 Zeichen lang sind. (Die auf flexiblen Servern unterstützte Länge der Firewallregelnamen beträgt 80 Zeichen, während auf einem Einzelserver die zulässige Länge 128 Zeichen beträgt.)
  • Wenn Ihre Quellinstanz von Azure Database for MySQL – Single Server Nicht-Standardports wie 3308, 3309 und 3310 verwendet, ändern Sie Ihren Konnektivitätsport zu 3306, da die oben genannten Nicht-Standardports für Flexible Server nicht unterstützt werden.

Wie wird die Zielinstanz von MySQL – Flexible Server automatisch bereitgestellt?

Computeebene und SKU für die Zielinstanz von Flexible Server werden auf der Grundlage des Tarifs und der virtuellen Kerne der Single Server-Quellinstanz anhand der Details in der folgenden Tabelle bereitgestellt.

Single Server: Tarif Single Server: Virtuelle Kerne Flexibler Server – Ebene Flexibler Server – SKU-Name
Basic 1 Burstfähig Standard_B1s
Basic 2 Burstfähig Standard_B2s
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, *Speichergröße, Abonnement und Ressourcengruppe der Zielinstanz von Flexible Server sind mit denen der Single Server-Quellinstanz identisch.
  • Bei Single Servers mit weniger als 20 GiB-Speicher wird die Speichergröße auf 20 GiB festgelegt, da dies das Mindestspeicherlimit für Azure Database for MySQL – Flexible Server ist.
  • Beide Benutzernamensformate – „username@server_name“ (Einzelserver) und „username“ (flexibler Server) – werden auf dem migrierten flexiblen Server unterstützt.
  • Beide Verbindungszeichenfolgenformate – Einzelserver und flexibler Server – werden auf dem migrierten flexiblen Server unterstützt.
  • Für die Instanz mit einem einzelnen Server mit aktivierter Abfragespeicher ist der Serverparameter "slow_query_log" für die Zielinstanz auf "EIN" festgelegt, um die Featureparität bei der Migration zu flexiblem Server sicherzustellen. Für bestimmte Workloads kann dies Auswirkungen auf die Leistung haben. Falls Sie Leistungsbeeinträchtigungen beobachten, legen Sie diesen Serverparameter für die Instanz von Flexible Server auf AUS fest.

Schritte nach der Migration

Hier sind die Informationen, die Sie nach der direkten Migration benötigen:

Hinweis

Starten Sie nach der Migration die beendete Single Server-Instanz nicht neu, da dies die Client- und Anwendungskonnektivität beeinträchtigen kann.

  • Kopieren Sie nach erfolgreichem Abschluss des MySQL-Importvorgangs die folgenden Eigenschaften aus der Einzelserver-Quellinstanz in die Zielinstanz von flexibler Server:
    • 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.
  • Für die Instanz mit einem einzelnen Server mit aktivierter Abfragespeicher ist der Serverparameter "slow_query_log" für die Zielinstanz auf "EIN" festgelegt, um die Featureparität bei der Migration zu flexiblem Server sicherzustellen. Für bestimmte Workloads hat dies Auswirkungen auf die Leistung. Falls Sie Leistungsbeeinträchtigungen beobachten, legen Sie diesen Serverparameter für die Instanz von Flexible Server auf AUS fest.
  • Bei einer Single Server-Instanz mit aktivierter Instanz von Microsoft Defender for Cloud wird der Aktivierungsstatus migriert. Um die Parität in Flexible Server nach der Automigration für Eigenschaften zu erreichen, die Sie in Single Server konfigurieren können, berücksichtigen Sie die Details in der folgenden Tabelle:
Eigenschaft Konfiguration
properties.disabledAlerts Sie können bestimmte Warnungstypen mithilfe der Microsoft Defender for Cloud-Plattform deaktivieren. Weitere Informationen finden Sie im Artikel mit dem Leitfaden zum Unterdrücken von Warnungen aus Microsoft Defender for Cloud.
properties.emailAccountAdmins, properties.emailAddresses Sie können E-Mail-Benachrichtigungen für Microsoft Defender for Cloud-Warnungen für alle Ressourcen in einem Abonnement zentral definieren. Weitere Informationen finden Sie im Artikel Konfigurieren von E-Mail-Benachrichtigungen für Sicherheitswarnungen.
properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint Die Microsoft Defender for Cloud-Plattform macht Warnungen über Azure Resource Graph verfügbar. Sie können Warnungen in einen anderen Speicher exportieren und die Aufbewahrung separat verwalten. Weitere Informationen zum fortlaufenden Export finden Sie im Artikel Einrichten eines fortlaufenden Exports im Azure-Portal: Microsoft Defender for Cloud.

Häufig gestellte Fragen (FAQs)

Q. Warum wird bei mir eine automatische Migration durchgeführt?

A. Ihre Instanz von Azure Database for MySQL – Einzelserver ist zur direkten Migration zu unserem Vorzeigeangebot Azure Database for MySQL – Flexibler Server berechtigt. Mit dieser direkten Migration entfällt der Aufwand für die manuelle Migration Ihres Servers, und Sie können die Vorteile von Flexibler Server nutzen, wie z. B. besserer Preis & bessere Leistung, eine genauere Kontrolle über die Datenbankkonfiguration und benutzerdefinierte Wartungsfenster.

F: Wie läuft die automatische Migration ab? Was wird alles migriert?

A. Der flexible Server wird so bereitgestellt, dass er die gleiche Anzahl virtueller Kerne und denselben Speicher wie Ihr Einzelserver aufweist. Als Nächstes wird die Einzelserver-Quellinstanz in den Zustand „Beendet“ versetzt, eine Momentaufnahme der Datendatei erstellt und in die Zielinstanz von flexibler Server kopiert. Die DNS-Umstellung wird ausgeführt, um alle vorhandenen Verbindungen an das Ziel weiterzuleiten, und die Zielinstanz von flexibler Server wird online geschaltet. Bei der automatischen Migration werden die gesamten Datendateien des Servers (einschließlich Schema, Daten, Logins) sowie die Serverparameter und Firewall-Regeln migriert. Alle geänderten Serverparameter der Quelle werden auf das Ziel kopiert. Nicht geänderte Serverparameter nehmen den von Flexible Server definierten Standardwert an. Dies ist eine Offlinemigration, bei der Ausfallzeiten von bis zu höchstens 5 Minuten auftreten.

Q. Wie kann ich Warnungen bezüglich der direkten Migration einrichten oder anzeigen?

A. Im Folgenden können Sie Warnungen einrichten:

  • Konfigurieren Sie Dienstintegritätswarnungen, um einen Zeitplan für die direkte Migration und Statusbenachrichtigungen per E-Mail/SMS zu empfangen, indem Sie die folgenden Schritte ausführen.
  • Überprüfen Sie die Benachrichtigung über die direkte Migration im Azure-Portal, indem Sie die folgenden Schritte ausführen.

Q. Wie kann ich die geplante Migration zurückstellen?

A. Sie können den Migrationszeitplan überprüfen, indem Sie zum Blatt „Migration“ Ihrer Einzelserverinstanz navigieren. Wenn Sie die Migration zurückstellen möchten, können Sie sie höchstens um einen Monat verschieben, indem Sie im Azure-Portal zum Blatt „Migration“ Ihrer Single Server-Instanz navigieren und die Migration durch Auswählen eines anderen Migrationsfensters innerhalb eines Monats neu planen. Die Migrationsdetails werden 7 Tage vor dem geplanten Migrationsfenster gesperrt. Danach können Sie den Zeitplan nicht mehr ändern. Diese direkte Migration kann monatlich bis zum 16. September 2024 zurückgestellt werden.

F: Welcher Benutzername und welche Verbindungszeichenfolge würden vom migrierten flexiblen Server unterstützt? ​​

A. Beide Benutzernamensformate – „username@server_name“ (Einzelserver) und „username“ (flexibler Server) – werden auf dem migrierten flexiblen Server unterstützt. Daher müssen Sie sie nicht aktualisieren, um die Anwendungskontinuität nach der Migration aufrechtzuerhalten. Überdies werden beide Verbindungszeichenfolgenformate (Format für Einzelserver und flexible Server) auch auf dem migrierten flexiblen Server unterstützt.

F: Wie kann ich Hochverfügbarkeit für meinen automatisch migrierten Server aktivieren?

A. Standardmäßig richtet die automatische Migration die Migration zu einer Instanz ohne Hochverfügbarkeit ein. Da Hochverfügbarkeit nur zum Zeitpunkt der Servererstellung aktiviert werden kann, sollten Sie den Hochverfügbarkeitsstatus vor der geplanten automatischen Migration mithilfe der Option zum Bearbeiten des Zeitplans für die automatische Migration im Portal aktivieren. Hochverfügbarkeit kann nur für die SKUs „Universell“ und „Memory Optimized“ auf der Zielinstanz von Flexible Server aktiviert werden, da bei der Migration von einer SKU „Basic“ zu „Burstfähig“ keine Hochverfügbarkeitskonfiguration unterstützt wird.

F: Ich sehe einen Preisunterschied bei meinem potenziellen Wechsel von MySQL Basic Einzelserver zu MySQL Flexibler Server?

A. Bei einigen wenigen Servern kann es nach der Migration zu einer geringfügigen Preiserhöhung kommen (geschätzte Kosten werden durch Klicken auf die Option zum Bearbeiten des Zeitplans für die automatische Migration im Portal angezeigt), da das Mindestspeicherlimit für beide Angebote unterschiedlich ist (5 GiB bei Single Server; 20 GiB bei Flexible Server) und die Speicherkosten (0,1 USD bei Single Server; 0,115 USD bei Flexible Server) bei Flexible Server geringfügig höher sind als bei Single Server. Bei betroffenen Servern bietet diese Preiserhöhung bei Flexible Server einen besseren Durchsatz und eine bessere Leistung im Vergleich zu Single Server.

Zugehöriger Inhalt