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. Dabei spielt die laufende Datenintegration mehrerer Quellsysteme eine wichtige Rolle.

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.