Wie lieferst du eine brechende Datenbank-Schemaänderung ohne Downtime aus?

Nutze das Expand-and-Contract-Muster. Erst expand: die neue Spalte oder Tabelle rückwärtskompatibel hinzufügen, sodass der aktuell deployte Code weiter funktioniert. Dann Code deployen, der alt und neu schreibt, bestehende Zeilen in kleinen Batches backfillen, die Lesepfade auf die neue Form umstellen und erst in einem späteren Release die alte Spalte droppen. Jede Migration muss mit der Anwendungsversion davor und danach kompatibel sein.

Meine Regel ist, dass jedes deployte Schema mit der vorherigen und der nächsten Codeversion funktionieren muss, denn während eines Rolling Deploy laufen beide gleichzeitig. Ich benenne also nie eine Spalte um, ich expand und contract. Sagen wir, wir teilen ein Namensfeld auf. Die erste Migration fügt die neuen nullable Spalten hinzu, das ist billig und fasst keine bestehende Zeile an. Dann ein Release, in dem die Anwendung alt und neu schreibt, aber weiter die alte Form liest, sodass noch nichts Nutzersichtbares von den neuen Daten abhängt. Dann ein Backfill in Batches von ein paar tausend mit Pausen dazwischen, damit ich keine lange Transaktion halte und den Replikationslag auf den Replicas nicht sprengen lasse. Dann ein Release, das die neuen Spalten liest, während die alten weiter geschrieben werden als Notausgang. Erst wenn das ein, zwei Releases stabil war, höre ich mit dem Dual Write auf und droppe die alten Spalten. Ich halte Migrationen außerdem aus dem Deploy-Pfad raus, und alles, was einen schweren Lock nimmt, etwa ein Indexaufbau, läuft concurrently und außerhalb der Spitzenzeiten.