Erklär mir, wie du eine Datenbankmigration ohne Downtime ausrollst.

Teil sie in rückwärtskompatible Schritte. Deploy die Schemaänderung zuerst in einer Form, die der laufende Code toleriert, etwa eine nullable Spalte, dann deploy Code, der alt und neu schreibt, backfille in Batches, schalt die Lesezugriffe um und lösch die alte Spalte erst in einem späteren Release. Vermeide lange Table Locks und teste immer den Rollback-Pfad.

Die Regel, an die ich mich halte, ist, dass während eines Rolling Deploys zwei Codeversionen mit einer Datenbank reden, jeder Schritt also für beide sicher sein muss. Eine Spalte umzubenennen ist die klassische Falle. Stattdessen expandiere ich: die neue nullable Spalte in einer eigenen Migration ergänzen, Code ausliefern, der beide Felder schreibt und weiterhin das alte liest, bestehende Zeilen in Batches von ein paar tausend mit Pause dazwischen backfillen, damit die Replikation nicht zurückfällt, dann im nächsten Release die Lesezugriffe umschalten, und erst in einem dritten Release die alte Spalte löschen. Postgres-Spezifika zählen auch. Ein NOT NULL Constraint auf einer großen Tabelle nimmt ein schweres Lock, also ergänze ich die Spalte nullable, backfille und validiere das Constraint separat. Django gibt dir separate_database_and_state und nicht-atomare Migrationen, wenn du sie brauchst, und ich setze ein kurzes lock_timeout, damit eine blockierte Migration schnell scheitert, statt jede Query dahinter aufzustauen. Jede Migration bekommt außerdem einen getesteten Rollback.