Migrazioni di database a zero downtime nella pratica

I deployment si sovrappongono

Una migrazione di schema raramente gira in isolamento. Istanze applicative vecchie e nuove possono servire traffico contemporaneamente, i worker possono elaborare job ritardati e i client mobile possono restare attivi per mesi. Una migrazione sicura assume questa sovrapposizione e mantiene ogni stato intermedio compatibile.

Il pattern expand-and-contract separa una sostituzione rischiosa in stadi reversibili. Prima espandi schema o interfaccia, poi migra comportamento e dati, osserva il risultato e solo dopo rimuovi il vecchio percorso. I passi extra comprano controllo nel momento in cui conta.

Espandi senza cambiare il significato

Aggiungi nuove colonne nullable, tabelle, indici o endpoint in un modo che il codice esistente possa ignorare. Evita default o vincoli che riscrivono una tabella grande sotto lock senza capire il comportamento del database. Costruisci indici grandi in concurrent quando il motore lo supporta e monitora lag di replica e durata dei lock.

Deploya codice che possa scrivere entrambe le rappresentazioni o popolare il nuovo modello per i dati appena creati. I dual write introducono rischio di consistenza, quindi tieni la transizione delimitata, strumenta la divergenza e preferisci una singola transazione quando entrambi i record condividono un database.

• Misura prima dimensione della tabella e comportamento dei lock
• Rendi riavviabili i comandi di migrazione
• Limita i backfill sotto carico di produzione
• Registra il progresso con checkpoint stabili

Il backfill come operazione

Un backfill di produzione è un workload, non uno script una tantum. Elabora batch deterministici, persisti checkpoint, limita la concorrenza ed esponi progresso e fallimenti. Il job deve essere sicuro da fermare e riprendere senza duplicare effetti.

Valida continuamente la nuova rappresentazione. Confronta conteggi, checksum, invarianti e record campionati invece di aspettare la fine. Se la migrazione trasforma il significato, codifica il mapping atteso in check eseguibili revisionati dai domain owner.

Sposta le read deliberatamente

Quando nuove write e dati storici sono pronti, sposta le read dietro un feature flag o un rollout controllato. Le shadow read possono confrontare risultati vecchi e nuovi senza cambiare la risposta all’utente. Segmenta errori e latenza per percorso così la decisione di avanzare si basa sull’evidenza.

Il rollback in questa fase di solito significa tornare alle read precedenti, non invertire lo schema. Script di rollback distruttivi possono peggiorare molto un deployment recuperabile. Conserva lo stato espanso fino a quando la confidenza è alta.

Contrai solo dopo l’evidenza

Smetti di scrivere la vecchia rappresentazione, attendi che versioni applicative sovrapposte e lavoro in coda si svuotino, poi rimuovi il codice inutilizzato. Conferma tramite telemetria che il vecchio campo o tabella non viene più letto prima di eliminarlo in un deployment separato.

Zero downtime non è assenza di rischio. È una forma di delivery che rende il rischio osservabile, limita il raggio d’impatto e preserva una decisione sicura a ogni stadio.