Datenbank-Migration: Schemas und Daten sicher umziehen

Eine Datenbank-Migration überführt ein Schema, Daten oder eine komplette Datenbank von einem Zustand in einen anderen – zum Beispiel von einer alten auf eine neue Software-Version, von MySQL auf PostgreSQL oder von einem lokalen Rechenzentrum in die Cloud. Ohne saubere Migration drohen Datenverlust, Ausfallzeiten und inkonsistente Daten.

Warum migriert man Datenbanken?

Versionswechsel: Neue Hauptversionen des DBMS ändern das Speicherformat oder entfernen veraltete Funktionen.
DBMS-Wechsel: Umstieg zwischen Systemen (MySQL nach MariaDB oder PostgreSQL) wegen Features, Lizenz oder Leistung.
Infrastruktur-Umzug: Wechsel des Servers, der Region oder vom eigenen Rechenzentrum in die Cloud.
Schema-Evolution: Strukturänderungen wie neue Tabellen oder Spalten werden ebenfalls als Migrationen versioniert.

Ablauf einer Migration

Analyse: Quell- und Zielsystem inventarisieren – Tabellen, Datentypen, Indizes, Fremdschlüssel, Sonderzeichen.
Schema übertragen: Tabellenstrukturen, Views, Stored Procedures und Trigger zuerst anlegen (siehe Stored Procedures).
Daten kopieren: Export als SQL-Dump oder über ETL-Werkzeuge; bei großen Datenmengen in Batches, damit Transaktionen überschaubar bleiben (siehe Transaktionen).
Verifizieren: Zeilenzahlen, Prüfsummen und Stichproben vergleichen, Fremdschlüssel-Integrität prüfen (siehe Primär- und Fremdschlüssel).
Umschalten: Lese-/Schreibbetrieb auf das neue System umstellen – meist mit kurzem Wartungsfenster.
Rollback planen: Das alte System so lange verfügbar halten, bis das neue stabil läuft (siehe Rollback).

Werkzeuge

Native Dumps: mysqldump für MySQL/MariaDB, pg_dump für PostgreSQL – mit konsistentem Snapshot.
ETL-Werkzeuge: Talend, Apache NiFi oder Pentaho für Transformationen während des Transfers.
Migrations-Frameworks: Flyway und Liquibase versionieren Schema-Änderungen als SQL-Skripte und spielen sie reproduzierbar ein – Standard in CI/CD-Pipelines.
Replikations-Setup: Bei minimaler Ausfallzeit wird das Ziel zunächst per Replikation nachgezogen und erst zum Umschaltzeitpunkt synchronisiert.

Typische Fallstricke

Zeichensatz: utf8mb4 vs. latin1 führt zu kaputten Umlauten – vor dem Export vereinheitlichen.
Datentypen: DATETIME, TIMESTAMP oder boolesche Typen verhalten sich zwischen DBMS unterschiedlich.
Autowerte: Nach dem Import müssen AUTO_INCREMENT-Zähler und Sequenzen neu synchronisiert werden.
Fremdschlüssel: Deaktivieren während des Imports (z. B. SET FOREIGN_KEY_CHECKS=0) und danach wieder aktivieren.
Ausfallzeit: Schreibzugriffe während des Kopierens erzeugen Inkonsistenz – deshalb ein Wartungsfenster oder Replikation einplanen.