Stratégies de migration de bases de données sans interruption de service

Les migrations de bases de données figurent parmi les opérations les plus délicates et risquées en infrastructure IT. Contrairement à un déploiement applicatif qui peut être rerollé en quelques minutes, une migration de données mal maîtrisée peut causer des heures d'indisponibilité, une perte de données ou une corruption silencieuse détectée des jours après.

Cet article explore les approches et outils éprouvés pour migrer vos bases de données en production avec un minimum (ou zéro) de downtime, tout en préservant l'intégrité des données.

1. Les enjeux d'une migration en production
2. Approche 1 : Blue-Green avec réplication
3. Approche 2 : Réplication logique PostgreSQL
4. Approche 3 : Change Data Capture (CDC) avec Debezium
5. Migration de schéma sans downtime (expand-contract)
6. Outils pratiques (pgloader, ora2pg, gh-ost)
7. Checklist pré-migration
8. Tests et validation post-migration
9. Conclusion et perspectives

Coût du downtime

Pour une application SaaS avec 10k utilisateurs, chaque minute d'indisponibilité représente non seulement une perte de revenu, mais aussi une dégradation de la confiance client. Les études montrent que le coût du downtime varie de 5 k€ à 100 k€ par heure selon l'industrie (finance, e-commerce, santé).

Avec une migration conventionnelle (dump/restore), il faut compter :

• Freeze applicatif : 15–30 min
• Dump et transfert : 30 min à plusieurs heures (selon le volume)
• Restore sur cible : idem
• Validations et rollback en cas d'erreur : +30 min

Total : 2–6 heures de downtime potentiel, inacceptable pour une mission-critical.

Intégrité des données et cohérence

Les migrations exposent plusieurs risques :

• Divergence entre source et cible pendant le transfert → données "entre deux états"
• Perte de transactions intermédiaires (commits pendant la migration)
• Corruption silencieuse non détectée avant plusieurs jours
• Rollback impossible après basculement en production

Stratégie de rollback

Une migration doit toujours répondre à : En cas de problème à T+2h, pouvons-nous revenir à l'état antérieur en < 15 min ?

Cela implique de conserver l'ancienne base active en parallèle pendant 48 à 72h, ce qui a un coût (stockage, CPU) mais offre une sécurité indispensable.

La stratégie Blue-Green alterne entre deux environnements (Blue = ancien, Green = nouveau).

Architecture

┌─────────────────────────────────────────────────┐
│             Load Balancer / Router              │
└────────────────┬────────────────┬───────────────┘
                 │                │
        ┌────────▼──────┐   ┌────▼─────────┐
        │   Base BLUE   │   │  Base GREEN  │
        │  (Production) │   │  (Migration) │
        └───────────────┘   └──────────────┘

Étapes

1. Setup Green : Provisioner une nouvelle instance identique (même version, même config)
2. Réplication initiale : Dump complet de Blue → Green
3. Réplication continue : Active des écritures depuis Blue vers Green (réplication logique ou WAL streaming)
4. Validation : Contrôles d'intégrité, tests de performance sur Green
5. Switchover : Basculer le trafic (DNS ou router) de Blue vers Green
6. Rollback window : Maintenir Blue actif pendant 48–72h en relecture

Avantages

• Approche classique et fiable
• Switchover instantané (DNS ou HAProxy)
• Rollback simple : revenir au routing Blue

Inconvénients

• Double coût infrastructure pendant la migration
• Requiert une réplication en temps réel (latence acceptable)
• Complexité opérationnelle pour synchroniser les writes

Exemple avec PostgreSQL + WAL streaming

# Sur Blue (source) — enable WAL archiving
wal_level = replica
max_wal_senders = 5
wal_keep_size = 1GB

# Sur Green (cible)
pg_basebackup -h blue.db.local -D /var/lib/postgresql/data -Xs
# Lance la réplication WAL stream

Pour PostgreSQL 10+, la réplication logique offre un contrôle fine-grained.

Concept

Contrairement au WAL streaming (physical replication) qui rejeu les octets exacts, la réplication logique extrait les changements logiques (INSERT, UPDATE, DELETE) et les applique sur la cible. Cela permet :

• Migrer vers une version PostgreSQL différente
• Changer le schéma en parallèle
• Filtrer certaines tables ou colonnes

Setup avec Logical Replication Slots

-- Sur Blue (publication)
CREATE PUBLICATION migration_pub FOR ALL TABLES;

-- Sur Green (subscription)
CREATE SUBSCRIPTION migration_sub
  CONNECTION 'postgresql://user:pass@blue.db/dbname'
  PUBLICATION migration_pub;

-- Monitor
SELECT slot_name, restart_lsn FROM pg_replication_slots;
SELECT subname, subenabled FROM pg_subscription;

Avantages

• Flexibilité : filtrer les tables/colonnes
• Compatible avec les migrations de version (9.6 → 15, etc.)
• Découpling : source et cible peuvent tourner à des rythmes différents

Inconvénients

• Overhead CPU/réseau : le décodage logique consomme des ressources
• Lag potentiel : si Green ne peut pas suivre le rythme des écritures
• Requiert PostgreSQL 10+ sur source ET cible

Pour des environnements complexes (plusieurs BD, hétérogènes), Debezium capture les changements et les alimente à un Kafka ou autre événementiel.

Architecture

┌──────────────────┐
│  Source Database │
│  (MySQL/PG/Oracle)
└────────┬─────────┘
         │
         ▼
   ┌─────────────┐
   │  Debezium   │ (CDC connector)
   │  Connector  │
   └──────┬──────┘
          │
          ▼
   ┌────────────────┐
   │     Kafka      │ (event streaming)
   └──────┬─────────┘
          │
          ▼
   ┌──────────────────┐
   │  Target Database │
   │ + Consumer       │
   └──────────────────┘

Cas d'usage

• Heterogeneous migration : MySQL 5.7 → PostgreSQL 15
• Multi-database sync : PostgreSQL + Oracle + MongoDB
• Event-driven architecture : propager les changes à des services externes
• Analytics pipeline : dupliquer en temps réel vers un data warehouse

Configuration exemple (MySQL)

{
  'name': 'mysql-migration-connector',
  'config':
    {
      'connector.class': 'io.debezium.connector.mysql.MySqlConnector',
      'database.hostname': 'mysql.source.local',
      'database.port': 3306,
      'database.user': 'debezium',
      'database.password': 'secret',
      'database.server.id': 1,
      'database.server.name': 'production',
      'table.include.list': 'mydb.users,mydb.orders',
      'topic.prefix': 'mysql',
      'transforms': 'route',
      'transforms.route.type': 'org.apache.kafka.connect.transforms.RegexRouter',
      'transforms.route.regex': "([^.]+)\\.([^.]+)\\.([^.]+)",
      'transforms.route.replacement': '$3',
    },
}

Avantages

• Decoupling : source et cible ne se touchent pas directement
• Flexibility : ajout facile de nouveaux consumers
• Auditability : historique complet des changes dans Kafka
• Replay capability : rejouer tous les events depuis un point donné

Inconvénients

• Infrastructure supplémentaire : Kafka, Zookeeper, Connect workers
• Operational complexity : monitoring multi-composants
• Latency : pas zero-latency, typiquement 100-500ms

Le schéma (tables, colonnes, index) est souvent aussi critique que les données.

Expand-Contract Pattern

La stratégie expand-contract en trois phases :

Phase 1 : Expand (préparation)

-- Ajouter la nouvelle colonne en parallel
ALTER TABLE users ADD COLUMN email_normalized VARCHAR(255);
ALTER TABLE users ADD CONSTRAINT email_normalized_uniq UNIQUE(email_normalized);

-- Application : avant INSERT/UPDATE, populer BOTH colonnes (dual write)
INSERT INTO users (email, email_normalized) VALUES
  ('john@example.com', 'john@example.com');

Phase 2 : Contract (bascule)

-- Passer l'ancienne colonne en "deprecated"
-- Application bascule sur la nouvelle colonne
-- Maintenir backward compatibility brièvement

-- Vérifier cohérence
SELECT COUNT(*) FROM users
WHERE email IS NOT NULL AND email_normalized IS NULL;

Phase 3 : Cleanup (nettoyage)

-- Après 2–3 jours sans incident
ALTER TABLE users DROP COLUMN email;
DROP INDEX email_normalized_uniq; -- si remplacé par primary key

Outils for schema evolution

Flyway (Java-centric)

-- V1.0__Initial_schema.sql
CREATE TABLE users (id SERIAL PRIMARY KEY, name VARCHAR(255));

-- V1.1__Add_email.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255);

flyway -url=jdbc:postgresql://localhost/mydb \
       -user=migrator \
       -password=secret \
       -locations=filesystem:db/migration \
       migrate

Liquibase (XML/YAML, plus verbose mais plus flexible)

databaseChangeLog:
  - changeSet:
      id: 1
      author: devops
      changes:
        - createTable:
            tableName: users
            columns:
              - column:
                  name: id
                  type: SERIAL
                  constraints:
                    primaryKey: true

gh-ost (for MySQL, no-locks)

gh-ost \
  --user=migrator \
  --password=secret \
  --host=mysql.prod.local \
  --alter="ADD COLUMN email VARCHAR(255), ADD UNIQUE INDEX idx_email (email)" \
  --database=mydb \
  --table=users \
  --execute

gh-ost crée une table shadow, la peuple en arrière-plan, puis bascule une fois synchronisée (zéro locks).

pgloader (PostgreSQL)

Outil all-in-one pour migrer vers PostgreSQL depuis MySQL, SQLite, Oracle, etc.

pgloader mysql://user:pass@source/dbname postgresql://user:pass@target/dbname

Features :

• Parallel data loading
• Automatic data type mapping (MySQL INT → PG INTEGER, etc.)
• Index and foreign key recreation

ora2pg (Oracle → PostgreSQL)

ora2pg -c ora2pg.conf

# Dans ora2pg.conf
ORACLE_HOME=/u01/app/oracle/product/21c
ORACLE_USER=scott
ORACLE_PASSWORD=tiger
OUTPUT=output.sql
TYPE=TABLE,INDEX,SEQUENCE,VIEW,PROCEDURE

Extracte le schéma, les données, les procédures stockées (avec traduction PL/SQL → PL/pgSQL).

AWS Database Migration Service (DMS) — concepts génériques

DMS applique les principes ci-dessus (change data capture, parallel loading) :

• Support multi-source (Oracle, MySQL, PostgreSQL, SQL Server)
• Heterogeneous migrations (Oracle → PostgreSQL)
• Replication continue
• Validation de données automatique

Note : Pas une obligation d'utiliser AWS — les mêmes concepts marchent on-premise avec Debezium + Kafka.

Avant d'appuyer sur le bouton :

Préparation

• Backup complet de la source (test de restore sur machine test!)
• Vérifier la compatibilité des versions (caractères spéciaux, encodage, collations)
• Documenter le schéma source (contraintes, triggers, séquences)
• Créer une matrice de mapping des types de données
• Dimensionner la cible (storage, CPU, RAM, network bandwidth)

Monitoring & Baseline

• Capturer les métriques de performance actuelles (query latency, throughput, CPU, memory)
• Configurer des alertes sur la source (connection count, disk space, replication lag)
• Préparer des dashboards (Prometheus, Grafana, DataDog, etc.)
• Vérifier l'espace disque : avoir 150% de l'espace utilisé pour la manœuvre

Communication

• Annoncer la maintenance window (48h minimum avant)
• Impliquer les équipes métier (tests de régression)
• Documenter le plan de rollback et responsables
• Prévoir un war room (Slack, calls) pendant la migration

Sauvegardes & Récupération

• Tester une restauration complète sur environnement de test (pas juste un backup!)
• Prévoir une VM snapshot de la source (système de fichiers ou volumique)
• Sauvegarder la configuration (postgresql.conf, my.cnf, etc.)

Une migration n'est jamais terminée tant qu'on n'a pas validé l'intégrité des données.

Data Integrity Checks

-- Compter les lignes
SELECT COUNT(*) FROM users; -- comparer source vs target

-- Checksum par table
SELECT
  table_name,
  MD5(CONCAT(CAST(COUNT(*) AS VARCHAR),
             CAST(SUM(CAST(id AS BIGINT)) AS VARCHAR)))
FROM information_schema.tables t
GROUP BY t.table_name;

-- Vérifier les séquences
SELECT last_value FROM users_id_seq;

-- Constraints
SELECT constraint_name, constraint_type
FROM information_schema.table_constraints
WHERE table_name = 'users';

Performance Comparison

-- Benchmark sur source (avant)
EXPLAIN ANALYZE
SELECT u.id, u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id
ORDER BY order_count DESC
LIMIT 100;

-- Répéter sur target (après)
-- Comparer : execution time, seq scans vs index scans

Query Regression Testing

# Exporter les top 100 queries de la source (via logs)
# Les rejouer sur la cible
# Comparer les temps (tolerance : +5-10%)

# Exemple avec pgBadger (PostgreSQL)
pgbadger -o report.html postgresql.log
# Analyser top slow queries

Rollback Procedures

# À T+2h si catastrophe
1. Couper le trafic vers Green
2. Vérifier que Blue est toujours en sync (replication lag)
3. Basculer le load balancer : trafic → Blue
4. Garder Green offline pour post-mortem
5. Lancer les tests de santé applicatifs

# Timing cible : < 15 min total

Pour approfondir vos connaissances sur des sujets connexes :

• PostgreSQL haute disponibilité avec Patroni : cluster HA + failover automatique
• Optimisation des performances PostgreSQL : indexation, vacuum, query planning
• Stratégies de sauvegarde et restauration (3-2-1) : backup planning, RTO/RPO
• Backup distribué avec rsync et hardlinks : incremental backups lean et rapides

• PostgreSQL Official Documentation : Logical Replication
• Debezium Project : CDC Connectors
• gh-ost GitHub : GitHub-hosted schema migration tool
• Flyway : Database migrations
• Liquibase : Database change management
• AWS DMS Concepts : Database Migration Best Practices (applicable beyond AWS)
• pgloader : Data loader for PostgreSQL
• Oracle to PostgreSQL Migration : ora2pg documentation

Les migrations de bases de données zéro-downtime sont devenues la norme, pas l'exception. Le choix entre blue-green, réplication logique, ou CDC dépend de vos contraintes :

Pour les migrations complexes en environnement multi-tenant ou haute-performance, SHPV accompagne ses clients via son offre Infogérance : audit d'architecture, planning détaillé, exécution 24/7 avec SLA 99.9%+, et war room dédiée.

Une migration réussie, c'est un projet qu'on ne remarque pas — les utilisateurs continuent à travailler, les données restent intègres, et l'équipe peut dormir sereinement.