La réplication logique de PostgreSQL transmet les modifications d’une base source vers une base cible sous forme d’un flux d’opérations (insertions, mises à jour, suppressions), rejouées en continu. Disponible depuis la version 10, c’est elle qui rend une sortie de RDS gérable sans coupure longue.
La réplication logique synchronise RDS et la nouvelle base en continu, puis vous basculez en quelques minutes, sans perte de données. Le vrai chantier arrive après : sauvegardes, mises à jour, supervision, tout ce que RDS faisait sans le dire revient à votre charge.
Migrer les données sans perte
Vous déclarez la nouvelle base comme abonnée à RDS. Elle rejoue les écritures au fil de l’eau pendant que l’application travaille normalement. Quand le retard de réplication tombe à zéro et que les deux bases sont alignées, vous basculez : la seule coupure visible, c’est le temps de repointer la connexion. Quelques minutes.
RDS bride toutefois ce que vous pouvez configurer côté source. Certaines versions anciennes coincent, et un schéma mal taillé aussi : une grosse table sans clé primaire, par exemple, met la réplication en échec. Quand le terrain ne s’y prête pas, je passe par un dump/restore (un export complet de la base d’un côté, réimporté de l’autre) sur une fenêtre planifiée de nuit. Plus long, mais sans surprise.
Ce que RDS faisait dans votre dos
Le vrai travail est là. Pendant des mois, AWS a tenu des choses que vous ne voyiez pas :
- Les sauvegardes automatiques. À reconstruire, puis à tester en restauration réelle, pas seulement à programmer.
- La haute disponibilité. Une réplique en attente, avec une bascule automatique ou au moins documentée et répétée.
- Les mises à jour mineures. À planifier vous-même, fenêtre comprise.
- La supervision. Connexions ouvertes, espace disque, saturation, et des alertes qui partent avant que ça casse.
Rien d’insurmontable. Mais c’est précisément le genre de tâche qu’on repousse. J’ai repris une base auto-gérée sur un site de production où « les sauvegardes tournaient » : le cron (la tâche planifiée censée lancer la sauvegarde chaque nuit) crachait des fichiers de 40 octets depuis cinq semaines, et personne n’avait regardé. Une sauvegarde qu’on n’a jamais restaurée ne protège de rien — elle empile des fichiers en espérant.
Le réflexe qui change tout
Une priorité avant tout le reste : une fois la connexion repointée, votre première action sur la nouvelle base n’est pas de la mettre en production. C’est de prendre une sauvegarde et de la restaurer ailleurs, immédiatement, pour vérifier qu’elle remonte. Vous saurez alors que votre filet existe avant d’en avoir besoin. Le reste (réplique de secours, supervision, fenêtres de mise à jour) se met en place dans les jours qui suivent, sans urgence.