Erweitern und Verkleinern: So ändern Sie Schemas, ohne laufenden Code zu unterbrechen_
Null-Downtime-Migrationen erfordern normalerweise eine Staging-Umgebung: das Schema erweitern, nachfüllen, den Code umschalten und dann erst die alte Form entfernen.
Die gefährliche Migration ist nicht die, die das Schema ändert. Es ist die, die annimmt, dass jede laufende App-Instanz, jeder Job-Worker und jeder Hintergrundverbraucher die Erwartungen genau im gleichen Moment umschaltet.
Diese Annahme ist in der Produktion so gut wie nie sicher.
Was Erweitern und Verkleinern bedeutet
Das Muster funktioniert, weil es Überlappungen zwischen der alten und der neuen Welt akzeptiert:
das Schema erweitern
den alten Code funktionsfähig halten
nachfüllen oder dual schreiben
Lese- und Schreiboperationen umschalten
die alte Form später entfernen
Wenn Sie zum Beispiel von full_name zu first_name und last_name wechseln, beginnen Sie normalerweise mit der Erweiterung:
UPDATE usersSET first_name = split_part(full_name, ' ', 1), last_name = substring(full_name from position(' ' in full_name) + 1);
Nur nachdem die Anwendung die neuen Spalten sicher liest, entfernen Sie full_name.
Warum dieses Muster die zusätzlichen Schritte wert ist
Erweitern und Verkleinern ist langsamer als eine einmalige unterbrechende Migration, aber es bewältigt reale Produktionsbedingungen besser:
Rollende Deployments
Hintergrundjobs auf älteren Versionen
Wiederholungen gegen gemischte Anwendungsversionen
Partielle Nachfüllungen, die überwacht werden müssen
Die zusätzlichen Schritte sind kein bloßes Zeremoniell. Sie sichern die Kompatibilität während des Wandels.
Abwägungen
Die Kosten sind vorübergehende Komplexität:
mehr Codepfade für eine Weile
Migrationsbuchhaltung
spätere Bereinigungsarbeiten
Teams geraten in Schwierigkeiten, wenn sie die Erweiterungsphase durchlaufen und die Verkleinerungsphase vergessen. Wenn der alte Pfad nie entfernt wird, wird die Migration zu einer dauerhaften architektonischen Schuld.