Zero-Downtime Database Migrations in der Praxis

Deployments überlappen

Eine Schema Migration läuft selten isoliert. Alte und neue Application Instances können gleichzeitig Traffic bedienen, Worker können verzögerte Jobs processieren, und Mobile Clients können monatelang aktiv bleiben. Eine sichere Migration nimmt diese Überlappung an und hält jeden Intermediate State kompatibel.

Das Expand-and-Contract Pattern trennt eine riskante Replacement in reversible Stages. Zuerst expandieren Sie Schema oder Interface, dann migrieren Sie Behavior und Data, beobachten Sie das Result und entfernen erst später den alten Path. Die Extra Steps kaufen Control im Moment, in dem sie zählt.

Expandieren, ohne Meaning zu ändern

Fügen Sie neue nullable Columns, Tables, Indexes oder Endpoints so hinzu, dass existierender Code sie ignorieren kann. Vermeiden Sie Defaults oder Constraints, die eine große Table unter Lock umschreiben, ohne Database Behavior zu verstehen. Bauen Sie große Indexes concurrently, wenn die Engine das unterstützt, und monitoren Sie Replication Lag und Lock Duration.

Deployen Sie Code, der beide Representations schreiben oder das neue Model für neu erstellte Data populieren kann. Dual Writes führen Consistency Risk ein, also halten Sie die Transition bounded, instrumentieren Sie Divergence und bevorzugen Sie eine Single Transaction, wenn beide Records dieselbe Database teilen.

• Messen Sie Table Size und Lock Behavior zuerst
• Machen Sie Migration Commands restartable
• Throttlen Sie Backfills unter Produktionslast
• Recorden Sie Progress mit stabilen Checkpoints

Backfill als Operation

Ein Produktions-Backfill ist eine Workload, kein One-Off Script. Processen Sie deterministische Batches, persistieren Sie Checkpoints, limitieren Sie Concurrency und exponieren Sie Progress und Failures. Der Job sollte sicher zu stoppen und zu resumieren sein, ohne Effects zu duplizieren.

Validieren Sie die neue Representation kontinuierlich. Vergleichen Sie Counts, Checksums, Invariants und gesampelte Records statt bis zum Ende zu warten. Wenn die Migration Meaning transformiert, kodieren Sie das erwartete Mapping in executable Checks, die von Domain Owners reviewed werden.

Reads absichtlich bewegen

Sobald neue Writes und historische Data bereit sind, verschieben Sie Reads hinter einem Feature Flag oder Controlled Rollout. Shadow Reads können alte und neue Results vergleichen, ohne die User Response zu ändern. Segmentieren Sie Errors und Latenz nach Path, damit die Entscheidung voranzugehen auf Evidenz basiert.

Rollback in dieser Stage sollte meist bedeuten, Reads zurückzuschalten, nicht das Schema umzukehren. Destruktive Rollback Scripts können ein recoverable Deployment deutlich verschlechtern. Bewahren Sie den expanded State, bis Confidence hoch ist.

Contract nur nach Evidenz

Stoppen Sie das Schreiben der alten Representation, warten Sie, bis overlapping Application Versions und queued Work klar sind, und entfernen Sie dann unused Code. Bestätigen Sie durch Telemetry, dass das alte Field oder die Table nicht mehr gelesen wird, bevor Sie es in einem separaten Deployment droppen.

Zero Downtime ist nicht die Abwesenheit von Risk. Es ist eine Delivery Shape, die Risk beobachtbar macht, Blast Radius begrenzt und bei jeder Stage eine sichere Entscheidung erhält.