Une migration de base change parfois le schéma, les index ou le format des données pendant que l’application continue de fonctionner. Une préparation progressive limite le blocage et rend le retour plus prévisible.
Mesurer la contrainte métier
Demandez combien de temps chaque fonctionnalité peut être indisponible et quelle perte de données est acceptable. Une opération interne peut accepter une courte fenêtre nocturne, tandis qu’un formulaire client ou un paiement demande une continuité plus stricte.
Identifiez les tables volumineuses, les écritures fréquentes, les index utilisés et les jobs qui lisent la base. Mesurez une migration sur une copie représentative. La durée d’un test réduit ne prédit pas toujours celle d’une table de production.
Utiliser une période de compatibilité
Pour une modification importante, déployez d’abord un schéma compatible avec l’ancienne version. Ajoutez un champ ou une table, puis publiez le code qui écrit dans les deux formats si nécessaire. Après vérification, lisez le nouveau format et retirez l’ancien dans une étape séparée.
Cette période permet de revenir à la version précédente sans demander à l’application de comprendre un schéma qu’elle ne connaît pas. Elle demande toutefois un suivi des deux écritures et une règle claire pour supprimer le code temporaire.
Limiter les verrous
Une commande qui réécrit une grande table peut bloquer des lectures ou des écritures. Utilisez les options de migration adaptées à votre moteur, traitez les données par lots et surveillez les verrous. Chaque lot doit être rejouable ou identifiable afin qu’un arrêt ne laisse pas un état ambigu.
Exécutez les changements lourds pendant une période de moindre demande lorsque c’est possible. Préparez une limite de durée : une migration qui dépasse le seuil doit être interrompue ou déplacée dans un processus asynchrone.
Valider les données
Après chaque étape, comparez les volumes, les clés, les contraintes et quelques agrégats significatifs. Vérifiez les caractères, les dates, les fuseaux horaires et les valeurs nulles. Une migration peut réussir techniquement et modifier le sens d’un champ pour l’application.
Testez les parcours métier avec des comptes de test. Contrôlez aussi les exports, les rapports et les intégrations qui utilisent la base sans passer par l’API principale. Les tâches planifiées doivent connaître le moment où le nouveau schéma devient disponible.
Préparer la restauration
Avant une migration destructive, faites une sauvegarde et testez sa restauration. Écrivez le point de retour, le temps prévu et la manière de traiter les écritures réalisées après la sauvegarde. Un retour de code n’annule pas automatiquement les changements déjà écrits dans la base.
Définissez les seuils qui interrompent l’opération : erreurs applicatives, durée de verrouillage, échec de validation ou croissance inattendue. Une personne décide du retour, et une autre peut confirmer l’état des données.
Documenter l’opération
Le runbook doit citer la version du code, les commandes, les permissions, les tableaux de bord et les vérifications. Ajoutez une procédure pour nettoyer les éléments temporaires et une date de réexamen. Le test de restauration des sauvegardes complète cette préparation.
Sources : PostgreSQL, concurrent index builds, AWS Prescriptive Guidance, blue green databases.