Migrations de base de données zero-downtime en pratique

Les déploiements se chevauchent

Une migration de schéma tourne rarement isolée. D'anciennes et nouvelles instances applicatives peuvent servir le trafic simultanément, des workers peuvent traiter des jobs retardés, et des clients mobiles peuvent rester actifs des mois. Une migration sûre assume ce chevauchement et garde chaque état intermédiaire compatible.

Le pattern expand-and-contract sépare un remplacement risqué en étapes réversibles. D'abord expandez le schéma ou l'interface, puis migrez comportement et données, observez le résultat, et seulement ensuite retirez l'ancien chemin. Les étapes supplémentaires achètent du contrôle au moment où il compte.

Expander sans changer le sens

Ajoutez de nouvelles colonnes nullable, tables, index ou endpoints d'une façon que le code existant peut ignorer. Évitez defaults ou contraintes qui réécrivent une grande table sous lock sans comprendre le comportement de la base. Construisez de grands index en concurrent quand le moteur le permet et monitorez le lag de réplication et la durée de lock.

Déployez du code capable d'écrire les deux représentations ou de peupler le nouveau modèle pour les données nouvellement créées. Les dual writes introduisent un risque de cohérence, donc bornez la transition, instrumentez la divergence, et préférez une seule transaction quand les deux records partagent une base.

• Mesurez d'abord la taille de table et le comportement de lock
• Rendez les commandes de migration restartables
• Throttlez les backfills sous charge de production
• Enregistrez la progression avec des checkpoints stables

Le backfill comme une opération

Un backfill de production est une charge de travail, pas un script one-off. Traitez des lots déterministes, persistez des checkpoints, limitez la concurrence, et exposez progression et échecs. Le job doit pouvoir être arrêté et repris sans dupliquer les effets.

Validez la nouvelle représentation en continu. Comparez counts, checksums, invariants et records échantillonnés plutôt que d'attendre la fin. Si la migration transforme le sens, encodez le mapping attendu dans des checks exécutables reviewés par les owners de domaine.

Déplacer les reads délibérément

Une fois les nouveaux writes et les données historiques prêts, déplacez les reads derrière un feature flag ou un rollout contrôlé. Les shadow reads peuvent comparer anciens et nouveaux résultats sans changer la réponse utilisateur. Segmentez erreurs et latence par chemin pour que la décision d'avancer soit fondée sur l'évidence.

Le rollback à ce stade doit généralement signifier revenir aux reads, pas inverser le schéma. Des scripts de rollback destructifs peuvent rendre un déploiement récupérable bien pire. Préservez l'état expandé jusqu'à une confiance élevée.

Contracter seulement après évidence

Arrêtez d'écrire l'ancienne représentation, attendez que les versions applicatives qui se chevauchent et le travail en file soient clairés, puis retirez le code inutilisé. Confirmez via la télémétrie que l'ancien champ ou table n'est plus lu avant de le dropper dans un déploiement séparé.

Le zero downtime n'est pas l'absence de risque. C'est une forme de livraison qui rend le risque observable, limite le rayon d'impact, et préserve une décision sûre à chaque étape.