MySQL 8.0 EOL: Wechsel auf MariaDB

Der Stichtag ist verstrichen: 30. April 2026

Oracle hat den Support für MySQL 8.0 Community am 30. April 2026 beendet. End of Life, kurz EOL, heißt: seit diesem Datum keine Updates mehr, auch keine für neu entdeckte Sicherheitslücken. Für einen Onlineshop ist das kein Randthema, denn die Datenbank hält Kundendaten, Bestellungen und Zahlungsbezüge. Jede seither entdeckte Lücke in der Datenbankschicht bleibt bei einem reinen Oracle-MySQL 8.0 dauerhaft offen, ein Risiko, das über den Shop hinausreicht.

Der Nachfolger im 8.x-Zweig ist MySQL 8.4 LTS. LTS steht für Long Term Support, also eine Version mit besonders langer Update-Garantie. Trotzdem ist 8.4 für einen Shopware-Shop nicht automatisch die naheliegende Wahl. Der ruhigere Weg führt in vielen Fällen zu MariaDB. Warum das so ist und wie der Umzug abläuft, steht in diesem Beitrag. Die Einordnung aller EOL-Termine rund um Shopware, PHP und Datenbank liefert der Überblicksbeitrag zu End of Life.

Wie akut ist es wirklich?

Ein wichtiger Punkt zur Einordnung: Ein Shop, der weiter auf MySQL 8.0 läuft, war am 1. Mai 2026 nicht schlagartig ungeschützt, und ist es bis heute nicht zwangsläufig. Wer die Datenbank nicht als reines Oracle-Paket betreibt, bekommt Sicherheits-Patches oft noch länger. Percona Server für MySQL 8.0, ein weit verbreiteter, quelloffener Nachbau, liefert über das Oracle-Datum hinaus noch mehrjährige Security-Backports, und auch Managed-Hoster sowie die Datenbankpakete der Linux-Distributionen pflegen Sicherheitskorrekturen häufig weiter ein.

Akut betroffen ist damit vor allem, wer ein selbst installiertes Oracle-MySQL 8.0 ohne solchen Zusatz-Support fährt: Dieser Shop läuft seit April 2026 ohne Sicherheitsupdates und gehört zügig umgezogen. Wer über Percona, Hoster oder Distribution noch Patches bekommt, hat einen Puffer, aber keinen Freibrief. Dieser Puffer ist genau die Gelegenheit, den Umstieg sauber vorzubereiten und zu testen, statt ihn unter Zeitdruck an einem Freitagabend zu erzwingen.

Warum MariaDB und nicht MySQL 8.4

MariaDB ist aus MySQL hervorgegangen und über Jahre der De-facto-Standard im Shopware-Umfeld geblieben. Der offizielle Hosting-Leitfaden von Shopware nennt MariaDB an erster Stelle, die meisten Hoster liefern sie als Voreinstellung aus, und in der Praxis läuft die Mehrheit der Shops ohnehin schon darauf. Ein Wechsel von MySQL 8.0 auf MariaDB bewegt sich damit auf gut ausgetretenem Boden.

Der stärkste Grund gegen MySQL 8.4 ist eine strengere Prüfung von Fremdschlüsseln. Ein Fremdschlüssel ist die Verknüpfung zwischen zwei Tabellen, etwa zwischen einer Bestellung und dem zugehörigen Kunden. MySQL 8.4 verlangt hier eine formale Sauberkeit, an die viele Erweiterungen und ältere Datenbestände noch nicht angepasst sind. Dass das kein theoretisches Problem ist, zeigt Shopware selbst: Der Core bringt einen eigenen Schutzmechanismus mit, den NonStandardFkGuard, der genau solche nicht ganz regelkonformen Fremdschlüssel abfangen soll. MariaDB ist an dieser Stelle nachsichtiger, und die Zielversion MariaDB 11.4 LTS wird über Jahre mit Updates versorgt.

Wer sein Datenbankmodell komplett unter Kontrolle hat und alle Erweiterungen kennt, kann MySQL 8.4 durchaus einsetzen. Für einen gewachsenen Shop mit Plugins aus verschiedenen Quellen ist MariaDB 11.4 der Weg mit den wenigsten Überraschungen.

Der Umzug mit shopware-cli

Für den Datenbankumzug hilft shopware-cli, das offene Kommandozeilen-Werkzeug rund um Shopware (Quellcode auf GitHub). Sein Befehl project dump erzeugt einen sauberen Export der Datenbank in eine SQL-Datei, die sich anschließend in die neue MariaDB einlesen lässt. Praktisch daran: Der Befehl bringt seine eigene Dump-Logik mit und ist nicht auf ein passendes externes mysqldump-Programm angewiesen.

Ein typischer Aufruf sieht so aus:

shopware-cli project dump \
  --host 127.0.0.1 \
  --username shopware \
  --password \
  --clean \
  --output shop.sql \
  shopware

Das letzte Argument ist der Datenbankname. Ohne Wert hinter --password fragt das Werkzeug das Kennwort interaktiv ab, statt es in der Befehlszeile und damit in der Shell-Historie zu hinterlassen. Die Option --clean lässt verzichtbare Massendaten wie den Warenkorb-Zwischenspeicher und die Nachrichten-Warteschlange weg, was den Export kleiner und den Import schneller macht. Für einen echten Umzug bleiben die eigentlichen Shop-Daten dabei vollständig erhalten. Wer den Export zusätzlich verkleinern will, hängt --compression gzip an.

Anschließend wird die Datei in die neue MariaDB eingelesen:

mariadb -u shopware -p shopware_neu < shop.sql

Worauf beim Import zu achten ist

Ein sauberer Shopware-Export ist beim Import meist unkritisch, denn Shopware legt seine Tabellen von sich aus mit der Sortierregel utf8mb4_unicode_ci an, die MariaDB kennt. Die Sortierregel, im Fachjargon Collation, legt fest, wie Text verglichen und sortiert wird.

Der Server-Standard von MySQL 8 ist dagegen utf8mb4_0900_ai_ci, eine MySQL-eigene Regel auf Basis von Unicode 9.0.0. In den eigentlichen Shopware-Tabellen steht sie normalerweise nicht, sie kann aber bei einzelnen Tabellen auftauchen, die ohne ausdrückliche Collation angelegt wurden, etwa von Erweiterungen. Bricht der Import mit einer Meldung wie Unknown collation: 'utf8mb4_0900_ai_ci' ab, hilft ein Suchen-und-Ersetzen über die Datei, hin zu der von Shopware verwendeten Regel:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' shop.sql

Ob die Ziel-MariaDB die MySQL-Collation von sich aus akzeptiert, hängt von ihrer Version ab, deshalb ist der Blick in die Fehlermeldung des Imports die verlässlichere Prüfung als eine feste Regel.

Der zweite Punkt betrifft den Datenbank-Benutzer. MySQL 8 legt Konten standardmäßig mit dem Anmeldeverfahren caching_sha2_password an, MariaDB nutzt ein anderes. Der Benutzer für den Shop wird auf dem MariaDB-Server deshalb ohnehin neu angelegt; anschließend kommen die Zugangsdaten in die Shopware-Konfiguration (.env).

Nach dem Import gegenprüfen

Steht die Datenbank, wird der Cache geleert und die Migrationen werden geprüft, damit Shopware und Schema sicher zusammenpassen:

bin/console cache:clear
bin/console database:migrate --all

Zum Abschluss die wichtigsten Abläufe im Shop einmal von Hand durchgehen: Startseite, eine Kategorie, ein Produkt, ein Testkauf bis zur Bestellbestätigung und ein Blick in die Administration. Erst wenn das sauber läuft, wird die alte Datenbank abgeschaltet.

Was jetzt zu tun ist

Der Stichtag im April 2026 liegt bereits einige Monate zurück, und nur dank der Backports von Percona und den Distributionen ist die Lage für viele Shops noch nicht brenzlig. Dieser Puffer ist kein Grund zum Abwarten, sondern die Gelegenheit, den Wechsel sauber statt hektisch anzugehen: die Zielumgebung mit MariaDB 11.4 aufsetzen, den Umzug an einer Kopie testen, die Importmeldungen im Blick behalten und den Livegang zeitnah planen. Wer ein reines Oracle-MySQL 8.0 ohne Backport-Support fährt, sollte damit nicht länger warten.

Ein Datenbankwechsel scheitert in der Praxis selten an der Technik, sondern an der Zuständigkeit: Der Shop läuft, niemand verfolgt EOL-Termine, und die Datenbankversion steht auf keiner Liste. Wer diesen Umzug nicht selbst gehen möchte, findet über die Shopware-Wartung Unterstützung, von der Zielumgebung über den getesteten Umzug bis zur Gegenprobe nach dem Livegang.