Versionshinweise 2026 für Azure Database for MySQL – Flexibler Server

Azure Database for MySQL – Flexibler Server ist ein vollständig verwalteter Datenbankdienst, der Ihnen granulare Kontrolle über Datenbankverwaltungsfunktionen und Flexibilität bei Konfigurationseinstellungen bietet. Der Dienst unterstützt die Communityversionen von MySQL 5.7, 8.0 und 8.4. Jede monatliche Version bietet neue Funktionen, Modulupdates, Verbesserungen und Fixes, die zuerst auf neuen Servern und auf vorhandenen Servern während der nächsten geplanten Wartung bereitgestellt werden.

In diesem Artikel werden die monatlichen Versionshinweise aus dem Jahr 2026 für Azure Database for MySQL Flexible Server zusammengefasst, aufgeführt in absteigender Reihenfolge, beginnend mit der neuesten Version.

Note

Dieser Artikel enthält Verweise auf den Begriff „Slave“. Dieser Begriff wird von Microsoft nicht mehr verwendet. Sobald der Begriff aus der Software entfernt wurde, wird er auch aus diesem Artikel entfernt.

Juli 2026

Das Update vom Juli 2026 enthält kleinere Upgrades der Engine-Version, Verbesserungen der Zuverlässigkeit und Behebungen bekannter Probleme. Überprüfen Sie die folgenden Details vor dem Upgrade Ihrer Server während der nächsten geplanten Wartung.

Versionshinweise

Die Juli 2026-Version von Azure Database for MySQL Flexible Server ist verfügbar. Ab dem 14. Juli 2026 verwenden alle neuen Server diese Version automatisch. Vorhandene Server werden während der nächsten geplanten Wartung aktualisiert. Um Ihre Server früher zu aktualisieren, registrieren Sie sich beim Virtual Canary-Programm.

Überlegungen zur Wartungsplanung

Sie können das Wartungsplanungsfenster bis zum 15. August 2026 verlängern. Einigen Servern mit aktiviertem CMW wird möglicherweise ein Wartungsdatum außerhalb des bevorzugten Fensters zugewiesen. Sie können die Wartung im Azure-Portal weiterhin neu planen, um ihre ursprüngliche CMW-Einstellung besser anzupassen.

Modulversionsänderungen

Diese Version enthält die folgenden Nebenversionsänderungen:

  • 8.0.44 -> 8.0.45
  • 8.4.7 -> 8.4.8

Features

Diese Version führt keine neuen Features ein.

Improvements

  • Resilienz gegenüber vorübergehenden Netzwerkproblemen hinzugefügt.
  • Während dieses geplanten Wartungsfensters migrieren einige HA-fähige Server von der aktuellen Architektur zu einer dedizierten Load Balancer Standard (SLB)-basierten Architektur. Die infrage kommenden Server werden über die üblichen Wartungsbenachrichtigungen mitgeteilt. Diese Erweiterung fügt eine dedizierte SLB zu HA-Konfigurationen für Server hinzu, die mit öffentlichem Zugriff oder privaten Endpunkten erstellt wurden. Durch die Verwaltung des MySQL-Datendatenverkehrspfads beseitigt die SLB die Notwendigkeit von DNS-Änderungen während failovers, wodurch die Failoverzeit erheblich reduziert wird. Es gibt eine kurze zusätzliche Ausfallzeit (von ca. 30 Sekunden), während diese Migration ausgeführt wird. Dieses Feature wird von Servern mit privatem Zugriff mit einer Integration eines virtuellen Netzwerks nicht unterstützt.

Behebung bekannter Probleme

  • Behebt ein Timeout-Problem bei der Verfügbarkeit von Upgrades auf Hauptversionen und erholt sich nun bei einer Ausnahme schnell wieder.
  • Korrigiert die Logik, damit MultiZone-HA möglich ist, indem geprüft wird, ob noch unterstützte Zonen vorhanden sind.

Mai 2026

Das Update vom Mai 2026 führt neue vom Kunden verwaltete Schlüssel- und Ausfallsicherheitsfunktionen sowie TLS- und Netzwerkverbesserungen sowie bekannte Problembehebungen ein. Überprüfen Sie die folgenden Details vor dem Upgrade Ihrer Server während der nächsten geplanten Wartung.

Versionshinweise

Die Version vom Mai 2026 von Azure Database for MySQL – Flexible Server ist verfügbar. Ab dem 19. Mai 2026 verwenden alle neuen Server diese Version automatisch. Vorhandene Server werden während der nächsten geplanten Wartung aktualisiert. Um Ihre Server früher zu aktualisieren, registrieren Sie sich beim Virtual Canary-Programm.

Überlegungen zur Wartungsplanung

Das Wartungsplanfenster kann bis zum 21. Juni 2026 verlängert werden. Einigen Servern mit aktiviertem CMW wird möglicherweise ein Wartungsdatum außerhalb des bevorzugten Fensters zugewiesen. Sie können die Wartung im Azure-Portal weiterhin neu planen, um ihre ursprüngliche CMW-Einstellung besser anzupassen.

Modulversionsänderungen

Diese Version enthält keine Änderungen der Engine-Version.

Features

  • Sie können jetzt HSM-gesicherte Schlüsseltresore auf Ebene von ProtectedSubscription verwenden, wenn Sie kundenseitig verwaltete Schlüssel (CMK) konfigurieren, und erhalten dadurch eine stärkere Schlüsselisolation für regulierte und compliancekritische Workloads.
  • Sie können jetzt Verfügbarkeitszonen zu einem vorhandenen Server hinzufügen, ohne ihn neu zu erstellen, wodurch die Resilienz einfacher verbessert werden kann, wenn sich Ihre Workload weiterentwickelt.
  • Listen-APIs für Datenbanken und Server unterstützen jetzt die Paginierung und bieten schnellere und zuverlässigere Antworten, wenn Sie eine große Anzahl von Ressourcen verwalten.

Improvements

  • TLS-Zertifikate werden jetzt automatisch früher im Lebenszyklus (bei 84% Gültigkeit) erneuert, und alle Zertifikate folgen demselben Verlängerungszeitplan, wodurch die Wahrscheinlichkeit von Verbindungsproblemen verringert wird, die durch Ablauf des Zertifikats verursacht werden.
  • Während dieses geplanten Wartungsfensters migrieren einige HA-fähige Server von der aktuellen Architektur zu einer dedizierten Load Balancer Standard (SLB)-basierten Architektur. Die infrage kommenden Server werden über die üblichen Wartungsbenachrichtigungen mitgeteilt. Diese Erweiterung fügt eine dedizierte SLB zu HA-Konfigurationen für Server hinzu, die mit öffentlichem Zugriff oder privaten Endpunkten erstellt wurden. Durch die Verwaltung des MySQL-Datendatenverkehrspfads beseitigt die SLB die Notwendigkeit von DNS-Änderungen während failovers, wodurch die Failoverzeit erheblich reduziert wird. Es gibt eine kurze zusätzliche Ausfallzeit (von ca. 30 Sekunden), während diese Migration ausgeführt wird. Dieses Feature wird von Servern mit privatem Zugriff mit einer Integration eines virtuellen Netzwerks nicht unterstützt.

Behebung bekannter Probleme

  • Es wurde ein vorübergehendes Verbindungsproblem behoben, das sich auf Server auswirken konnte, die mit privatem Zugriff (Virtual Network Integration) konfiguriert sind, indem eine kürzlich vorgenommene Änderung auf den zugrunde liegenden Netzwerkstapel zurückgesetzt wurde.
  • Ein Problem wurde behoben, bei dem binlog-Kopiervorgänge fehlschlagen konnten, wenn eine erwartete Binlogdatei fehlte. Der Dienst behandelt diesen Fall jetzt ordnungsgemäß, ohne den Vorgang zu unterbrechen.

März 2026

Das Update vom März 2026 umfasst kleinere Upgrades der Engine-Version, Verbesserungen bei der Fehlerbehebung und Integration sowie die Behebung eines bekannten Problems. Überprüfen Sie die folgenden Details vor dem Upgrade Ihrer Server während der nächsten geplanten Wartung.

Versionshinweise

Die Version vom März 2026 von Azure Database for MySQL flexiblen Server ist jetzt verfügbar. Ab dem 31. März 2026 verwenden alle neuen Server diese Version automatisch. Vorhandene Server werden während der nächsten geplanten Wartung aktualisiert. Um Ihre Server früher zu aktualisieren, registrieren Sie sich beim Virtual Canary-Programm.

Überlegungen zur Wartungsplanung

Sie können das Wartungsfenster bis Ende April verlängern. Einigen Servern mit aktiviertem CMW wird möglicherweise ein Wartungsdatum außerhalb des bevorzugten Fensters zugewiesen. Sie können die Wartung im Azure-Portal weiterhin neu planen, um ihre ursprüngliche CMW-Einstellung besser anzupassen.

Modulversionsänderungen

Diese Version enthält die folgenden Nebenversionsänderungen:

  • 8.0.42 -> 8.0.44
  • 8.4.5 -> 8.4.7
  • 9.3.0 -> 9.5.0

Features

Diese Version führt keine neuen Features ein.

Improvements

  • Gibt klare, umsetzbare, kundenorientierte Fehlermeldungen für Szenarien mit ungültigen Schlüsseln zurück und verbessert so die Fehlerbehebung und das Support-Erlebnis.
  • Ermöglicht die Self-Service-Konfiguration von binlog_row_metadata, das Entsperren von CDC/Data Out-Integrationen und die Reduzierung der Unterstützungsabhängigkeit.
  • Im Rahmen des Updates vom März 2026 wird davon ausgegangen, dass die tägliche automatisierte Sicherungszeit für Ihren Server einmal geändert wird. Nach diesem Update werden Sicherungen wie gewohnt weiterhin einmal täglich ausgeführt. Die tägliche automatische Sicherung bleibt unverändert, und nur der geplante Zeitpunkt der täglichen Sicherung verschiebt sich einmal. Es ist keine Benutzeraktion erforderlich.

Behebung bekannter Probleme

  • Fügt die Überprüfung hinzu, um festzustellen, ob die Ziel-AZ als unterstützte Zone für die spezifische SKU verfügbar ist.

Januar 2026

Das Update vom Januar 2026 konzentriert sich auf Fehlermeldungen und TLS-Verbesserungen sowie bekannte Problembehebungen. Bevor Sie die Wartung neu planen, überprüfen Sie die Überlegungen zur Planung der zertifikatbezogenen Wartung.

Versionshinweise

Die Version vom Januar 2026 von Azure Database for MySQL – Flexibler Server ist jetzt verfügbar. Ab dem 22. Januar 2026 verwenden alle neuen Server diese Version automatisch. Vorhandene Server werden während der nächsten geplanten Wartung aktualisiert. Um Ihre Server früher zu aktualisieren, registrieren Sie sich beim Virtual Canary-Programm.

Überlegungen zur Wartungsplanung

Für Azure-Datenbank für MySQL-Instanzen in der öffentlichen Azure-Cloud läuft ein internes Zertifikat bis Ende Februar 2026 ab. Daher ist das Wartungsplanungsfenster für diesen Zyklus auf Datumsangaben vor Ende Februar beschränkt. Nach Ablauf des Zertifikats kann das Verschieben der Wartung über Februar hinaus dazu führen, dass der Server nach Ablauf des Zertifikats nicht mehr erreichbar ist. Daher wird die Neuplanung über das Ende des Februars hinaus für dieses Wartungsereignis nicht unterstützt.

Für einige Azure-Datenbank für MySQL-Instanzen in Azure National Clouds läuft das Zertifikat, das die aktuelle Zertifizierungsstelle (CA) ausgestellt hat, vor dem 6. Februar 2026 ab. Nach Ablauf des Zertifikats schlagen Clientverbindungen mit dem Server fehl, was zu einer Nichtverfügbarkeit des Diensts führt.

Um zu beurteilen, ob Ihr Server betroffen ist, überprüfen Sie das Ablaufdatum des Zertifikats aus einer Clientumgebung mithilfe des folgenden Befehls: openssl s_client -starttls mysql -connect <server_dns>:3306 Für betroffene Server ist das Wartungsplanungsfenster begrenzt und kann nicht frei verschoben werden, da die weitere Verzögerung das Risiko für das Ablaufen von Zertifikaten und Clientverbindungsfehler erhöht. In einigen Fällen wird das Zertifikat automatisch aktualisiert, wenn der Server kürzlich neu gestartet wurde. Wenn Sie der Meinung sind, dass diese Bedingung auf Ihren Server zutrifft, öffnen Sie einen Azure-Supportfall. Nach der Überprüfung kann das Wartungsplanungsfenster bis Ende Februar verlängert werden.

Während dieses Wartungszyklus gibt es zwischen dem 5. und 10. Februar 2026 und dem 16. und 23. Februar 2026 wichtige globale Ereignisse, die unsere Möglichkeiten einschränken könnten, bei der ersten Planung die Präferenzen aller Kunden für benutzerdefinierte Wartungsfenster (CMW) vollständig zu berücksichtigen. Daher werden einigen Servern mit aktiviertem CMW möglicherweise ein Wartungsdatum außerhalb des bevorzugten Fensters zugewiesen. Sie können die Wartung im Azure-Portal weiterhin neu planen, um diese Ereigniszeiträume oder Ihre ursprüngliche CMW-Einstellung besser auszurichten.

Modulversionsänderungen

Diese Version enthält keine Änderungen der Engine-Version.

Features

Diese Version führt keine neuen Features ein.

Improvements

  • Die Fehlermeldung wurde verbessert, die angezeigt wird, wenn Sie versuchen, HA auf einer VNET-basierten Instanz zu aktivieren, bei der die Funktion "Accelerated Logs" noch aktiviert ist.
  • Tls 1.3-Unterstützung für Azure MySQL 5.7-Version hinzugefügt.

Behebung bekannter Probleme

  • Es wurde ein Problem behoben, bei dem das Aktivieren der Geo-Sicherung zur Folge hatte, dass nachfolgende GTID-Zurücksetzungsvorgänge fehlschlugen.
  • Es wurde ein Problem behoben, bei dem bestimmte HA-Server hinter einem dedizierten Server Load Balancer keinen privaten Endpunkt aktivieren konnten.