MySQL 8.0 → 8.4 LTS Upgrade (in-place)

Aktualisiert ein installiertes MySQL 8.0 auf demselben Server (in-place) auf 8.4 LTS: Einzelserver, Source + Replicas (zuerst die Replicas, zuletzt die Source) oder InnoDB Cluster (Router → Shell → Metadaten → Secondaries einzeln → zuletzt der Primary). Enthalten sind die Vorabprüfung mit util.checkForServerUpgrade auf jedem Server, die in 8.4 entfernten Variablen und das standardmäßig deaktivierte mysql_native_password, ein Rückfallpunkt per Cold Copy, die Prüfung und ein Runbook für den Rückweg auf 8.0. Da ein Downgrade nicht unterstützt wird, führt der einzige Rückweg über die vor dem Upgrade erstellte Kopie. Für eine Migration auf neue Server (Dump/Load) nutze den Modus „Auf einen anderen Server migrieren“ im Guide zum logischen Backup.

Topologie: 1 Server, Source + Replicas oder InnoDB Cluster (3+ Mitglieder + MySQL-Router-Server)

Vor dem Start

• Der Server bzw. die Server laufen auf dem neuesten Minor-Release von MySQL 8.0 (8.0.4x), installiert aus dem offiziellen MySQL-Repo. Ein direktes Upgrade von 8.0 auf 8.4 wird unterstützt; ein direktes Upgrade von 5.7 auf 8.4 wird nicht unterstützt (zuerst auf 8.0).
• Unter … ist freier Platz in Höhe von Datenverzeichnis + Binlogs vorhanden (für die Cold Copy).
• Es gibt ein aktuelles erfolgreiches Backup (XtraBackup 8.0 oder mysqldump) und einen Restore-Test. Nach dem Upgrade musst du auf XtraBackup 8.4 wechseln (die Version 8.0 kann keinen 8.4-Server sichern).
• Die Unterstützung von MySQL 8.4 und caching_sha2_password in der Anwendung und den Client-Treibern (JDBC, PHP mysqlnd, Python…) wurde in einer Testumgebung geprüft.
• Das Wartungsfenster ist genehmigt…; der Lesetraffic kann sinken, weil die Replicas einzeln aktualisiert werden, und während die Source aktualisiert wird, gibt es eine Schreib-Ausfallzeit….
• Die Binlog-Aufbewahrung auf der Source ist länger als die Upgrade-Dauer der Replicas (Binlogs, die gestoppte Replicas noch brauchen, dürfen nicht gelöscht werden).
• Der Cluster ist gesund: alle Mitglieder ONLINE, Single-Primary-Modus; das erste Mitglied im Formular ist der aktuelle Primary. Beginne das Upgrade nicht, solange es ein Mitglied im Zustand RECOVERING oder einen Status OK_PARTIAL / OK_NO_TOLERANCE gibt.
• Das Cluster-Admin-Konto … kann sich über Port … mit allen Mitgliedern verbinden und sein Passwort ist bekannt (MySQL Shell fragt es bei jeder Verbindung ab).
• Auf den Router-Servern ist MySQL Router aus dem offiziellen MySQL-Repo installiert und läuft als systemd-Dienst (mysqlrouter). Kommt der Anwendungstraffic über mehrere Router, werden die Router einzeln aktualisiert.
• Die Anwendung verbindet sich nur über Router (eine Anwendung, die sich direkt mit einem Mitgliedsnamen verbindet, kann nach einem Wechsel der Primary-Rolle nicht schreiben).

Phasen der Anleitung

• Vorabprüfung — Aktueller Zustand · 8.4-Repo hinzufügen und MySQL Shell 8.4 installieren · Upgrade Checker ausführen · Konfiguration nach entfernten Variablen durchsuchen · Konten mit mysql_native_password umstellen
• Vorabprüfung InnoDB Cluster — Clusterstatus und Router festhalten · Prüfen, ob ein Metadaten-Upgrade nötig ist (dryRun)
• Metadaten-Upgrade — dba.upgradeMetadata() ausführen
• Vorbereitung des Primary-Wechsels — Prüfen, dass die Secondaries auf 8.4 und ONLINE sind
• Abschließende Prüfung InnoDB Cluster — Erweiterten Clusterstatus prüfen · Primary-Rolle an das erste Mitglied zurückgeben
• Nach dem Upgrade — Replikation prüfen (…) · XtraBackup auf 8.4 umstellen und neues Full Backup erstellen · Konten mit mysql_native_password umstellen (dauerhafte Lösung) · Entscheidung über das Löschen der Rückfallkopie
• Rückfall (zurück auf 8.0) — Rückfall: 8.4 stoppen, Datenverzeichnis beiseitelegen · Rückfall: 8.4 stoppen, Datenverzeichnis beiseitelegen · Rückfall: zurück auf die 8.0-Software · Rückfall: zurück auf die 8.0-Software · Rückfall: Cold Copy zurücklegen · Rückfall: Cold Copy zurücklegen …