MySQL-Migration

Dreistufiges Major-Upgrade von MySQL 5.6 ueber 5.7 auf 8.0 im BSI-regulierten Umfeld. Zeichensatz-Migration, automatisierte Upgrade-Pipeline mit Rollback und lueckenlose Audit-Dokumentation nach BSI 200-1/2/3 und ISO 27001.

BSI-konform

Sicherheitsstandard

MySQL 8.0

Zielversion

Automatisiert

Upgrade-Prozess

2022

Projektzeitraum

Ausgangslage

Ein Kunde aus dem behördlichen Umfeld betrieb produktive MySQL-Datenbanken auf Version 5.6 — einer Version, die seit 2021 kein offizielles Support-Ende erreicht hatte und zunehmend Sicherheitslücken aufwies. Im regulierten Umfeld mit BSI-Anforderungen war ein Upgrade zwingend: Nicht nur aus technischen Gründen, sondern auch um die Compliance-Vorgaben nach BSI 200-1/2/3/4 und ISO 27001 einzuhalten.

Die Herausforderung: Ein dreistufiges Major-Upgrade (5.6 → 5.7 → 8.0) im laufenden Betrieb, mit Zeichensatz-Konvertierung von latin1 auf utf8mb4, ohne Datenverlust und mit vollständiger Dokumentation für das BSI-Audit.

Herausforderung & Ansatz

Herausforderung

Dreistufiges Major-Upgrade (5.6 → 5.7 → 8.0) ohne Downtime
Zeichensatz-Konvertierung latin1 → utf8mb4 über alle Tabellen
BSI-konforme Dokumentation aller Änderungen für Audit-Nachweis
Bestehende Anwendungen durften nicht beeinträchtigt werden

Ansatz

Automatisierte Upgrade-Pipeline mit Rollback-Mechanismus
Staging-Umgebung als Testlauf vor jedem Produktiv-Upgrade
Icinga2-Monitoring mit datenbankspezifischen Checks
Betriebshandbuch nach BSI 200-1/2/3/4 und ISO 27001

Umsetzung

Upgrade-Strategie: Schrittweise statt Big Bang

MySQL erlaubt keine Sprünge über Major-Versionen hinweg — ein direktes Upgrade von 5.6 auf 8.0 ist technisch nicht möglich. Jede Zwischenversion bringt Änderungen am Data Dictionary, an Systemtabellen und an der Replikationslogik mit sich, die sequentiell abgearbeitet werden müssen.

Fachlicher Hintergrund

Ab MySQL 8.0 wurde das File-basierte Data Dictionary durch ein transaktionales, InnoDB-basiertes Dictionary ersetzt. Das bedeutet: mysql_upgrade aus 5.7-Zeiten existiert in 8.0 nicht mehr — der Server führt das Upgrade beim ersten Start automatisch durch. Dieses Verhalten muss in automatisierten Pipelines berücksichtigt werden, da es die Boot-Zeit signifikant verlängert.

Wir haben eine dreistufige Upgrade-Pipeline entwickelt, bei der jeder Schritt in einer Staging-Umgebung vorab getestet wurde. Automatisierte Scripts prüften vor und nach jedem Upgrade die Tabellenintegrität, Indexkonsistenz und Replikationsstatus. Ein Rollback-Mechanismus per LVM-Snapshot ermöglichte im Fehlerfall die Rückkehr zum vorherigen Stand innerhalb von Minuten.

Zeichensatz-Migration: latin1 → utf8mb4

Die Konvertierung des Zeichensatzes war die technisch anspruchsvollste Phase. Bei einer naiven ALTER TABLE ... CONVERT TO-Anweisung können Daten korrumpiert werden, wenn Spalten bereits UTF-8-Daten in einem latin1-deklarierten Feld enthalten — ein häufiges Problem bei gewachsenen Systemen.

Achtung bei Zeichensatz-Migrationen

Vor jeder Konvertierung muss geprüft werden, ob die tatsächliche Byte-Sequenz zum deklarierten Zeichensatz passt. Ein SELECT HEX(spalte) auf Stichproben zeigt schnell, ob Daten als UTF-8 in latin1-Feldern liegen. In diesem Fall ist ein Zwischenschritt über BINARY nötig, um Doppel-Encodings zu vermeiden.

Unser Ansatz: Automatisierte Analyse aller Tabellen und Spalten auf tatsächliche Byte-Muster, danach spaltenweise Konvertierung mit der jeweils passenden Strategie. Über 200 Tabellen wurden so fehlerfrei migriert.

Sicherheit & Compliance

Parallel zum technischen Upgrade wurde das gesamte Sicherheitskonzept nach BSI-Grundschutz überarbeitet. Dies umfasste die Systemhärtung der Datenbankserver, die Verschlüsselung der Datenbanken mit Transparent Data Encryption (TDE) sowie die Umstellung aller Verbindungen auf TLS 1.2+.

Best Practice

MySQL 8.0 unterstützt caching_sha2_password als Standard-Authentifizierung. Ältere Clients (PHP < 7.4, bestimmte JDBC-Treiber) können damit nicht umgehen. Vor dem Upgrade sollte geprüft werden, welche Clients sich verbinden, und gegebenenfalls mysql_native_password als Fallback konfiguriert werden.

Kenntnisse

MySQL 5.6 → 5.7 → 8.0
XtraDB Cluster / Galera
Performance-Tuning
Zeichensatz-Migration
Transparent Data Encryption

Icinga2
DB-spezifische Health-Checks
Replikations-Monitoring
Alerting & Eskalation

BSI 200-1 / 200-2 / 200-3 / 200-4
ISO 27001
Systemhärtung
TLS 1.2+ / SSL-Verbindungen
Audit-Dokumentation

Ergebnis & Fazit

Ergebnis

Erfolgreiche Migration auf MySQL 8.0 ohne Datenverlust
Automatisierte Upgrade-Pipeline für zukünftige Minor-Updates
Vollständiges Betriebshandbuch — BSI-Audit bestanden
Icinga2-Monitoring mit 15+ datenbankspezifischen Checks
Alle Verbindungen verschlüsselt (TLS 1.2+)

Fazit

MySQL-Migrationen im regulierten Umfeld sind kein reines Datenbank-Thema — sie erfordern ein Zusammenspiel aus Automatisierung, Sicherheitskonzept und lückenloser Dokumentation. Der Schlüssel lag in der schrittweisen Vorgehensweise mit Staging-Validierung vor jedem Produktiv-Upgrade, kombiniert mit automatischer Integritätsprüfung.

Das Projekt zeigt: Wer BSI-Compliance nicht als Bremse versteht, sondern als Qualitätsrahmen nutzt, baut zwangsläufig robustere Systeme.