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:
ALTER TABLE users ADD COLUMN first_name TEXT;
ALTER TABLE users ADD COLUMN last_name TEXT;
Dann fügen Sie die Daten nach:
UPDATE users
SET 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.
Weiterführende Literatur