Datenbankänderungen ohne Ausfall: Expand und Contract

Ziel

Die Datenbankstruktur ändern, während der Dienst weiter bedient – und jeder Zwischenzustand sowohl mit der alten als auch mit der neuen Codeversion funktioniert.

Voraussetzungen

Migrationen, die mit dem Code versioniert sind; ein Deploy-Prozess, der Code und Migrationen getrennt ausliefern kann; Wissen darüber, welche Statements starke Sperren nehmen. Die PostgreSQL-Dokumentation zu ALTER TABLE nennt zu jeder Form die Sperrstufe – die meisten nehmen ACCESS EXCLUSIVE, was jede andere Nutzung der Tabelle blockiert – und hält fest, dass ADD COLUMN mit einem nicht-volatilen DEFAULT den Wert in den Metadaten ablegt, statt die Tabelle umzuschreiben; dass ein CHECK- oder NOT NULL-Constraint die Tabelle liest, aber nicht neu schreibt; und dass ein mit NOT VALID angelegter Constraint erst durch VALIDATE CONSTRAINT geprüft wird, das nur eine SHARE UPDATE EXCLUSIVE-Sperre nimmt. CREATE INDEX CONCURRENTLY baut einen Index, ohne Einfügen, Ändern und Löschen auf der Tabelle zu sperren. Der Parameter lock_timeout bricht ein Statement ab, das länger als angegeben auf eine Sperre wartet.

Schritte

1. Expand: neue Spalte, Tabelle oder Index so anlegen, dass es schnell geht und nicht blockiert (nullable Spalte oder konstanter Default, CREATE INDEX CONCURRENTLY, Constraints NOT VALID). Alter Code ignoriert das Neue.
2. Jede Migration mit gesetztem lock_timeout (wenige Sekunden) laufen lassen und bei Abbruch wiederholen, statt hinter einer wartenden Sperre eine Schlange aus blockierten Anfragen aufzubauen.
3. Code ausliefern, der beide Darstellungen schreibt und weiterhin die alte liest.
4. Bestehende Zeilen in kleinen Häppchen mit Pausen nachfüllen; Sperrwartezeiten und Replikationsverzögerung beobachten. Danach VALIDATE CONSTRAINT.
5. Code ausliefern, der die neue Darstellung liest und sie eine Zeit lang gegen die alte prüft (Abweichungen protokollieren).
6. Das Schreiben der alten Darstellung einstellen; ausliefern.
7. Contract: alte Spalte oder Tabelle in einem späteren Release entfernen, sobald ein Rollback auf die vorige Codeversion nicht mehr nötig ist.

Erwartetes Ergebnis

Jedes Deployment ist für sich umkehrbar; keine Migration hält eine Sperre lange genug, um aufzufallen.

Grenzen und Prüfbasis

Das Muster vervielfacht die Schritte und dauert Tage statt Minuten. Eine Spalte wird als «anlegen, kopieren, löschen» umbenannt, nicht per RENAME, wenn beide Codeversionen laufen müssen. Das Sperrverhalten folgt der zitierten Dokumentation; Zeiten werden nicht behauptet. Ob lock_timeout samt Wiederholung die Zahl der Vorfälle senkt, ist im Wiki als Hypothese festgehalten, nicht als Befund.

Wiederholen mit Blick auf den Blockierer

Ein Abbruch durch lock_timeout ist eine Information, keine Aufforderung zur Endlosschleife: Schon die wartende Sperranfrage blockiert alle neuen Zugriffe hinter sich, und jede Wiederholung erzeugt einen weiteren kurzen Stillstand. Vor dem nächsten Versuch zeigt pg_blocking_pids(pg_backend_pid()) zusammen mit pg_stat_activity (state, xact_start, query), wer die Sperre hält. Eine lange Auswertung oder eine idle in transaction hängende Sitzung endet nicht von selbst; hier ist warten, abbrechen oder pg_terminate_backend eine bewusste Entscheidung, und idle_in_transaction_session_timeout verhindert die häufigste Sorte vorbeugend. Die Schleife braucht eine Pause zwischen den Versuchen und eine Obergrenze. lock_timeout begrenzt nur das Warten auf die Sperre; die Laufzeit von VALIDATE CONSTRAINT und der Nachfüll-Häppchen begrenzt statement_timeout.