MySQL 9.7 LTS in der Praxis #01: Von 8.4 auf 9.7, was beim Upgrade wirklich zählt

Alle Beispiele basieren auf der Beispieldatenbank Sakila und sind mit MySQL 9.7.2 Community getestet, dem zum Testzeitpunkt aktuellen offiziellen Container-Image. Für den Betrieb empfehle ich den neuesten Patchstand, derzeit 9.7.4. Enterprise-Funktionen sind nicht Teil der Serie.

Läuft eure Produktion noch auf MySQL 8.4? Dann ist jetzt der richtige Moment, das nächste Upgrade zu planen, statt es später unter Zeitdruck durchziehen zu müssen. Mit MySQL 9.7 hat Oracle am 21. April 2026 das erste Long-Term-Support-Release seit 8.4 veröffentlicht. Es bündelt zwei Jahre Innovation Releases und ist zugleich der einzige Weg in die neue, kalenderbasierte Versionslinie 26.x.

Ich behaupte, dass sich der Umstieg nicht nur wegen des Supportzyklus lohnt. Etliche Funktionen, die bisher der Enterprise Edition vorbehalten waren, stehen jetzt in der Community Edition zur Verfügung. Genau diese Neuerungen sind Gegenstand dieser Serie. In sechs Teilen nehme ich mir jede Woche ein Thema vor, das im Betrieb wirklich etwas ändert und zwar ausschließlich mit Funktionen der Community Edition. Alle Beispiele basieren auf der Sakila-Datenbank und laufen in einem Podman-Labor.

Den Anfang macht die Frage, die vor allen neuen Features steht. Wie kommt man sauber von 8.4 auf 9.7 und wo lauern die Überraschungen?

Warum gerade jetzt?

MySQL kennt seit 8.4 zwei Release-Linien. Innovation Releases erscheinen quartalsweise und werden nur bis zum nächsten Innovation Release gepflegt. LTS-Releases bleiben über Jahre stabil, Funktionen kommen dort nur im ersten Release einer Reihe hinzu oder fallen weg. 9.7 ist die neue LTS-Basis und seit Juli 2026 tragen die Innovation Releases Kalendernummern wie 26.7 und 26.10. Wer später in diese Linie wechseln will, kommt an 9.7 nicht vorbei, denn LTS-Reihen lassen sich nicht überspringen.

Akuten Druck gibt es für 8.4 noch nicht. Jede LTS-Reihe erhält fünf Jahre Premier Support und drei Jahre Extended Support, für 8.4 also bis April 2029 beziehungsweise April 2032. Für 9.7 verschieben sich diese Termine auf April 2031 und April 2034. Wie es aussieht, wenn man den Absprung verpasst, zeigt MySQL 8.0, das seit April 2026 nur noch im Sustaining Support läuft und keine neuen Updates mehr erhält. Genau darin liegt die Chance. Ein Upgrade, das man in Ruhe testen kann, ist das bessere Upgrade.

Das Labor

Für diesen Beitrag habe ich ein In-Place-Upgrade mit den offiziellen Container-Images durchgespielt. Ausgangspunkt war MySQL 8.4.11, Ziel MySQL 9.7.2. Die Patch-Releases 8.4.13 und 9.7.4 sind am 20. Oktober 2026 erschienen, standen zum Testzeitpunkt aber noch nicht als offizielle Images bereit. Alle Ausgaben in diesem Beitrag stammen aus diesem Lauf.

Auf der 8.4-Instanz liegt Sakila, dazu kommen zwei Testkonten. Eines nutzt bewusst noch mysql_native_password, das in 8.4 nur nach einem Start mit --mysql-native-password=ON verfügbar ist.

CREATE USER 'app_alt'@'%' IDENTIFIED WITH mysql_native_password BY 'Alt_Pw_84!'; 
CREATE USER 'app_neu'@'%' IDENTIFIED WITH caching_sha2_password BY 'Neu_Pw_84!'; 
GRANT SELECT ON sakila.* TO 'app_alt'@'%', 'app_neu'@'%'; 

Das vollständige Laborskript für Podman findet ihr hier: 

Was meldet der Upgrade Checker?

Bevor ein Upgrade durchgeführt wird, sollte der Upgrade Checker der MySQL Shell in der Version der Zielumgebung ausgeführt werden. Praktischerweise enthält das offizielle 9.7-Image die MySQL Shell bereits. Im Labor lief der Check aus einem Wegwerf-Container heraus gegen die 8.4-Instanz. 

podman run --rm --network mysql97 docker.io/library/mysql:9.7 \ 
  mysqlsh "root:${PW}@mj84:3306" -- util check-for-server-upgrade --target-version=9.7.2 

Ein kleiner Stolperstein liegt in der Aufrufform. Wer util.checkForServerUpgrade({targetVersion: '9.7.2'}) mit nur einem Objekt aufruft, erhält Invalid values in connection options: targetVersion, weil die Shell ein einzelnes Objekt als Verbindungsoptionen liest. Die Kommandozeilenform oben umgeht das zuverlässig.

Für die Sakila-Instanz meldete der Checker einen Fehler und 21 Warnungen. Tabellen, Routinen, Foreign Keys und Plugins waren unauffällig. Der Fehler betrifft erwartungsgemäß das Altkonto.

5) Check for deprecated or invalid user authentication methods. 
(authMethodUsage) 
   Some users are using authentication methods that may be deprecated or 
   removed, please review the details below. 
 
   Error: The following users are using the 'mysql_native_password' 
   authentication method which is removed as of MySQL 9.0.0. 
   The users must be deleted or re-created with a different authentication 
   method (i.e. caching_sha2_password). 
   - app_alt@% 
... 
Errors:   1 
Warnings: 21 
Notices:  0  

Spannender als der Fehler sind die 21 Warnungen. 

Neue Defaults, die niemand bestellt hat

Der Checker listet Systemvariablen, deren Standardwert sich zwischen 8.4 und 9.7 geändert hat und die in der Konfiguration nicht gesetzt sind. Nach dem Upgrade habe ich nachgesehen, was davon tatsächlich greift. 

SELECT @@gtid_mode, @@enforce_gtid_consistency, @@explain_format; 
SELECT @@innodb_change_buffering, @@innodb_change_buffer_max_size, @@back_log; 
+-------------+----------------------------+------------------+ 
| @@gtid_mode | @@enforce_gtid_consistency | @@explain_format | 
+-------------+----------------------------+------------------+ 
| ON          | ON                         | TREE             | 
+-------------+----------------------------+------------------+ 
+---------------------------+---------------------------------+------------+ 
| @@innodb_change_buffering | @@innodb_change_buffer_max_size | @@back_log | 
+---------------------------+---------------------------------+------------+ 
| all                       |                               5 |      10000 | 
+---------------------------+---------------------------------+------------+ 

Der wichtigste Wert ist gtid_mode. Ein Server, der unter 8.4 ohne GTIDs lief, arbeitet nach dem Upgrade ohne jede Konfigurationsänderung mit GTIDs, inklusive enforce_gtid_consistency. Wer eine Replikation ohne GTIDs betreibt oder Anwendungen hat, die mit den GTID-Einschränkungen nicht zurechtkommen, sollte beide Variablen vor dem Upgrade ausdrücklich in die Konfiguration schreiben.

Auch die übrigen Änderungen haben Folgen. Skripte, die EXPLAIN-Ausgaben auswerten, sehen jetzt das TREE-Format. Der Change Buffer ist wieder aktiv, nachdem 8.4 ihn standardmäßig abgeschaltet hatte. Das Plugin caching_sha2_password rechnet mit 10.000 statt 5.000 Runden und die Group Replication verlangt standardmäßig SSL. Meine Empfehlung ist deshalb einfach: Jeder Wert, auf den sich Ihr Betrieb verlässt, gehört vor dem Upgrade explizit in die Konfigurationsdatei.

Das Upgrade selbst ist unspektakulär

Nach einer Sicherung mit mysqldump und einem langsamen Shutdown mit innodb_fast_shutdown = 0 startet der 9.7-Container auf demselben Datenverzeichnis. Das Upgrade erledigt der Server beim Start selbst. 

[System] [MY-011090] [Server] Data dictionary upgrading from version '80300' to '90200'. 
[System] [MY-013413] [Server] Data dictionary upgrade from version '80300' to '90200' completed. 
[System] [MY-013381] [Server] Server upgrade from '80411' to '90702' started. 
[System] [MY-013381] [Server] Server upgrade from '80411' to '90702' completed.  

Mit Sakila dauerte das rund drei Sekunden. Eine Lektion aus dem Labor gebe ich trotzdem weiter. Der neue Server darf erst starten, wenn der alte nachweislich gestoppt ist. Zwei Instanzen auf einem Datenverzeichnis sind auch mit Containern schnell passiert, wenn ein Stop-Befehl ins Leere läuft. Mein Laborskript prüft das deshalb vor dem Start ausdrücklich. 

Stolperstein mysql_native_password

Hier liegt die eigentliche Überraschung. Der Upgrade Checker hat das Altkonto als Fehler gemeldet, der Server stört sich daran nicht. Er startet ohne Abbruch und hinterlässt nur eine Warnung im Error Log. 

[Warning] [MY-010312] [Server] The plugin 'mysql_native_password' used to authenticate user 'app_alt'@'%' is not loaded. Nobody can currently login using this account.  

 Das Konto steht weiterhin mit dem alten Plugin in mysql.user, ist aber unbrauchbar. Die Anwendung merkt das erst beim Verbindungsaufbau.

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded  

Reparieren lässt sich das auch nach dem Upgrade, im Labor funktionierte die Anmeldung nach einem ALTER USER sofort. Sinnvoller ist es aber, betroffene Konten vorher zu finden und gemeinsam mit den Anwendungsteams umzustellen, denn auch die Treiber der Anwendungen müssen caching_sha2_password unterstützen. 

SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password'; 
 
ALTER USER 'app_alt'@'%' IDENTIFIED WITH caching_sha2_password BY 'Alt_Pw_97!'; 

Neu in 9.7 ist PBKDF2 für caching_sha2_password

9.7 bringt ein zweites Speicherformat für Passwort-Hashes. Standard bleibt CRYPT5 mit SHA256, neu ist PBKDF2 mit SHA512. Gesteuert wird das über die globale, dynamische Variable caching_sha2_password_storage_format. Die Doku beschreibt das Format, nennt aber nicht den exakten Wert und die naheliegende Schreibweise lehnt der Server ab. 

SET GLOBAL caching_sha2_password_storage_format = 'PBKDF2'; 
-- ERROR 1231 (42000): Variable 'caching_sha2_password_storage_format' can't be set to the value of 'PBKDF2' 
 
SET GLOBAL caching_sha2_password_storage_format = 'PBKDF2_SHA512'; 
-- erfolgreich 

Das neue Format greift erst beim nächsten Passwortwechsel, bestehende Hashes bleiben unverändert. Im Labor ließ sich das am Präfix des authentication_string ablesen (Auszug, Hashes gekürzt). 

vor der Umstellung   app_neu  $A$005$...   Passwort unter 8.4 gesetzt 
nach der Migration   app_alt  $A$00A$...   CRYPT5, Passwort unter 9.7 gesetzt 
nach ALTER USER      app_neu  $B$00A$...   PBKDF2_SHA512 

Die Anmeldung mit dem PBKDF2-Hash funktionierte ohne jede Änderung am Client. Am Rande fiel mir auf, dass die Ziffern nach dem Präfix zur Rundenzahl passen, also 005 für die 5.000 Runden unter 8.4 und 00A für die 10.000 Runden unter 9.7. Eine Beschreibung dazu habe ich in der Doku nicht gefunden, ich verstehe es deshalb als Beobachtung. Mit caching_sha2_password_enforce_storage_format (Standard OFF) lässt sich laut Doku erzwingen, dass Konten mit abweichendem Format ihr Passwort neu setzen müssen. Getestet habe ich diese Variante nicht. 

Rolling Upgrades ab 9.7

Ebenfalls neu ist replica_allow_higher_version_source, im Labor standardmäßig ON. Die Variable regelt, ob ein Replica mit niedrigerer Version von einer Quelle mit höherer Version replizieren darf. Für den Schritt von 8.4 auf 9.7 hilft sie noch nicht, denn ein 8.4-Replica kennt sie nicht. Für künftige Upgrades ab 9.7 schafft sie aber Spielraum. Unabhängig davon gilt die alte Regel weiter, nach der zuerst die Replicas und zuletzt die Quelle aktualisiert werden. 

Fallstricke, die die Doku nicht nennt

• 9.7.0 meiden. Percona empfiehlt wegen CVEs mit höherem Schweregrad mindestens 9.7.1 und hat 9.7.0 für den eigenen Server übersprungen. Wer jetzt plant, geht direkt auf 9.7.4.

• Paketquellen festlegen. Mit dem GA-Release hat ein Fehler im mysql-community.repo (Bug #120315) auf manchen Systemen still das 8.4-Repository deaktiviert und 9.7 aktiviert, sodass Routine-Updates die Hauptversion gewechselt haben.

• Konfiguration aufräumen. Mit 9.7 entfallen unter anderem die Variablen replica_parallel_type und group_replication_allow_local_lower_version_join. Stehen sie noch in der Konfiguration, gehört das vor dem Upgrade bereinigt.

• Die Sicherung ist der Rückweg. Ein Downgrade über die LTS-Grenze zurück auf 8.4 ist nicht vorgesehen.

Empfehlungen

1. Den Upgrade Checker mit MySQL Shell der Zielversion ausführen und jede Warnung zu geänderten Defaults bewerten.
2. Werte, auf die Sie sich verlassen, vor dem Upgrade in die Konfiguration schreiben, allen voran gtid_mode und enforce_gtid_consistency.
3. Konten mit mysql_native_password vorab migrieren und die Treiber der Anwendungen prüfen.
4. Vollständig sichern, langsam herunterfahren und das Upgrade zuerst an einer Kopie testen.
5. In Replikationstopologien die Replicas zuerst aktualisieren.
6. Direkt auf den aktuellen 9.7-Patchstand gehen und die Paketquelle fest auf 9.7 LTS setzen.

Fazit

Das eigentliche Upgrade von 8.4 auf 9.7 ist unspektakulär, im Labor dauerte es Sekunden. Über Erfolg oder Ärger entscheidet die Vorbereitung. Ein Konto mit mysql_native_password fällt beim Start nicht auf, sondern erst, wenn sich die Anwendung nicht mehr anmelden kann. Geänderte Defaults wie gtid_mode verändern das Verhalten eines Servers, ohne dass jemand die Konfiguration angefasst hat. Wer beides vorher erledigt, hat mit 9.7 eine solide Basis für die nächsten Jahre.

Wo stehen eure Systeme heute und welche Hürden seht ihr beim Umstieg auf 9.7? Schreibt mir gern eure Erfahrungen. Nächste Woche geht es in Teil 2 um OpenTelemetry. Wer die Themen der Serie vertiefen möchte, findet sie auch im ORDIX-Seminar „MySQL Administration“, in dem ich als Referent die Neuerungen der aktuellen LTS-Version behandle.

Quellen

Seminarempfehlung