Datenbankmigrationen ohne Herzrasen
Schema-Änderungen auf Produktivsystemen sind einer dieser Momente wo man kurz innehält
und überlegt ob man wirklich Entwickler werden wollte. ALTER TABLE auf
einer Tabelle mit 50 Millionen Zeilen – wie lange dauert das? Wird die Tabelle
gesperrt? Funktioniert die Replikation danach noch? Kann ich das rückgängig machen?
Die gute Nachricht: es gibt Antworten auf alle diese Fragen. Die schlechte: sie sind nicht immer die die man hören will.
Was ALTER TABLE wirklich macht
In älteren MySQL-Versionen hat fast jedes ALTER TABLE die Tabelle
für Reads und Writes gesperrt, eine Kopie gebaut, und dann umbenannt. Bei großen
Tabellen: Minuten bis Stunden Downtime. In neueren Versionen (MySQL 5.6+, MariaDB)
gibt es Online DDL – viele Operationen laufen ohne Table Lock. Aber nicht alle.
Und "ohne Table Lock" heißt nicht "ohne Performance-Impact".
Die Checkliste vor jeder Migration
Backup gemacht – und getestet ob es sich wiederherstellen lässt. Nicht
nur gemacht, auch getestet. Das ist kein Witz.
Staging-Umgebung mit Produktionsdaten (anonymisiert) – Migration dort
zuerst, Laufzeit messen. Wartungsfenster kommuniziert wenn nötig.
Rollback-Plan überlegt – nicht jedes ALTER TABLE ist
einfach rückgängig zu machen.
Migration-Tools die helfen
pt-online-schema-change (Percona Toolkit) – der Standard für große Tabellen ohne Downtime. gh-ost von GitHub – Alternative zu pt-osc, triggerbasiert, gut für Hochlast-Umgebungen. Flyway / Liquibase – für versionierte Schema-Migrationen die nachvollziehbar und wiederholbar sind. Für PHP-Projekte auch Doctrine Migrations oder Laravel Migrations wenn das Framework sowieso dabei ist.
Das Herzrasen bleibt trotzdem ein bisschen. Das ist normal. Wer dabei gar kein Herzrasen hat, macht sich wahrscheinlich zu wenig Gedanken.
← zurück zu Datenbanken 📂 Archiv