L’un des défis majeurs lors de la migration d’une base de données de production est de minimiser la fenêtre d’interruption pour les utilisateurs. Pour les systèmes critiques, un arrêt de plusieurs heures est tout simplement inacceptable.
C’est ici que pgcopydb se distingue en intégrant nativement un mécanisme de capture des changements de données (Change Data Capture ou CDC) via son option --follow. Cet article explique comment fonctionne cette réplication en continu et comment l’utiliser pour réussir une migration « zéro downtime ».
Le principe du mode Follow
Le mode --follow de pgcopydb s’appuie sur la réplication logique de PostgreSQL. Il permet de maintenir la base de données cible synchronisée avec la source en temps réel, même pendant et après la copie initiale des données.
Le processus se déroule en trois étapes clés :
Étape 1 : Création du slot de réplication et snapshot consistant
Avant de copier le moindre octet, pgcopydb crée un slot de réplication logique sur le serveur source. Ce slot sert de repère. PostgreSQL va commencer à conserver tous les changements (WAL – Write-Ahead Logs) qui se produisent à partir de cet instant précis.
Grâce à l’utilisation d’un identifiant de transaction partagé (snapshot exporté), la copie initiale des données se fait dans un état parfaitement cohérent avec le point de départ du slot de réplication.
Étape 2 : Copie initiale et buffering
Pendant que pgcopydb copie les données historiques en parallèle, des transactions continuent d’avoir lieu sur la base source. Les modifications correspondantes sont capturées par le slot de réplication logique et stockées temporairement dans le journal de transactions (WAL) de la source.
Étape 3 : Le rattrapage (Catch-up)
Une fois la copie initiale terminée et les index reconstruits, pgcopydb passe en mode réplication active. Ii consomme les modifications accumulées dans le slot de réplication et les applique sur la base cible. Cette phase de rattrapage se poursuit jusqu’à ce que la cible soit synchronisée à quelques millisecondes près avec la source.
Commandes clés pour une migration Live
Pour exécuter une migration complète avec CDC, la commande principale est :
pgcopydb clone --follow
Cette commande orchestre tout le cycle :
1. Connexion aux bases source et cible.
2. Configuration du slot de réplication logique.
3. Copie du schéma, des données, puis reconstruction des index.
4. Passage automatique en mode synchronisation continue.
Le switchover (bascule)
Une fois que la cible est synchronisée et que le décalage (lag) est proche de zéro :
1. Passez temporairement l’application source en mode lecture seule (ou coupez les écritures).
2. Attendez quelques secondes que pgcopydb applique les dernières modifications résiduelles.
3. Arrêtez le processus pgcopydb.
4. Mettez à jour les chaînes de connexion de vos applications pour pointer vers la nouvelle base de données cible.
5. Ouvrez les accès en écriture sur la cible.
Prérequis et bonnes pratiques
Pour assurer le succès d’une migration avec --follow, plusieurs configurations sont requises sur le serveur source :
wal_level = logical: Ce paramètre est obligatoire dans le fichierpostgresql.confde la source pour permettre le décodage logique.- Espace disque pour le WAL : Sur la source, assurez-vous d’avoir suffisamment d’espace disque. Si la copie initiale prend du temps et que l’activité en écriture est intense, PostgreSQL va accumuler beaucoup de journaux WAL.
max_replication_slotset `max_wal_senders` : Ce paramètre doit être configuré pour autoriser au moins une connexion de réplication logique supplémentaire.- Nettoyage final : N’oubliez pas d’arrêter proprement pgcopydb à la fin pour qu’il détruise le slot de réplication logique créé sur la source. Un slot de réplication actif mais non consommé peut saturer le disque de la source à terme.
Conclusion
Le mode --follow de pgcopydb démocratise les migrations à chaud en encapsulant une technologie complexe (le décodage logique) dans un outil simple à utiliser. C’est l’outil idéal pour migrer des bases de production critiques vers de nouveaux serveurs physiques, des machines virtuelles ou des instances cloud avec une interruption minimale.
Ressources Officielles
- Dépôt GitHub : dimitri/pgcopydb
- Documentation Officielle : Documentation pgcopydb