Technical Tutorials

La migration de bases de données est l'une des tâches les plus critiques et à haut risque en ingénierie logicielle. Que vous passiez de la version 9.6 à la 15, que vous migriez de serveurs on-premise vers une infrastructure cloud comme AWS RDS, ou que vous changiez de fournisseur d'hébergement, une migration échouée peut entraîner une perte de données et des interruptions importantes. Ce guide explore les méthodes les plus fiables pour migrer des bases de données PostgreSQL, en équilibrant sécurité, rapidité et minimisation des perturbations.

Choisir la bonne stratégie

Avant de plonger dans les commandes, vous devez sélectionner la stratégie appropriée en fonction de votre tolérance aux interruptions et du volume de données. Les deux approches principales sont la sauvegarde et la restauration logiques et la réplication physique/logique.

Sauvegarde logique (pg_dump) : Idéale pour les bases de données petites à moyennes ou lorsque des interruptions minimales sont acceptables. Elle exporte les données sous forme de fichiers SQL ou au format personnalisé.
Réplication logique : Parfaite pour les grandes bases de données nécessitant des interruptions quasi nulles. Elle transmet les modifications en temps réel jusqu'au basculement final.

Méthode 1 : Utilisation de pg_dump et pg_restore

L'utilitaire pg_dump est la norme de l'industrie pour les sauvegardes logiques. Il prend en compte le schéma et peut gérer des types de données complexes, des fonctions et des déclencheurs. Pour les environnements de production, utilisez toujours le format personnalisé (-Fc) pour permettre une restauration parallèle et une récupération sélective des tables.

Étape 1 : Créer la sauvegarde

Connectez-vous à votre base de données source et générez une archive compressée au format personnalisé.

# Sauvegarder toutes les tables, schémas et données
pg_dump -h old-db-host -p 5432 -U postgres -Fc -f production_backup.dump mydb

# Pour les grandes bases de données, utilisez des travailleurs parallèles pour accélérer le processus
pg_dumpall -h old-db-host -p 5432 -U postgres -Fc -f full_cluster_backup.dump

Étape 2 : Transférer et restaurer

Transférez en toute sécurité le fichier de sauvegarde vers le nouveau serveur à l'aide de scp ou du stockage cloud. Ensuite, restaurez les données dans la nouvelle instance. La restauration parallèle est cruciale pour les performances.

# Créer une base de données vide sur la nouvelle instance
createdb -h new-db-host -U postgres mydb_new

# Restaurer avec des travailleurs parallèles
pg_restore -h new-db-host -p 5432 -U postgres -d mydb_new -j 4 --no-owner production_backup.dump

Note : L'option --no-owner garantit que l'utilisateur actuel possède tous les objets, évitant ainsi les problèmes de permissions si l'utilisateur d'origine n'existe pas sur le nouveau serveur.

Méthode 2 : Zéro interruption via la réplication logique

Pour les bases de données massives où les interruptions sont inacceptables, la réplication logique permet à la nouvelle instance de rester synchronisée avec l'ancienne. Cela nécessite PostgreSQL 10 ou une version ultérieure.

Étapes de configuration

Base de données source : Activez l'archivage WAL ou assurez-vous d'avoir suffisamment de max_wal_senders.
Base de données cible : Créez un slot de réplication.
Initialisation : Utilisez pg_basebackup pour la configuration physique ou des slots de réplication logique pour une synchronisation purement logique.

Sur le serveur cible, créez un slot de réplication pour conserver les enregistrements WAL :

CREATE REPLICATION SLOT my_rep_slot LOGICAL "pgoutput";

Sur le serveur source, publiez toutes les tables pour la réplication :

CREATE PUBLICATION my_pub FOR ALL TABLES;

Sur la cible, créez un abonnement pour commencer le flux de données :

SUBSCRIBE my_sub TO my_pub
CONNECTION 'host=old-db-host port=5432 user=replicator password=secret'
WITH (copy_data = true);

Une fois que l'abonnement est à jour (vérifiez en consultant pg_stat_subscription), vous pouvez arrêter les écritures vers l'ancienne base de données, effectuer le basculement final et supprimer l'abonnement.

Vérification et bonnes pratiques

N'acceptez jamais une migration sans vérification. Après la restauration, exécutez des requêtes de sommes de contrôle pour comparer le nombre de lignes et des échantillons de données critiques entre la source et la cible.

-- Vérifier le nombre de lignes d'une table critique
SELECT COUNT(*) FROM orders;

-- Vérifier l'intégrité des clés étrangères manquantes
SELECT COUNT(*) FROM child_table WHERE id NOT IN (SELECT id FROM parent_table);

Les principales bonnes pratiques incluent :

Tester en pré-production : Répétez toujours la migration dans un environnement similaire à la production au préalable.
Sauvegarder avant la migration : Assurez-vous d'avoir une sauvegarde complète de la source avant de commencer.
Surveiller l'E/S disque : Les grandes sauvegardes peuvent saturer la bande passante du disque ; planifiez pendant les heures creuses si vous utilisez pg_dump.
Compatibilité du schéma : Si vous passez d'une version majeure à une autre (par exemple, de 9.6 à 12), vérifiez les fonctionnalités obsolètes à l'aide du mode de vérification de pg_upgrade.

Conclusion

Le choix du bon chemin de migration dépend de vos contraintes spécifiques. Pour la plupart des applications, pg_dump avec un formatage personnalisé offre une solution robuste et simple. Cependant, pour les systèmes critiques avec des exigences de haute disponibilité, la réplication logique fournit le filet de sécurité de la synchronisation en temps réel. En suivant ces étapes et en vérifiant rigoureusement l'intégrité des données, vous pouvez migrer des bases de données PostgreSQL avec confiance et un risque minimal.