"Wir brauchen ein Wartungsfenster." Vier Worte, die in vielen Teams reflexartig fallen, sobald jemand das Wort "Datenbankmigration" in den Mund nimmt. Als wäre es ein Naturgesetz: Spalte umbenennen, Tabelle umstrukturieren, Index hinzufügen – also Seite offline, Nutzer informieren, Daumen drücken. Das stimmt nicht. Es hat nur noch niemand etwas Besseres eingeführt.

Das Grundproblem: Code und Schema laufen nicht synchron

Das eigentliche Problem bei Datenbankmigrationen ist nicht die Migration selbst – es ist der Moment, in dem alter Code auf ein neues Schema trifft oder neuer Code auf ein altes. In diesem Übergangsmoment passieren Fehler. Zero-Downtime-Strategien lösen genau dieses Problem, indem sie diesen Übergang kontrolliert gestalten statt ihn zu ignorieren.

Das Expand/Contract-Pattern

Phase 1: Expand

Statt eine Spalte umzubenennen, wird eine neue Spalte hinzugefügt. Der neue Code schreibt in beide Spalten – alte und neue. Der alte Code liest weiter aus der alten Spalte. Kein Ausfall, kein Datenverlust, kein Wartungsfenster.

Phase 2: Migrate

Ein Hintergrundprozess befüllt die neue Spalte mit Daten aus der alten – in Batches, ohne die Produktion zu blockieren. Große Tabellen werden in Blöcken verarbeitet, um Lock-Probleme zu vermeiden. Läuft unbemerkt, während der Rest des Teams Mittagspause macht.

Phase 3: Contract

Sobald alle Daten migriert sind und der neue Code ausschließlich die neue Spalte nutzt, wird die alte Spalte entfernt. Erst jetzt ist die Migration vollständig abgeschlossen. Kein Fanfare, kein Wartungsfenster – einfach fertig.

Feature Flags als Sicherheitsnetz

Feature Flags erlauben es, neuen Code zu deployen, ohne ihn sofort zu aktivieren. Damit lässt sich der Übergang zwischen altem und neuem Schema kontrolliert vollziehen: Der neue Code ist deployed, aber deaktiviert. Die Migration läuft. Der Flag wird aktiviert. Bei Problemen: Flag aus, sofortiger Rollback ohne Datenbankänderung. Fast so entspannt wie ein Freitagabend ohne Deploy.

Zero-Downtime bedeutet nicht Zero-Aufwand. Es bedeutet, den Aufwand in einen kontrollierten Prozess zu überführen statt in ein Wartungsfenster.

Werkzeuge in der PHP-Welt

Doctrine Migrations, Phinx oder Flyway eignen sich für die Verwaltung von Migrationsskripten. Für Hochlastsysteme lohnt sich ein Blick auf pt-online-schema-change oder gh-ost – Tools, die Schemawechsel an MySQL-Datenbanken ohne Table Locks durchführen.

Fazit

Wartungsfenster für Datenbankmigrationen sind eine Wahl, keine Notwendigkeit. Das Expand/Contract-Pattern erfordert mehr Planung als ein direkter Schemawechsel – aber es macht das System robuster und das Team autonomer. Deployments ohne Nachtschichten, ohne Stress, ohne das mulmige Gefühl beim Drücken von Enter.