Freigeben über

Migrieren von Azure Database for MySQL – Einzelserver zu flexibler Server

  • Artikel

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

Wichtig

Einige Einzelserverinstanzen können obligatorische Eingaben erfordern, um eine erfolgreiche direkte automatische Migration durchzuführen. Überprüfen Sie die Migrationsdetails im Blatt „Migration“ im Azure-Portal, um diese Eingaben bereitzustellen. Wenn keine obligatorischen Eingaben 2 Tage vor der geplanten Migration bereitgestellt werden, führt dies zu einer erneuten Planung der Migration zu einem späteren Zeitpunkt.

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, Universell oder Arbeitsspeicheroptimiert und ohne aktivierte komplexe Features (Lesereplikat, virtuelles Netzwerk, doppelte Verschlüsselung der Infrastruktur, Dienstendpunkt/VNet-Regeln). 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 während eines geplanten Wartungsfensters eine äußerst robuste und selbstheilende Offlinemigration mit weniger als 5 Minuten Ausfallzeiten für die SKU für allgemeine Zwecke und speicheroptimierte SKU und bis zu 30 Minuten für die einfache SKU. 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 Einzelserverinstanz über eine einfache SKU verfügt, wird Ihre geplante Instanz mit einem Ausfallzeitfenster von bis zu 30 Minuten migriert. Die Instanz wird zu einer höheren allgemeinen SKU migriert, um eine erfolgreiche Migration sicherzustellen und in 24-48 Stunden auf burstable SKU herabskaliert zu werden. Wenn nach der Migration zu Burstable SKU die Guthaben ihrer Instanz aufgrund einer hohen CPU-Workload ausläuft, sollten Sie ein Upgrade auf die SKU für allgemeine Zwecke auf der Flexible Server-Instanz in Betracht ziehen.

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 besitzen und keine komplexen Features aktiviert haben (Lesereplikat, virtuelles Netzwerk, doppelte Verschlüsselung der Infrastruktur, Dienstendpunkt/VNet-Regeln), können Sie sich jetzt für die automatische Migration vormerken lassen (falls nicht bereits vom Dienst geplant), indem Sie Ihre Serverdaten über ein Azure-Supportticket übermitteln.

Führen Sie die folgenden Schritte aus, um Ihren nicht zulässigen Server für die automatische Migration zu qualifizieren:

  • Die Einzelserverinstanz sollte sich im Status „Bereit“ und sich während des geplanten Wartungsfensters nicht im Status „Beendet“ befinden, damit die automatische Migration stattfindet.
  • 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 Ihr Server Lesereplikate enthält, legen Sie Lesereplikate ab. Sie können Lesereplikate nach der automatischen Migration konfigurieren.
  • Wenn auf Ihrem Server die Konfiguration von Dienstendpunkten (VNet-Regeln) oder virtuelles Netzwerk aktiviert ist, sollten Sie sie ablegen oder auf die Funktion für private Verknüpfungen in Ihrer Single Server-Instanz wechseln.
  • Wenn der Server die Double Infrastructure Encryption aktiviert hat, sollten Sie in Ihrer Einzelserverinstanz zu cmK (Customer Managed Key) wechseln.

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üfen und Konfigurieren des Migrationszeitplans und der Details

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 ist 2 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 bei Ihrer Instanz ein oder mehrere private Verbindungen, kundenseitig verwaltete Schlüssel (Customer Managed Key, CMK) sowie Microsoft Entra Admin aktiviert sind, erfordert die direkte automatische Migration obligatorische Eingaben für die privaten Endpunkte, die kundenseitig verwalteten Schlüssel sowie für Microsoft Entra Admin, die von Ihrer Single Server-Instanz zur Flexible Server-Zielinstanz migriert werden. Die Benutzereingaben müssen zwei Tage vor dem geplanten Migrationsfenster bereitgestellt werden. Wenn die Benutzereingaben erst bereitgestellt werden, wenn die Migrationsdetails gesperrt sind, wird die Migration zu einem späteren Zeitpunkt neu geplant. Stellen Sie nach der Bereitstellung aller Eingaben sicher, dass Sie die Konfiguration im Assistenten für die automatische Migration speichern. Schritte zur Bereitstellung von Benutzereingaben:

    • Navigieren Sie zum Blatt „Migration“ Ihrer Single Server-Instanz, und wählen Sie Bearbeiten der geplanten Migration aus.
    • Klicken Sie im Abschnitt Details zur automatischen Migration auf die Schaltfläche Authentifizieren, um die ARM-API-Verbindung zu authentifizieren und zu speichern, um Ihren Server zu migrieren.
    • Wenn für Ihren Server Microsoft Entra Admin konfiguriert ist, können Sie Eingaben im Assistenten für die automatische Migration im Abschnitt „Microsoft Entra Admin“ eingeben:
      • Für die Migration von Microsoft Entra Admin für den Zielserver muss eine Identität zur Azure Database for MySQL – Flexible Server hinzugefügt werden. Die Identität erfordert, dass die folgenden Berechtigungen erteilt werden: User.Read.All, GroupMember.Read.All und Application.Read.All. Wählen Sie eine entsprechende vom Benutzer zugewiesene verwaltete Identität aus und erteilen Sie die richtigen Berechtigungen, indem Sie die folgenden Schritte hier ausführen.
    • Wenn für Ihren Server ein kundenseitig verwalteter Schlüssel konfiguriert ist, können Sie Eingaben im Assistenten für die automatische Migration im Abschnitt „Datenverschlüsselung“ eingeben:
      • Für die Verschlüsselung des kundenseitig verwalteten Schlüssels muss eine Identität zur Azure Database for MySQL – Flexible Server hinzugefügt werden. Bitte wählen Sie eine geeignete benutzerseitig zugewiesene verwaltete Identität aus. Der aufgeführte Schlüsselbezeichner/Schlüssel würde vom Quell- zum Zielserver migriert werden und sollte folgende Berechtigungen erhalten, um den Zugriff auf den Schlüsseltresor zu ermöglichen: Get, Wrap Key, Unwrap Key.
    • Wenn Ihr Einzelserver über private Endpunkteverfügt, führen Sie die folgenden obligatorischen Schritte aus, wenn Sie den Zeitplan für die Migration mindestens 2 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.
        • Eine benutzerdefinierte private DNS-Zone wird von der automatischen Migration nicht unterstützt. Die private DNS-Zone muss privatelink.mysql.database.azure.com sein.
        • Die Methode zur Genehmigung der Verbindung für private Endpunkte muss als automatische Genehmigung, nicht als manuelle festgelegt werden. Die manuelle Genehmigung für private Endpunkte wird von der automatischen Migration nicht unterstützt.
      • Stellen Sie sicher, dass Sie über die Rolle "Mitwirkender auf Abonnement- oder Ressourcengruppenebene verfügen, um beim Authentifizieren Probleme mit Berechtigungen zu vermeiden.
      • Aktivieren Sie das Kontrollkästchen Bestätigung, nachdem sie die aufgeführten erforderlichen Prüfungen für die Migration privater Endpunkte durchgeführt haben.

    Hinweis

    Wenn die obligatorischen Eingaben für die Migration nicht mindestens 2 Tage vor der geplanten Migration bereitgestellt werden, wird die Migration zu einem späteren Zeitpunkt neu geplant.

    Hinweis

    Löschen Sie für single Server-Instanzen mit privaten Endpunkten die Instanz der Einzelnen Server-Quelle nach der Migration. Wenn kein Serverlöschvorgang ausgeführt wird, wird die Quellinstanz bis zu 14 Tage gewartet, nach der sie vom Dienst gelöscht wird.

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.
  • Die Serverparameter, Einstellungen, Konfiguration und Firewallregeln der Einzelnen Serverinstanz sollten während des 2-Tage-Fensters vor der geplanten Automigration nicht aktualisiert werden.
  • 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 2 Universell Standard_D2ds_v4
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) sowie Sperreinstellungen
    • 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.
  • Löschen Sie für single Server-Instanzen mit privaten Endpunkten die Instanz der Einzelnen Server-Quelle nach der Migration. Wenn kein Serverlöschvorgang ausgeführt wird, wird die Quellinstanz bis zu 14 Tage gewartet, nach der sie vom Dienst gelöscht wird.
  • 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 Configuration
Unterdrücken bestimmter Warnungstypen Sie können bestimmte Warnungstypen mithilfe der Microsoft Defender for Cloud-Plattform deaktivieren. Weitere Informationen finden Sie im Leitfaden zum Unterdrücken von Warnungen in Microsoft Defender for Cloud.

Single Server-Benutzer:innen können die API-Eigenschaft verwenden:
properties.disabledAlerts
E-Mail-Benachrichtigungen 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 unter Konfigurieren von E-Mail-Benachrichtigungen für Sicherheitswarnungen.

Single Server-Benutzer:innen können die API-Eigenschaften verwenden:
properties.emailAccountAdmins,
properties.emailAddresses
Exportieren von Warnungen zur weiteren Verarbeitung und/oder Archivierung Warnungen werden auf der Microsoft Defender for Cloud-Plattform gespeichert und über Azure Resource Graph verfügbar gemacht.
Sie können Warnungen in einen anderen Speicher exportieren und die Aufbewahrung separat verwalten. Weitere Informationen finden Sie unter Einrichten des fortlaufenden Exports im Azure-Portal: Microsoft Defender for Cloud.

Single Server-Benutzer:innen können die API-Eigenschaften verwenden:
properties.retentionDays,
properties.storageAccountAccessKey,
properties.storageEndpoint

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