Migration de Base de Données : Changements de Schema et Deploy sans Downtime

Qu'est-ce que la Migration de Base de Données ?

La migration de base de données est un processus contrôlé utilisé pour changer le schema de la base de données (structures de tables, index, contraintes).

Changements de schema : Ajouter une nouvelle table, ajouter/modifier/supprimer une colonne, ajouter un index, ajouter une foreign key, changer le type de données.

Risques : Perte de données, downtime, dégradation des performances, incompatibilité vers l'arrière.

Objectif : Appliquer les changements de schema de manière sûre, répétable et rollback-able.

Outils de Migration

Flyway : Outil de migration basé sur SQL. Fichiers de migration versionnés (V1__create_users.sql). Support Java, Node.js, CLI.

Liquibase : Changelog au format XML/YAML/JSON/SQL. Support de rollback, génération de diff, comparaison de bases de données.

Prisma Migrate : Intégré avec Prisma ORM. Génère automatiquement la migration depuis schema.prisma.

Knex.js : Outil de migration Node.js. Fichiers de migration en JavaScript. Fonctions up et down.

Django/ActiveRecord : Outils de migration intégrés au framework. Crée automatiquement la migration à partir des changements de modèle.

Stratégies de Migration sans Downtime

Expand and Contract (Parallel Change) : 1) Ajouter une nouvelle colonne/table (expand), 2) Mettre à jour le code (supporter l'ancienne et la nouvelle colonne), 3) Supprimer l'ancienne colonne (contract).

Changements compatibles vers l'arrière : Ajouter une nouvelle colonne (nullable), ajouter une nouvelle table, ajouter un nouvel index. Ces changements ne nécessitent pas de downtime.

Breaking changes : Suppression de colonne, changement de type de colonne, rename. Ces changements doivent être faits avec le pattern expand-contract.

Feature flags : Mettez le nouveau schema derrière un feature flag. Réduisez le risque avec un rollout graduel.

Blue-green deployment : Testez le nouveau schema dans un environnement parallèle. Basculez le trafic. Revenez à l'ancien environnement en cas de problème.

Migration de Données

Backfill : Rendez les données existantes compatibles avec le nouveau schema. Traitez les grands ensembles de données avec le batch processing.

Dual write : Écrivez dans l'ancien et le nouveau schema. Maintenez la cohérence des données pendant la période de transition.

Validation des données : Vérifiez l'intégrité des données après la migration. Nombre de lignes, checksum, comparaison d'échantillon.

Performance : La migration sur de grandes tables crée une charge de lock et d'I/O. Exécutez pendant les heures creuses. Utilisez le traitement par chunks.

Plan de Rollback

Down migration : Écrivez la down migration correspondante (rollback) pour chaque up migration. Flyway, Liquibase supportent le rollback.

Backup : Faites un backup complet avant la migration. Ayez la capacité de point-in-time recovery (PITR).

Tests : Testez la migration dans l'environnement de staging. Utilisez le même volume de données et schema que la production.

Monitoring : Surveillez la performance des requêtes et le taux d'erreur après la migration. Rollback en cas de déviation anormale.

Communication : Partagez le plan de migration avec l'équipe. Définissez la fenêtre de maintenance.

Meilleures Pratiques

Contrôle de version : Suivez les fichiers de migration avec Git. Chaque migration doit être atomique (un seul changement).

Idempotence : Exécuter la migration plusieurs fois doit produire le même résultat. Utilisez IF NOT EXISTS, IF EXISTS.

Petites migrations : Divisez les grands changements en petites migrations. Chaque migration doit être déployable indépendamment.

Code review : Faites passer les fichiers de migration par le code review. Les changements de schema sont critiques et difficiles à annuler.

Documentation : Documentez le but et l'impact de chaque migration. Indiquez clairement les changements breaking.