Welche Strategien zur State-Migration sind bei Zero-Downtime-Deployments von relationalen Datenbanken (z. B. Expand-Contract Pattern) anzuwenden?

Zero-Downtime-Deployments bei relationalen Datenbanken setzen voraus, dass die Datenbank zu jedem Zeitpunkt mit mindestens zwei Versionen der Applikation kompatibel ist. Wir setzen hierfür primär das Expand-Contract Pattern (auch Parallel Change genannt) ein, um destruktive Änderungen zu vermeiden.

Der Prozess gliedert sich in drei technische Phasen:

Bei komplexeren Transformationen ergänzen wir diesen Prozess durch folgende Strategien:

• Dual-Writing: Die Applikation schreibt Daten synchron oder asynchron in die alte und die neue Struktur. Dies stellt sicher, dass keine Daten während der Übergangsphase verloren gehen.
• Backfilling: Ein Hintergrundprozess migriert bestehende Datensätze schrittweise in die neue Struktur, um die Datenbanklast zu begrenzen und Timeouts zu vermeiden.
• Feature Toggles: Über Konfigurationsschalter steuern wir den Zeitpunkt, an dem die Applikation von der alten auf die neue Datenquelle umschaltet, ohne einen erneuten Deployment-Zyklus zu starten.

Die Implementierung dieser Strategien erfordert präzises Data Engineering, da die Konsistenz zwischen den Versionen gewahrt bleiben muss. Besonders bei hochfrequentierten Tabellen ist die Vermeidung von Table-Locks kritisch. Wir setzen daher auf Online-Schema-Change-Tools, die Tabellenkopien im Hintergrund erstellen und per Atomic Switch austauschen.

Wir empfehlen, auf direkte ALTER TABLE-Befehle bei produktiven Systemen mit großen Datenmengen vollständig zu verzichten. Die einzige nachhaltige Lösung für Zero-Downtime ist die strikte Trennung von Schema-Migration und Code-Deployment. Wer versucht, beides in einem Schritt zu lösen, riskiert bei einem Rollback des Codes einen inkonsistenten Datenbankzustand, der nur durch zeitaufwendige manuelle Korrekturen behoben werden kann.