MySQL 5.7 auf 8.0 upgraden: Praxisleitfaden für Magento-Shops

1. Warum das Upgrade keine reine Formsache ist

Oracle stellt für den Wechsel von MySQL 5.7 auf 8.0 offiziell keinen unterstützten Downgrade-Pfad zur Verfügung. Sobald der Server einmal mit den neuen Data-Dictionary-Strukturen von 8.0 gestartet wurde, lässt sich die Instanz nicht mehr einfach mit einer alten 5.7-Binärversion zurückstarten. Jede Upgrade-Planung muss diese Tatsache von Anfang an berücksichtigen, statt sie erst im Problemfall zu entdecken.

Hinzu kommt, dass MySQL 8.0 in mehreren zentralen Bereichen bewusst andere Standardwerte gewählt hat als 5.7, nicht aus Versehen, sondern als bewusste Design-Entscheidung. Wer ein Upgrade als reinen Versionswechsel ohne inhaltliche Prüfung behandelt, riskiert stillschweigend veränderte Ausführungspläne, fehlschlagende Zeichensatz-Vergleiche oder sogar einen Server, der wegen einer inzwischen ungültigen Konfigurationsoption gar nicht mehr startet.

2. Optimizer-Verhalten: stillschweigend andere Ausführungspläne

MySQL 8.0 bringt ein überarbeitetes Kostenmodell für den Optimizer mit, ergänzt um Histogramm-Statistiken, die gezielt für Spalten ohne Index erzeugt werden können und die Datenverteilung deutlich genauer abbilden als die bisherigen, rein indexbasierten Statistiken. In der Praxis bedeutet das: dieselbe Abfrage, dieselben Indizes, aber ein anderer Ausführungsplan, weil der Optimizer nun andere Kosten für Alternativen berechnet.

Zusätzlich unterstützt MySQL 8.0 Hash-Joins für Fälle, in denen 5.7 noch auf verschachtelte Loop-Joins ohne passenden Index zurückfiel, was bestimmte komplexe Reporting-Abfragen deutlich beschleunigen, andere hingegen unerwartet verlangsamen kann. Vor jedem produktiven Upgrade lohnt sich deshalb ein Vergleich der EXPLAIN-Pläne für die geschäftskritischsten, langsamsten Abfragen zwischen alter und neuer Version, nicht nur ein pauschaler Blick auf die Gesamtlast.

3. Die Standard-Collation-Falle: utf8mb4_general_ci vs. utf8mb4_0900_ai_ci

MySQL 8.0 ändert die Standard-Kollation für utf8mb4 von utf8mb4_general_ci auf utf8mb4_0900_ai_ci, eine deutlich präzisere, Unicode-9.0-basierte Sortierreihenfolge. Magentos eigenes Schema setzt die Kollation für seine Tabellen explizit in db_schema.xml, sodass bestehende Kerntabellen davon direkt nicht betroffen sind, das Risiko liegt jedoch bei neu angelegten Tabellen aus Drittmodulen, temporären Tabellen und beim Vergleich von Zeichenketten unterschiedlicher Herkunft.

Treffen zwei Zeichenketten mit unterschiedlicher Kollation in einem JOIN oder WHERE aufeinander, etwa eine 5.7-Alttabelle mit der alten Standard-Kollation und eine neu angelegte 8.0-Tabelle mit der neuen, quittiert MySQL das mit dem Fehler Illegal mix of collations. Vor dem Upgrade lohnt sich deshalb ein systematischer Check aller Tabellen und Spalten auf ihre tatsächlich gesetzte Kollation, um Inkonsistenzen frühzeitig zu finden statt erst bei einem fehlschlagenden Checkout.

-- Alle Tabellen mit von der Standard-Kollation abweichender Einstellung finden
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'magento'
  AND TABLE_COLLATION NOT LIKE 'utf8mb4_general_ci';

4. Entfernte Query-Cache-Konfiguration

Der Query Cache war bereits in MySQL 5.7.20 als veraltet markiert, in MySQL 8.0 ist er vollständig entfernt, inklusive sämtlicher zugehöriger Konfigurationsoptionen wie query_cache_size und query_cache_type. Enthält eine bestehende my.cnf, die noch aus 5.6- oder frühen 5.7-Zeiten stammt, eine dieser Optionen, startet der MySQL-8.0-Server danach überhaupt nicht mehr, sondern bricht sofort mit einer klaren Fehlermeldung im Error-Log ab.

Für Magento-Shops ist das in der Praxis meist unkritisch, weil Full Page Cache und Objekt-Cache ohnehin über Redis oder Varnish laufen und der Query Cache selbst bei aktiviertem MySQL-5.7-Betrieb kaum genutzt wurde. Wichtig ist trotzdem, vor dem Upgrade die produktive my.cnf systematisch gegen die Liste entfernter Variablen in der offiziellen Upgrade-Dokumentation zu prüfen, statt erst beim gescheiterten Neustart davon zu erfahren.

5. Authentifizierung: caching_sha2_password als neuer Standard

MySQL 8.0 setzt als Standard-Authentifizierungs-Plugin caching_sha2_password statt des bisherigen mysql_native_password. Neu angelegte Benutzer ohne explizite Angabe verwenden damit automatisch das neue Verfahren, was bei älteren PHP-Treibern oder Verbindungsbibliotheken, die caching_sha2_password nicht unterstützen, zu Verbindungsfehlern direkt nach dem Upgrade führen kann, insbesondere bei unverschlüsselten Verbindungen ohne SSL.

Moderne PHP-Versionen mit aktuellem mysqlnd-Treiber, wie sie in einem Magento-2.4.8-Stack mit PHP 8.4 laufen, unterstützen caching_sha2_password vollständig, sodass in den meisten Fällen kein Handlungsbedarf besteht. Bestehende, bereits vor dem Upgrade angelegte Benutzerkonten behalten ihr ursprüngliches Authentifizierungsverfahren bei, ein Upgrade ändert es nicht automatisch, sicherheitshalber lohnt sich trotzdem ein expliziter Test aller produktiven Verbindungsstrings direkt nach dem Upgrade.

-- Aktuelles Authentifizierungs-Plugin eines Benutzers pruefen
SELECT user, host, plugin FROM mysql.user WHERE user = 'magento_app';

-- Bei Bedarf explizit auf mysql_native_password zuruecksetzen
ALTER USER 'magento_app'@'%' IDENTIFIED WITH mysql_native_password BY 'ein-sicheres-passwort';

6. Reservierte Schlüsselwörter und weitere Datentyp-Feinheiten

Mit jeder MySQL-Version kommen neue reservierte Schlüsselwörter hinzu, die zuvor problemlos als Tabellen- oder Spaltenname verwendet werden konnten. In MySQL 8.0 zählen dazu unter anderem RANK, ROW, GROUPS, WINDOW und mehrere weitere, die im Zusammenhang mit den neu eingeführten Fenster-Funktionen stehen. Eine bestehende Custom-Tabelle mit einer Spalte namens rank ohne Backtick-Quoting funktioniert unter 5.7 problemlos und erzeugt unter 8.0 einen Syntaxfehler.

Vor dem Upgrade lohnt sich deshalb ein Abgleich sämtlicher Tabellen- und Spaltennamen im eigenen Schema, insbesondere in Custom-Modulen und Drittanbieter-Extensions, gegen die aktuelle Liste reservierter Wörter in der MySQL-8.0-Dokumentation. Bereits bestehende Objekte mit einem jetzt reservierten Namen funktionieren zwar meist weiterhin, sofern konsequent mit Backticks referenziert wird, neue DDL-Anweisungen ohne Quoting schlagen jedoch fehl.

7. Der mysql_upgrade-Workflow in der Praxis

Seit MySQL 8.0.16 ist der separate Befehl mysql_upgrade überflüssig geworden, der Server prüft und aktualisiert die internen Systemtabellen sowie das Data Dictionary beim ersten Start nach einem Binär-Upgrade automatisch selbst. Das eigentliche Vorgehen läuft deshalb über einen klassischen In-Place-Upgrade-Pfad: Server stoppen, neue Binärpakete installieren, Server mit denselben Datenverzeichnissen neu starten und den Fortschritt im Error-Log verfolgen.

Vor dem eigentlichen Upgrade prüft das in MySQL Shell integrierte Werkzeug util.checkForServerUpgrade() proaktiv auf bekannte Inkompatibilitäten wie reservierte Wörter, entfernte Systemvariablen oder problematische Kollationen, ohne selbst irgendetwas zu verändern. Dieser Pre-Check-Schritt sollte immer vor dem eigentlichen Upgrade-Wartungsfenster laufen, damit gefundene Probleme in Ruhe behoben werden können, statt mitten im Wartungsfenster überrascht zu werden.

# Pre-Check vor dem eigentlichen Upgrade über MySQL Shell
mysqlsh -- util check-for-server-upgrade --user=root --password

# Nach Installation der neuen Binaerpakete: Server neu starten
# und den automatischen Upgrade-Vorgang im Error-Log beobachten
bin/log mysql/error.log

8. Teststrategie vor dem produktiven Upgrade

Ein produktives Upgrade sollte niemals der erste Test sein. Der sicherste Weg ist eine vollständige Kopie der Produktionsdatenbank auf einer separaten Staging-Instanz, die dort mit der neuen Version 8.0 hochgezogen wird, gefolgt von einem vollständigen Magento-Reindex sowie dem produktiven Testsuite-Lauf, inklusive der geschäftskritischsten Checkout- und Bestellprozesse.

Ergänzend lohnt sich ein direkter Vorher-Nachher-Vergleich des Slow Query Logs unter vergleichbarer, simulierter Last, um Abfragen zu identifizieren, die durch die veränderten Optimizer-Entscheidungen langsamer geworden sind. Erst wenn diese Tests über mehrere Tage stabil und ohne neue kritische Fehler durchlaufen, ist das produktive Wartungsfenster der richtige nächste Schritt.

9. Rollback-Strategie, falls das Upgrade Probleme verursacht

Da ein offizieller Downgrade-Pfad von 8.0 zurück auf 5.7 nicht existiert, muss die Rollback-Strategie vor dem Upgrade feststehen, nicht danach improvisiert werden. Die zuverlässigste Absicherung ist ein vollständiges, konsistentes Backup unmittelbar vor dem Upgrade, idealerweise per Snapshot auf Dateisystem- oder Storage-Ebene, das im Fehlerfall die alte 5.7-Instanz binnen Minuten wiederherstellen kann, statt einen langwierigen logischen Restore aus einem mysqldump zu benötigen.

Für Umgebungen mit ausreichend Kapazität ist ein Blue-Green-Ansatz die robustere Alternative: ein bislang nicht aktualisierter 5.7-Replica bleibt während des Upgrade-Fensters unangetastet im Hintergrund verfügbar und kann im Ernstfall innerhalb weniger Minuten zum neuen Primärserver befördert werden, während die problematische 8.0-Instanz in Ruhe analysiert wird. Ein klar definiertes, zeitlich begrenztes Wartungsfenster mit einem festen Abbruchkriterium gehört in jedem Fall zur Planung dazu.

10. Zusammenfassung

11. FAQ: MySQL 5.7 auf 8.0: Upgrade-Leitfaden