Migration de base de données sans interruption : les stratégies qui fonctionnent

Le terme recouvre trois situations différentes : le déplacement d'une base vers un autre serveur ou un autre hébergeur avec le même moteur, le changement de moteur (par exemple de MySQL vers PostgreSQL, ou d'une base auto-hébergée vers un service managé), et l'évolution du schéma d'une base en production, comme renommer, restructurer ou découper des tables.

Chaque situation a ses outils, mais toutes partagent le même principe : à aucun moment il ne doit exister une période où l'application ne peut ni lire ni écrire. Cela impose que l'ancien et le nouveau système coexistent pendant une phase de transition, et que l'application sache travailler avec les deux.

La migration avec arrêt, où l'on coupe, copie puis rallume, reste légitime pour une petite base et une fenêtre de maintenance acceptable. Les stratégies décrites ici s'adressent aux systèmes où cette fenêtre n'existe pas ou coûte trop cher en chiffre d'affaires ou en image.

Pour faire évoluer le schéma sans interruption, on procède en trois temps. Expand : on ajoute la nouvelle structure (colonne, table) à côté de l'ancienne, sans rien supprimer. Migrate : on fait écrire l'application dans les deux structures et on remplit la nouvelle avec les données historiques. Contract : une fois que tout lit la nouvelle structure, on supprime l'ancienne.

Chaque étape est déployée séparément et reste compatible avec la version précédente de l'application, ce qui autorise un retour arrière à tout moment. C'est aussi ce qui permet aux déploiements progressifs, où deux versions du code cohabitent, de fonctionner sans erreur pendant la transition.

Attention aux opérations qui verrouillent les tables. Sur PostgreSQL, créez les index avec l'option CONCURRENTLY, ajoutez les contraintes en deux temps (NOT VALID puis VALIDATE) et évitez les réécritures complètes de table. Sur MySQL, des outils comme gh-ost ou pt-online-schema-change réalisent les modifications sans verrou prolongé.

La double écriture consiste à faire écrire l'application simultanément dans l'ancienne et la nouvelle base, tout en continuant à lire dans l'ancienne. Un processus de remplissage copie les données historiques en arrière-plan. Quand la nouvelle base est complète et vérifiée, on bascule les lectures, puis on arrête d'écrire dans l'ancienne.

Cette approche est simple à comprendre et donne un contrôle total au code applicatif, ce qui la rend adaptée aux changements de moteur avec transformation du modèle. Son inconvénient est le risque d'incohérence : si l'une des deux écritures échoue, les bases divergent sans que personne ne s'en aperçoive.

Pour limiter ce risque, l'écriture doit être idempotente, les échecs doivent être journalisés et rejoués, et une comparaison régulière des deux bases doit détecter les écarts. Cette complexité fait qu'on lui préfère souvent la capture des changements lorsque le moteur le permet.

La capture des changements de données lit le journal de transactions de la base source (WAL sur PostgreSQL, binlog sur MySQL, oplog sur MongoDB) et rejoue chaque modification sur la base cible, en continu et avec un délai de quelques secondes. L'application n'a rien à modifier, ce qui réduit considérablement le risque.

Des outils comme Debezium, AWS Database Migration Service ou les fonctionnalités de réplication natives couvrent ce besoin, y compris entre moteurs différents avec des transformations. La copie initiale (snapshot) est suivie d'une réplication continue jusqu'à la bascule, que l'on choisit au moment le plus calme.

Le CDC est aujourd'hui l'approche de référence pour changer de serveur, d'hébergeur ou de moteur. Ses limites : les types de données exotiques, les objets non répliqués (séquences, procédures stockées, déclencheurs) et la nécessité de surveiller le retard de réplication en permanence.

Une migration n'est pas terminée quand les données sont copiées, mais quand on a prouvé qu'elles sont identiques et que l'application fonctionne sur la cible. Comparez les volumes par table, des sommes de contrôle par lot et des échantillons de lignes choisis au hasard, et rejouez les requêtes critiques sur les deux bases.

Faites tourner l'application en lecture sur la nouvelle base dans un environnement de préproduction alimenté par la réplication, et exécutez vos tests fonctionnels et de charge. Vérifiez particulièrement les encodages, les fuseaux horaires, la précision des décimaux et les ordres de tri, qui diffèrent souvent entre moteurs.

Préparez enfin la bascule elle-même comme un déploiement : procédure écrite, minutage, rôles, critères de succès, et surtout procédure de retour arrière. Le plus sûr est de maintenir une réplication inverse, de la nouvelle base vers l'ancienne, pendant les premiers jours.

Le premier piège est de sous-estimer le code applicatif : requêtes SQL spécifiques à un moteur, comportements implicites (insensibilité à la casse, gestion des valeurs NULL, dates), procédures stockées oubliées. Un audit du code et des requêtes avant le projet évite les découvertes tardives, toujours coûteuses.

Le second est la performance de la cible : un schéma copié tel quel sans revoir les index et les paramètres du nouveau moteur donne souvent des temps de réponse dégradés au moment de la bascule, précisément quand la pression est maximale et la tolérance minimale.

Le troisième est l'absence de propriétaire : une migration de base de données touche le code, l'infrastructure, l'exploitation et parfois le métier. Sans une personne responsable de bout en bout, les décisions s'éternisent et la phase de coexistence, coûteuse, se prolonge.