MySQL 8.0 auf 8.4 upgraden: sicher mit Docker Compose

Für ein Upgrade von MySQL 8.0 auf 8.4 in Docker sicherst du die Datenbank, stellst das Image auf einen festen mysql:8.4.x-Tag um und entfernst im selben Schritt das Flag --default-authentication-plugin, das 8.4 nicht mehr kennt. Danach startest du docker compose up -d, und der Server aktualisiert das Datenverzeichnis beim ersten Start selbst. Der Weg ist eine Einbahnstraße: Ein 8.4-Datenverzeichnis startet nicht mehr unter 8.0, das Backup ist also dein einziger Rückweg.

Warum jetzt von MySQL 8.0 auf 8.4 wechseln?

Weil MySQL 8.0 nicht mehr gepflegt wird: Oracle schreibt, dass MySQL 8.0 im April 2026 das End of Life erreicht hat; 8.0.46 ist das letzte Bugfix-Release. Ein 8.0-Container läuft weiter, bekommt aber keine Sicherheitsupdates mehr, und jede neue Lücke im Server bleibt auf deinem Server offen – egal ob er bei Hetzner, IONOS oder Strato steht.

MySQL 8.4 ist die Long-Term-Support-Reihe (LTS) nach 8.0. Die offiziellen Upgrade-Pfade nennen „8.0 → 8.4.x LTS“ als unterstützt per In-place-Upgrade, per logischem Dump und Import oder per Replikation. Für einen einzelnen Container ist das In-place-Upgrade am einfachsten: Du startest das neue Image auf dem alten Volume, und der Server aktualisiert Data Dictionary und Systemtabellen selbst. Das erledigt er seit MySQL 8.0.16 allein, ein separater mysql_upgrade-Lauf ist nicht nötig.

Zwei Dinge auf Docker Hub machen das Thema dringend. Erstens führt das offizielle mysql-Image keinen 8.0-Tag mehr unter den unterstützten Tags; 8.4 und 8 zeigen beide auf 8.4.13. Zweitens sind die beweglichen Tags weitergezogen: lts zeigt auf 9.7, latest auf die Innovation-Reihe 26.x. Eine Compose-Datei mit nicht fixiertem image: mysql oder mysql:lts kann beim nächsten docker compose pull über 8.4 hinwegspringen – in eine Version, in der es mysql_native_password gar nicht mehr gibt.

⚠️ Achtung: Fixiere das MySQL-Image immer auf eine Reihe oder eine Patch-Version (mysql:8.4 oder mysql:8.4.13). Ein Major-Wechsel sollte eine bewusste Entscheidung mit Backup in der Hand sein, kein Nebeneffekt von pull.

Was geht kaputt, wenn du das Image auf mysql:8.4 umstellst?

Am häufigsten beendet sich der Container sofort, weil sein command: noch --default-authentication-plugin=mysql_native_password übergibt – eine Serveroption, die 8.4 entfernt hat. Viele Compose-Dateien für MySQL 8.0 enthalten genau diese Zeile:

services:
  db:
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    volumes:
      - dbdata:/var/lib/mysql

Mit mysql:8.4 gestartet, stoppt dieser Dienst, bevor er das Datenverzeichnis öffnet, und im Log steht:

$ docker compose logs db
db  | [ERROR] [MY-000067] [Server] unknown variable 'default-authentication-plugin=mysql_native_password'.
db  | [ERROR] [MY-010119] [Server] Aborting

Laut What Is New in MySQL 8.4 ist eine entfernte Option ein Fehler, keine Warnung. Die gute Nachricht: Der Server bricht ab, bevor er deine Daten anfasst – es wurde also noch nichts aktualisiert. Dasselbe gilt für eine my.cnf, die nach /etc/mysql/conf.d/ gemountet ist; prüfe sie zusammen mit der command:-Zeile.

Entfernte Optionen und ihr Ersatz

Stand: November 2026. Quelle: MySQL 8.4 Reference Manual, What Is New.

Änderungen, die den Start nicht verhindern, aber das Verhalten ändern

• Authentifizierung. mysql_native_password ist in 8.4 standardmäßig deaktiviert. Ein App-Benutzer, der unter 8.0 mit diesem Plugin angelegt wurde, bekommt ERROR 1045 (28000): Access denied, und das Anlegen eines solchen Kontos scheitert mit ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded. Beide Auswege stehen weiter unten.
• Nicht standardkonforme Fremdschlüssel. Fremdschlüssel auf nicht eindeutige oder partielle Schlüssel werden in neuen CREATE TABLE-Anweisungen abgelehnt, solange restrict_fk_on_non_standard_key auf ON steht (Standard). Bestehende Tabellen werden problemlos aktualisiert, der Server protokolliert für jeden solchen Schlüssel eine Warnung. Migrationen, die neue anlegen, schlagen fehl.
• Neue reservierte Wörter. MANUAL, PARALLEL, QUALIFY und TABLESAMPLE sind jetzt reserviert. Eine Spalte namens manual muss in rohem SQL in Backticks stehen; ORMs, die Bezeichner immer quoten, sind nicht betroffen.
• InnoDB-Standardwerte. Mehrere Defaults haben sich geändert – relevant auf kleinen VPS mit langsamen Platten. Wenn dein Setup von den alten Werten abhängt, setze sie explizit.

Stand: November 2026. Quelle: MySQL 8.4 Reference Manual, What Is New.

Wie sicherst du einen MySQL-Container vor dem Upgrade?

Mach zwei Backups: einen logischen Dump mit mysqldump, den du in jede MySQL-Version einspielen kannst, und eine Kopie des gestoppten Daten-Volumes, die dich am schnellsten exakt auf den Stand unter 8.0 zurückbringt. Dann beweise, dass sich der Dump wiederherstellen lässt.

Zwei Kopien braucht es, weil das Upgrade nur in eine Richtung geht. Die Downgrade-Dokumentation von MySQL erlaubt den Weg von 8.4 zurück auf 8.0 nur per logischem Dump und Import (oder Replikation) und nur zum Zurückrollen. Ein 8.0-Server öffnet ein 8.4-Datenverzeichnis nicht einfach so.

Lass vor dem Backup den Upgrade Checker laufen. Er liest den laufenden 8.0-Server und listet entfernte Optionen, Probleme mit der Authentifizierung, reservierte Wörter als Bezeichner und weitere Inkompatibilitäten. MySQL Shell steckt im mysql:8.4-Image, du installierst also nichts; ohne --target-version prüft der Checker gegen die eigene Shell-Version:

# find the network of your compose project, e.g. myapp_default
docker network ls

# run the 8.4 upgrade checker (MySQL Shell ships in the mysql:8.4 image)
# against the 8.0 server that is still running
docker run --rm -it --network myapp_default mysql:8.4.13 \
  mysqlsh -- util checkForServerUpgrade root@db:3306

Lies jeden Error im Bericht; Warnungen zu mysql_native_password sind erwartbar und werden unten behandelt. Dann stoppst du alles, was schreibt, und erstellst die Backups. Ersetze myapp_ durch den Namen deines Compose-Projekts und die Dienstnamen durch deine eigenen:

# 1. stop everything that writes to the database (app, workers, scheduler)
docker compose stop app queue scheduler

# 2. logical dump of the application database
docker compose exec -T db sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \
  --single-transaction --routines --triggers --events \
  --databases "$MYSQL_DATABASE"' | gzip > db-before-8.4.sql.gz

# 3. physical copy of the stopped data volume
docker compose stop db
docker volume ls | grep dbdata            # e.g. myapp_dbdata
docker run --rm -v myapp_dbdata:/var/lib/mysql:ro -v "$PWD":/backup alpine \
  tar czf /backup/dbdata-8.0.tgz -C /var/lib/mysql .

Der Dump nutzt --single-transaction – einen konsistenten Snapshot der InnoDB-Tabellen ohne Sperren – und enthält Routinen, Trigger und Events. Die Volume-Kopie entsteht erst nach docker compose stop db: Dateien eines laufenden MySQL-Servers zu kopieren, liefert ein Datenverzeichnis, das womöglich nicht startet. Auch die Upgrade-Vorbereitung von MySQL verlangt ein sauberes Herunterfahren; docker compose stop leistet das, solange der Server innerhalb des Stop-Timeouts fertig wird (standardmäßig 10 Sekunden; bei großem Buffer Pool mit stop_grace_period erhöhen).

Teste den Dump auf einem Wegwerf-Container mit 8.0, damit du weißt, dass die Datei vollständig ist, bevor du sie brauchst:

docker run -d --name restore-test -e MYSQL_ROOT_PASSWORD=test mysql:8.0
docker logs -f restore-test               # wait for "ready for connections", then Ctrl+C
gunzip -c db-before-8.4.sql.gz | docker exec -i restore-test mysql -uroot -ptest
docker exec restore-test mysql -uroot -ptest -e \
  "SELECT table_schema, COUNT(*) AS tables FROM information_schema.tables GROUP BY table_schema;"
docker rm -f restore-test

Lege beide Dateien außerhalb des Servers ab, mindestens auf einer anderen Platte – etwa in einer Hetzner Storage Box. Ein Backup auf derselben Platte wie die Datenbank schützt nicht vor deren Ausfall.

Was tun mit mysql_native_password?

Entweder lässt du es vorerst mit --mysql-native-password=ON eingeschaltet, oder du stellst alle Konten vor oder direkt nach dem Upgrade auf caching_sha2_password um. Beides funktioniert unter 8.4; nur Letzteres funktioniert auch unter MySQL 9, wo das Plugin entfernt ist.

Finde zuerst heraus, welches Konto welches Plugin nutzt. Führe das vor dem Upgrade auf dem 8.0-Server aus:

SELECT user, host, plugin
FROM mysql.user
ORDER BY plugin, user;

Zeigen alle App-Konten bereits caching_sha2_password (seit MySQL 8.0 Standard für neue Konten), brauchst du das native Plugin nicht: altes Flag entfernen, die Standard-authentication_policy *,, lassen, fertig. Konten mit mysql_native_password gibt es meist, weil die Compose-Datei dieses Plugin beim ersten Anlegen der Datenbank erzwungen hat, oft wegen eines alten PHP-Treibers.

Option A: native Authentifizierung behalten

Ergänze --mysql-native-password=ON in den Server-Flags. Sollen auch neue Konten das native Plugin nutzen (etwa weil der Installer deiner App selbst einen Benutzer anlegt), ersetze die entfernte Option durch --authentication-policy=mysql_native_password,,. Die Referenz zu authentication_policy erklärt das Format: bis zu drei kommagetrennte Faktoren; das erste Element legt das Plugin für den ersten Faktor fest, leere Elemente lassen den optionalen zweiten und dritten Faktor offen. Die weichere Variante *:mysql_native_password,, macht native zum Standard, erlaubt aber auch andere Plugins.

Option B: Konten auf caching_sha2_password umstellen

Starte 8.4 mit eingeschaltetem nativen Plugin (Option A), damit sich die Konten noch anmelden können, und stelle sie dann einzeln um. Wenn keines mehr übrig ist, startest du ohne das Flag neu:

-- move one account to the 8.4 default plugin (keep or change the password)
ALTER USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'the-password';

-- check the result
SELECT user, host, plugin FROM mysql.user WHERE user = 'app_user';

Prüfe vor dem Abschalten, ob sich jeder Client so anmelden kann. Aktuelle MySQL-Treiber für PHP (mysqlnd), Python und Node.js unterstützen caching_sha2_password. Die erste Anmeldung einer neuen Sitzung braucht entweder TLS oder einen RSA-Schlüsselaustausch; MySQL erzeugt beim ersten Start TLS-Zertifikate, Verbindungen zwischen Containern laufen daher normalerweise ohne weitere Konfiguration über TLS. Die übliche Überraschung sind Backup-Tools: Nutzt dein Backup-Container das mysqldump von MariaDB, mach einen echten Dump mit dem umgestellten Konto, bevor du das native Plugin entfernst.

MySQL 8.0 auf 8.4 in Docker Compose, Schritt für Schritt

Ändere Image und Server-Flags in einem Schritt, starte nur die Datenbank, warte im Log auf das Ende des Data-Dictionary-Upgrades und starte dann den Rest.

1. Den db-Dienst bearbeiten

   Fixiere mysql:8.4.13 (oder mysql:8.4, wenn du bei jedem Pull Patch-Updates willst) und ersetze das alte Flag. Das Beispiel behält die native Authentifizierung – die sichere Wahl für eine bestehende Datenbank; lass die beiden Auth-Flags weg, wenn alle Konten schon caching_sha2_password nutzen.

   services:
     db:
       image: mysql:8.4.13
       command: >-
         --mysql-native-password=ON
         --authentication-policy=mysql_native_password,,
         --character-set-server=utf8mb4
         --collation-server=utf8mb4_unicode_ci
       volumes:
         - dbdata:/var/lib/mysql

2. Image ziehen und nur die Datenbank starten

   Startest du db allein, verbindet sich die Anwendung nicht, während der Server seine Systemtabellen aktualisiert.

   docker compose pull db
   docker compose up -d db
   docker compose logs -f db

3. Das Upgrade im Log verfolgen

   Beim ersten Start erkennt der Server das 8.0-Datenverzeichnis, aktualisiert Data Dictionary und Systemschemata und nimmt dann Verbindungen an. Erwarte Zeilen wie diese (gekürzt; deine Versionsnummern weichen ab):

   [System] [MY-013381] [Server] Server upgrade from '80046' to '80413' started.
   [System] [MY-013381] [Server] Server upgrade from '80046' to '80413' completed.
   [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.4.13'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.

   Der Server aktualisiert Metadaten und Systemtabellen, nicht die Zeilen deiner Tabellen – bei einer typischen App-Datenbank ist das eine kurze Pause. Stoppe den Container währenddessen nicht. Steht stattdessen ein Fehler im Log, macht der Server laut Upgrade-Dokumentation seine Änderungen am Datenverzeichnis rückgängig; behebe das gemeldete Problem und starte erneut.

4. Die Anwendung starten

   Führe docker compose up -d für das ganze Projekt aus. Wartet die App per Healthcheck auf die Datenbank (mysqladmin ping funktioniert unter 8.4 unverändert), startet sie von selbst, sobald db gesund ist.

5. Alte Compose-Datei und Backups behalten

   Lösche .tgz und Dump erst nach einigen Tagen normalen Betriebs. Sie sind der einzige Weg zurück.

ℹ️ Hinweis: docker compose pull ändert nie deine Compose-Datei. Liefert ein App-Release eine neue docker-compose.yml mit mysql:8.4, musst du diese Datei trotzdem in deine Installation übernehmen (oder den db-Dienst zusammenführen), bevor sich etwas ändert.

Wie prüfst du, ob das Upgrade geklappt hat?

Prüfe vier Dinge: Der Server meldet 8.4, Zeichensatz und Kollationen sind unverändert, die Anwendung meldet sich an und sieht alle Migrationen, und dein Backup-Befehl erzeugt weiterhin einen Dump.

# server version and character set
docker compose exec db mysql -uroot -p -e \
  "SELECT VERSION(); SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server';"

# table collations per schema (compare with the same query before the upgrade)
docker compose exec db mysql -uroot -p -e \
  "SELECT table_schema, table_collation, COUNT(*) FROM information_schema.tables
   WHERE table_schema NOT IN ('mysql','sys','information_schema','performance_schema')
   GROUP BY 1, 2;"

# the application still sees all its migrations (Laravel example)
docker compose exec app php artisan migrate:status

# a dump still works with the client your backups use
docker compose exec -T db sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \
  --no-data --databases "$MYSQL_DATABASE"' > /dev/null && echo "dump OK"

Vergleiche die Kollations-Abfrage mit ihrer Ausgabe vor dem Upgrade. Ein In-place-Upgrade lässt bestehende Tabellen unverändert; ein Unterschied bedeutet meist, dass eine Migration eine Tabelle unter anderen Server-Defaults neu angelegt hat. Behalte die Flags --character-set-server und --collation-server aus 8.0 bei, damit neue Tabellen zu den alten passen – für Umlaute bleibst du bei utf8mb4.

Dann nutze die Anwendung: anmelden, etwas speichern, einen Hintergrundjob laufen lassen und ein geplantes Backup auslösen. Schau noch einmal ins MySQL-Log nach Warnungen zu Fremdschlüsseln oder veralteten Optionen und behebe sie, solange du noch weißt, was du geändert hast.

Kannst du von 8.4 zurück auf 8.0?

Nur über ein Backup. MySQL unterstützt kein In-place-Downgrade von 8.4 auf 8.0; die Downgrade-Tabelle erlaubt nur logischen Dump und Import oder Replikation, und das nur zum Zurückrollen, wenn auf den Daten keine neuen 8.4-Funktionen genutzt wurden.

Praktisch gibt es zwei Wege. Ist das Upgrade gescheitert oder verhält sich die App binnen Minuten falsch, spielst du die Kopie des gestoppten Volumes zurück: exakt der 8.0-Stand, aber alles, was nach dem Backup geschrieben wurde, ist weg. Lief 8.4 schon eine Weile und gibt es neue Daten, die du behalten willst, ziehst du unter 8.4 einen frischen mysqldump und spielst ihn in einen neuen, leeren 8.0-Container ein – das ist der unterstützte Weg.

docker compose stop
docker compose rm -f db
docker volume rm myapp_dbdata             # deletes the upgraded 8.4 data

# put the old docker-compose.yml back (image: mysql:8.0 and the old command:)
docker compose create db                  # recreates the empty volume
docker run --rm -v myapp_dbdata:/var/lib/mysql -v "$PWD":/backup alpine \
  tar xzf /backup/dbdata-8.0.tgz -C /var/lib/mysql
docker compose up -d

⚠️ Achtung: docker volume rm löscht die Daten endgültig. Führe es erst aus, wenn du geprüft hast, dass dbdata-8.0.tgz existiert, nicht leer ist und tar tzf dbdata-8.0.tgz | head Dateien auflistet.

Bedenke: Nach dem Zurückrollen läufst du wieder auf einer nicht unterstützten Version. Sieh das als Zeitgewinn, bis du behoben hast, was das Upgrade blockiert hat – nicht als Ziel.

Die Datenbank einer NetSendo-Installation aktualisieren

NetSendo hat seine docker-compose.yml mit Version 2.2.0 (6. November 2026) auf MySQL 8.4 LTS umgestellt. Der db-Dienst nutzt jetzt image: mysql:8.4 mit --mysql-native-password=ON --authentication-policy=mysql_native_password,,. So meldet sich der Datenbankbenutzer, den eine 8.0-Installation angelegt hat, weiter an, und das MariaDB-mysqldump im App-Image, das die NetSendo-Backups verwenden, kann sich weiterhin authentifizieren.

Eine bestehende Installation ändert sich nicht von selbst. Ein neues App-Image lässt deine Compose-Datei, wie sie ist; die Datenbank bleibt auf 8.0 und funktioniert mit dem neuen Image weiter. Zum Upgrade sicherst du die Datenbank, ersetzt die docker-compose.yml durch die aus dem Release (Image und command: zusammen) und startest docker compose up -d; MySQL aktualisiert das Datenverzeichnis beim ersten Start. Die Release Notes beschreiben den getesteten Weg: Migrationen unter 8.0, dasselbe Volume unter 8.4 gestartet, die App meldet sich an und mysqldump funktioniert. Die allgemeinen Installationsschritte findest du im Schnellstart, die Datenbankeinstellungen in der .env in der Konfigurationsdokumentation.

Wenn du noch eine Plattform zum Selbsthosten suchst, zeigt der Vergleich selbst gehosteter E-Mail-Marketing-Software, welche Datenbank jedes Tool braucht und was der Betrieb bedeutet. Zum Datenschutz gilt: Selbst hosten hält die Daten auf deiner eigenen Infrastruktur, was bei DSGVO-Pflichten hilft – wie gut, hängt davon ab, wie du den Server betreibst.

Häufig gestellte Fragen

Quellen

• MySQL 8.4 Reference Manual: What Is New in MySQL 8.4
• MySQL 8.4 Reference Manual: Upgrade Paths
• MySQL 8.4 Reference Manual: Downgrading MySQL
• MySQL 8.4 Reference Manual: Native Pluggable Authentication
• MySQL 8.4 Reference Manual: authentication_policy
• Oracle Cloud: MySQL Server Versions (MySQL 8.0 end of life)
• Docker Hub: official mysql image and supported tags
• NetSendo v2.2.0 release notes