Teilen über

Hauptversionsupgrade in Azure Database for MySQL – Flexibler Server

  • Artikel

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

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.

In diesem Artikel wird beschrieben, wie Sie ein direktes Upgrade Ihrer MySQL-Hauptversion in Azure Database for MySQL – Flexibler Server durchführen. Mit diesem Feature können Kunden direkte Upgrades ihrer MySQL 5.7-Server auf MySQL 8.0 durchführen, ohne dass Daten verschoben oder Verbindungszeichenfolgen für Anwendungen geändert werden müssen.

Wichtig

  • Die Dauer der Downtime variiert je nach Größe Ihrer Datenbankinstanz und der Anzahl der Tabellen darin.
  • Wenn Sie ein Hauptversionsupgrade für Azure Database for MySQL – Flexibler Server über die Rest-API oder das SDK initiieren, vermeiden Sie es, andere Eigenschaften des Diensts in derselben Anforderung zu ändern. Diese gleichzeitigen Änderungen sind nicht zulässig und können zu unbeabsichtigten Ergebnissen oder Anforderungsfehlern führen. Führen Sie nach Abschluss des Upgrades Eigenschaftenänderungen in separaten Vorgängen durch.
  • Einige Workloads zeigen nach dem Upgrade von 5.7 auf 8.0 möglicherweise keine verbesserte Leistung. Es wird empfohlen, die Leistung Ihrer Workload zu bewerten, indem Sie zuerst einen Replikatserver (als Testserver) erstellen und dann auf einen eigenständigen Server bewerben und dann die Workload auf dem Testserver vor der Implementierung des Upgrades in einer Produktionsumgebung ausführen.
  • Das Upgrade der Hauptversion von MySQL kann nicht rückgängig gemacht werden. Bei Ihrer Bereitstellung tritt möglicherweise ein Fehler auf, wenn bei der Überprüfung festgestellt wird, dass der Server mit Features konfiguriert ist, die entfernt wurden oder veraltet sind. Sie können erforderliche Konfigurationsänderungen auf dem Server vornehmen und danach nochmal versuchen, das Upgrade durchzuführen.

Voraussetzungen

  • Lesereplikate mit MySQL 5.7 sollten vor dem primären Server aktualisiert werden, damit die Replikation zwischen unterschiedlichen MySQL-Versionen kompatibel bleibt. Weitere Informationen finden Sie unter Replikationskompatibilität zwischen MySQL-Versionen.
  • Bevor Sie Ihre Produktionsserver aktualisieren, ist es jetzt einfacher und effizienter mit unserem integrierten Feature Überprüfen im Azure-Portal. Dieses Tool prüft vorab die Kompatibilität Ihres Datenbankschemas mit MySQL 8.0 und weist Sie auf mögliche Probleme hin. Auch wenn wir diese bequeme Option anbieten, sollten Sie dringend das offizielle Oracle MySQL Upgrade Checker-Tool verwenden, um die Kompatibilität Ihres Datenbankschemas zu testen und die erforderlichen Regressionstests durchzuführen, um die Anwendungskompatibilität mit entfernten/veralteten Features in der neuen MySQL-Version zu überprüfen.

    Hinweis

    Wenn Sie das offizielle Tool von Oracle verwenden, um die Schemakompatibilität zu überprüfen, treten möglicherweise einige Warnungen auf, die unerwartete Token in gespeicherten Prozeduren angeben, z. B.: mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode Sie können diese Warnungen gefahrlos ignorieren. Sie beziehen sich auf integrierte gespeicherte Prozeduren mit dem Präfix mysql., die zur Unterstützung von Azure MySQL-Features verwendet werden. Diese Warnungen wirken sich nicht auf die Funktionalität Ihrer Datenbank aus.

  • Lösen Sie die bedarfsgesteuerte Sicherung aus, bevor Sie ein Hauptversionsupgrade auf Ihrem Produktionsserver durchführen. Damit können Sie ein Rollback auf Version 5.7 von der vollständigen bedarfsgesteuerten Sicherung durchführen.
  • Bevor Sie mit dem Upgrade der Hauptversion fortfahren, stellen Sie sicher, dass keine aktiven oder ausstehenden XA-Transaktionen in der Datenbank vorhanden sind, da laufende XA-Transaktionen möglicherweise dazu führen können, dass der Upgradevorgang fehlschlägt. Um dieses Problem zu vermeiden, überprüfen Sie zunächst alle XA-Transaktionen im Zustand „vorbereitet“, indem Sie XA RECOVER; ausführen. Verwenden Sie für alle identifizierten Transaktionen XA ROLLBACK '{xid}'; um jede Transaktion rückgängig zu machen, ersetzen Sie {xid} durch die Transaktions-ID. Stellen Sie sicher, dass alle XA-Transaktionen entweder zugesichert oder zurückgesetzt werden, bevor Sie das Upgrade initiieren, um die Transaktionskonsistenz aufrechtzuerhalten und das Risiko von Upgradefehlern zu verringern.

Durchführen eines geplanten Hauptversionsupgrades von MySQL 5.7 auf MySQL 8.0 über das Azure-Portal für Server mit SKU „Burstfähig“

Für die Durchführung eines Hauptversionsupgrades für den Azure Database for MySQL-Computetarif mit der SKU „Burstfähig“ ist ein spezieller Workflow erforderlich. Das liegt daran, dass Hauptversionsupgrades ressourcenintensiv sind und viel CPU und Arbeitsspeicher beanspruchen. Instanzen der SKU „Burstfähig“ sind guthabenbasiert und können Schwierigkeiten mit diesen Anforderungen haben. Dies kann dazu führen, dass beim Upgradeprozess ein Fehler auftritt. Daher aktualisiert das System beim Upgrade der SKU „Burstfähig“ zunächst den Computetarif auf die SKU „Universell“, um sicherzustellen, dass ausreichende Ressourcen für das Upgrade verfügbar sind.

Führen Sie für ein Hauptversionsupgrade für den Azure Database for MySQL-Computetarif mit der SKU „Burstfähig“ über das Azure-Portal die folgenden Schritte aus:

  1. Wählen Sie im Azure-Portal Ihre vorhandene Azure Database for MySQL – Flexibler Server 5.7-Instanz aus.

    Wichtig

    Sie sollten das Upgrade zunächst an einer wiederhergestellten Kopie des Servers durchführen, anstatt direkt ein Upgrade in der Produktionsumgebung durchzuführen. Weitere Informationen finden Sie unter Durchführen einer Zeitpunktwiederherstellung.

  2. Wählen Sie auf der Seite Übersicht in der Symbolleiste die Option Upgrade aus.

    Wichtig

    Folgen Sie vor einem Upgrade dem Link zur Liste der Features, die in MySQL 8.0 entfernt wurden. Überprüfen Sie veraltete sql_mode-Werte, und entfernen/deaktivieren Sie sie auf dem Blatt „Serverparameter“ im Azure-Portal von Ihrem aktuellen Azure Database for MySQL – Flexibler Server 5.7-Server, um Bereitstellungsfehler zu vermeiden. sql_mode mit den Werten NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS und NO_TABLE_OPTIONS wird in MySQL 8.0 nicht mehr unterstützt.

    Screenshot: Upgrade eines flexiblen Azure Database for MySQL-Servers

  3. Überprüfung der Schemakompatibilität

    Bevor Sie mit dem Upgrade fortfahren, führen Sie das offizielle Oracle-Tool MySQL Upgrade Checker aus, um zu überprüfen, ob Ihr aktuelles Datenbankschema mit MySQL 8.0 kompatibel ist. Dieser Schritt ist entscheidend, um einen reibungslosen Upgradeprozess sicherzustellen.

  4. Entscheidung vor dem Upgrade

    Bevor Sie mit dem Upgrade fortfahren, müssen Sie den Computetarif auswählen, auf den Sie upgraden möchten, um das Hauptversionsupgrade durchzuführen. Standardmäßig wird das System von der SKU „Burstfähig“ auf die einfachste SKU vom Typ „Universell“ aktualisiert, Sie können aber bei Bedarf ein Upgrade auf einen höheren Computetarif durchführen.

    Hinweis

    Wenn Ihr Server während des Upgrades im Tarif „Universell“ betrieben wird, werden nur die tatsächlichen Ressourcen vom Typ „Universell“ abgerechnet, die während dieses Zeitraums verwendet werden.

  5. Entscheidung nach dem Upgrade

    Entscheiden Sie, ob die SKU „Universell“ nach dem Upgrade beibehalten oder auf die SKU „Burstfähig“ zurückgesetzt werden soll. Diese Auswahl wird während der ersten Upgradeschritte getroffen.

    Das System aktualisiert den Computetarif automatisch von der SKU „Burstfähig“ auf die ausgewählte SKU „Universell“, um das Upgrade der Hauptversion zu unterstützen.

  6. Upgrade der Hauptversion

    Nachdem der Computetarif aktualisiert wurde, initiiert das System den Prozess zum Hauptversionsupgrade. Überwachen Sie den Status des Upgrades im Azure-Portal. Je nach Größe und Aktivität Ihrer Datenbank kann der Upgradevorgang einige Zeit in Anspruch nehmen.

    Hinweis

    Wenn das Upgrade der Hauptversion fehlschlägt, wird der Computetarif nicht automatisch auf die vorherige SKU „Burstfähig“ zurückgesetzt. Dadurch können Kunden das Hauptversionsupgrade fortsetzen, ohne das Upgrade des Computetarifs erneut ausführen zu müssen.

  7. Automatische Zurücksetzung

    Basierend auf Ihrer Entscheidung vor dem Upgrade behält das System nach Abschluss des Upgrades entweder die SKU „Universell“ bei oder setzt die SKU auf „Burstfähig“ zurück.

    Hinweis

    Wenn Sie sich für die automatische Zurücksetzung auf die SKU „Burstfähig“ entschieden haben, wird das System standardmäßig auf die B2S-SKU zurückgesetzt.

Durchführen eines geplanten Hauptversionsupgrades von MySQL 5.7 auf MySQL 8.0 über das Azure-Portal für Server mit den SKUs „Universell“ und „Unternehmenskritisch“

Führen Sie die folgenden Schritte aus, um ein Hauptversionsupgrade eines Servers mit Azure Database for MySQL – Flexibler Server 5.7 mithilfe des Azure-Portals durchzuführen.

  1. Wählen Sie im Azure-Portal Ihre vorhandene Azure Database for MySQL – Flexibler Server 5.7-Instanz aus.

    Wichtig

    Sie sollten das Upgrade zunächst an einer wiederhergestellten Kopie des Servers durchführen, anstatt direkt ein Upgrade in der Produktionsumgebung durchzuführen. Weitere Informationen finden Sie unter Durchführen einer Zeitpunktwiederherstellung.

  2. Wählen Sie auf der Seite Übersicht in der Symbolleiste die Option Upgrade aus.

    Wichtig

    Folgen Sie vor einem Upgrade dem Link zur Liste der Features, die in MySQL 8.0 entfernt wurden. Überprüfen Sie veraltete sql_mode-Werte, und entfernen/deaktivieren Sie sie auf dem Blatt „Serverparameter“ im Azure-Portal von Ihrem aktuellen Azure Database for MySQL – Flexibler Server 5.7-Server, um Bereitstellungsfehler zu vermeiden. sql_mode mit den Werten NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS und NO_TABLE_OPTIONS wird in MySQL 8.0 nicht mehr unterstützt.

    Screenshot: Upgrade eines flexiblen Azure Database for MySQL-Servers

  3. Durchführen der Überprüfung vor dem Upgrade

    Bevor Sie mit dem Upgrade fortfahren, klicken Sie auf die Schaltfläche Überprüfen, um die Kompatibilität Ihres Servers mit MySQL 8.0 zu überprüfen.

    Screenshot: Überprüfung

    Wichtig

    Wenn Sie das Feature „Überprüfen“ verwenden, um Ihr Datenbankschema auf Kompatibilität mit MySQL 8.0 zu prüfen, sollten Sie sich darüber im Klaren sein, dass Sie die Tabellen sperren müssen, um das gesamte Schema genau zu beurteilen. Dieser Vorgang kann zu Abfragetimeouts führen. Daher ist es ratsam, keine Überprüfung während der Spitzenzeiten durchzuführen oder wenn Ihre Datenbank gerade eine hohe Auslastung hat. Wenn Sie für die Überprüfung einen Zeitraum mit geringer Aktivität wählen, können Sie die Auswirkungen auf Ihre Vorgänge minimieren.

  4. Überprüfen Sie in der Randleiste Upgrade im Textfeld MySQL-Version für das Upgrade die Hauptversion von MySQL, auf die Sie upgraden möchten, d. h. Version 8.0.

    Screenshot des Upgrades

    Bevor Sie Ihren primären Server aktualisieren können, müssen Sie zunächst alle zugehörigen Lesereplikatserver aktualisiert haben. Bis dies abgeschlossen ist, ist Upgrade deaktiviert.

  5. Wählen Sie auf dem primären Server die Bestätigungsmeldung aus, um zu verifizieren, dass alle Replikatserver aktualisiert wurden. Klicken Sie dann auf Upgrade.

    Screenshot des Upgrades

    Auf Lesereplikat- und eigenständigen Servern ist Upgrade standardmäßig aktiviert.

Durchführen eines geplanten Hauptversionsupgrades von MySQL 5.7 auf MySQL 8.0 über die Azure CLI

Führen Sie die folgenden Schritte aus, um ein Hauptversionsupgrade eines Azure Database for MySQL – Flexibler Server 5.7-Servers mithilfe der Azure CLI durchzuführen.

  1. Installieren Sie die Azure CLI für Windows, oder verwenden Sie die Azure CLI in Azure Cloud Shell, um die Upgradebefehle auszuführen.

    Für dieses Upgrade ist mindestens Version 2.40.0 der Azure-Befehlszeilenschnittstelle erforderlich. Bei Verwendung von Azure Cloud Shell ist die aktuelle Version bereits installiert. Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um das Upgrade auf die aktuelle Version durchzuführen.

  2. Nachdem Sie sich angemeldet haben, führen Sie den Befehl az mysql server upgrade aus.

    az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version 8

  3. Geben Sie unter der Bestätigungsaufforderung y zur Bestätigung oder n zum Stoppen des Upgradevorgangs ein, und drücken Sie dann die EINGABETASTE.

Durchführen eines Hauptversionsupgrades von MySQL 5.7 auf MySQL 8.0 auf einem Lesereplikatserver über das Azure-Portal

Führen Sie die folgenden Schritte aus, um ein Hauptversionsupgrade eines Azure Database for MySQL – Flexibler Server 5.7-Servers auf MySQL 8.0 auf einem Lesereplikat mithilfe des Azure-Portals durchzuführen.

  1. Wählen Sie im Azure-Portal Ihren vorhandenen Azure Database for MySQL – Flexibler Server 5.7-Lesereplikatserver aus.

  2. Wählen Sie auf der Seite Übersicht in der Symbolleiste die Option Upgrade aus.

Wichtig

Folgen Sie vor einem Upgrade dem Link zur Liste der Features, die in MySQL 8.0 entfernt wurden. Überprüfen Sie veraltete sql_mode-Werte, und entfernen/deaktivieren Sie sie auf dem Blatt „Serverparameter“ im Azure-Portal von Ihrem aktuellen Azure Database for MySQL – Flexibler Server 5.7-Server, um Bereitstellungsfehler zu vermeiden.

  1. Wählen Sie im Abschnitt Upgrade die Schaltfläche Upgrade ausführen aus, um einen Azure Database for MySQL – Flexibler Server 5.7-Lesereplikatserver auf MySQL 8.0 zu aktualisieren.

    Mit einer Benachrichtigung wird bestätigt, dass der Upgradevorgang erfolgreich war.

  2. Bestätigen Sie auf der Seite Übersicht, dass Ihr Azure Database for MySQL – Flexibler Server-Lesereplikatserver die Version 8.0 ausführt.

  3. Wechseln Sie nun zu Ihrem primären Server, und führen Sie darauf das Hauptversionsupgrade aus.

Durchführen eines Hauptversionsupgrades von MySQL 5.7 auf MySQL 8.0 mit minimaler Ausfallzeit unter Verwendung von Lesereplikaten

Führen Sie die folgenden Schritte aus, um ein Hauptversionsupgrade eines Azure Database for MySQL – Flexibler Server 5.7-Servers auf MySQL 8.0 mit Lesereplikatservern und möglichst geringer Downtime durchzuführen.

  1. Wählen Sie im Azure-Portal Ihren vorhandenen Azure Database for MySQL – Flexibler Server 5.7-Server aus.

  2. Erstellen Sie ein Lesereplikat des primären Servers.

  3. Upgraden Sie Ihr Lesereplikat auf Version 8.0.

  4. Wenn Sie bestätigt haben, dass der Replikatserver Version 8.0 ausführt, unterbrechen Sie die Verbindung zwischen Ihrer Anwendung und dem primären Server.

  5. Überprüfen Sie den Replikationsstatus, um sicherzustellen, dass der Replikatserver sich auf demselben Stand befindet wie der primäre Server, sodass alle Daten synchronisiert sind und keine neuen Vorgänge für den primären Server ausgeführt werden.

  6. Bestätigen Sie mit dem Befehl „show replica status“ auf dem Replikatserver den Replikationsstatus.

     SHOW SLAVE STATUS\G

    Wenn der Status von „Slave_IO_Running“ und „Slave_SQL_Running“ 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 lautet, verarbeitet das Replikat noch Updates. Nachdem Sie bestätigt haben, dass der Wert von „Seconds_Behind_Master“ „****“ lautet, kann die Replikation beendet werden.

  7. Stufen Sie Ihr Lesereplikat zum primären Replikat höher, indem Sie die Replikation anhalten.

  8. Legen Sie den Serverparameter „read_only“ auf 0 (deaktiviert) fest, um mit dem Schreiben auf dem höhergestuften primären Server zu beginnen.

  9. Zeigen Sie mit Ihrer Anwendung auf den neuen primären Server (das bisherige Replikat), auf dem Version 8.0 läuft. Jeder Server verfügt über eine eindeutige Verbindungszeichenfolge. Aktualisieren Sie Ihre Anwendung so, dass Sie auf das (ehemalige) Replikat und nicht auf die Quelle verweist.

Hinweis

In diesem Szenario tritt nur in den Schritten 4 bis 7 Downtime auf.

Häufig gestellte Fragen

  • Führt dies zu einer Downtime des Servers und wenn ja, wie lange dauert dies?

    Um die Ausfallzeiten bei Upgrades so gering wie möglich zu halten, führen Sie die unter Durchführen eines Hauptversionsupgrades von MySQL 5.7 auf MySQL 8.0 mit minimaler Ausfallzeit unter Verwendung von Lesereplikaten beschriebenen Schritte aus. Der Server wird während des Upgradeprozesses nicht verfügbar sein, sodass empfohlen wird, diesen Vorgang während eines geplanten Wartungsfensters durchzuführen. Die geschätzte Downtime hängt von der Datenbankgröße, der bereitgestellten Speichergröße (bereitgestellte IOPs) und der Anzahl der Tabellen in der Datenbank ab. Die Upgradezeit ist direkt proportional zur Anzahl der Tabellen auf dem Server. Um die Downtime für Ihre Serverumgebung abzuschätzen, empfehlen wir, das Upgrade zunächst auf einer wiederhergestellten Kopie des Servers durchzuführen.

  • Was geschieht mit meinen Sicherungen nach dem Upgrade?

    Alle vor dem Upgrade der Hauptversion (automatisch/bedarfsgesteuert) erstellten Sicherungen, werden bei einer Wiederherstellung immer mit einem Server mit der älteren Version (5.7) wiederhergestellt. Alle Sicherungen, die (automatisch/bedarfsgesteuert) nach dem Upgrade der Hauptversion erstellt wurden, werden mit Servern der aktualisierten Version (8.0) wiederhergestellt. Es wird dringend empfohlen, vor einem Upgrade der Hauptversion eine bedarfsgesteuerte Sicherung durchzuführen, um bei Bedarf ein einfaches Rollback ausführen zu können.

  • Ich verwende derzeit Burstable SKU. Plant Microsoft, in Zukunft das Upgrade der Hauptversion für diese SKU zu unterstützen?

    Die burstfähige SKU kann das Hauptversionsupgrade aufgrund der Leistungsbeschränkung dieser SKU nicht unterstützen.

    Wenn Sie ein Hauptversionsupgrade auf Ihrer Azure Database for MySQL – Flexibler Server-Instanz durchführen müssen und derzeit eine burstfähige SKU verwenden, besteht eine temporäre Lösung in einem Upgrade auf Universelle oder Unternehmenskritische SKU. Führen Sie das Upgrade aus und wechseln Sie dann wieder zu Burstable SKU.

    Beachten Sie, dass ein Upgrade auf eine höhere SKU eine Änderung der Preise mit sich bringen und zu erhöhten Kosten für Ihre Bereitstellung führen kann. Da der Upgradevorgang voraussichtlich jedoch nicht lange dauern wird, sollten die zusätzlichen Kosten nicht erheblich sein.

Nächste Schritte