J'ai une application en production qui utilise PostgreSQL 12 et j'ai besoin de mettre à jour vers la version 15. J'ai lu des choses sur pg_dump mais je ne suis pas sûr si c'est la meilleure option pour une base de données de près de 50 Go. Quelqu'un l'a déjà fait sans downtime ?
Ne fais pas un simple pg_dump et restore sur une base de données vide si tu ne veux pas avoir des heures de downtime - utilise plutôt pg_upgrade qui s'exécute sur le même serveur sans besoin d'exporter/importer, ou si tu veux migrer vers un autre serveur utilise la réplication logique pour garder l'app en fonction pendant la synchronisation. Avec 50GB tu vas économiser un tas de temps et de stress en le faisant de cette façon.
Votre application peut rester un moment sans écrire en base de données ou vous avez absolument besoin de zéro downtime ? Si vous pouvez arrêter les écritures ne serait-ce que 5-10 minutes, pg_upgrade est votre meilleure amie car il convertit les fichiers sur le même disque sans rien exporter, donc avec 50 GB vous économisez des heures. Maintenant, si vous avez besoin d'éviter complètement le downtime, il y a une astuce que peu de gens mentionnent : vous pouvez utiliser la réplication logique (logical replication) pour synchroniser l'ancienne base de données avec la nouvelle en parallèle pendant qu'elle continue de fonctionner, puis vous basculez quand tout est à jour - c'est un peu plus compliqué à configurer mais c'est du gold si vous ne pouvez pas arrêter le service. Cela dit, avant toute chose, testez-le dans un environnement de staging même avec un dump de quelques GB pour voir combien de temps cela prend dans votre setup spécifique.
T'as déjà vérifié si ta version 12 est directement compatible avec la 15, ou tu dois passer par des versions intermédiaires ? Ce que personne ne mentionne, c'est qu'en plus de pg_upgrade, tu devrais vraiment faire une sauvegarde complète avant quoi que ce soit, parce que même si pg_upgrade est assez fiable, avoir ce backup te donne la tranquillité d'esprit - surtout avec 50GB. Si tu dois absolument éviter un downtime complet, il existe la réplication logique (logical replication) où tu configures une instance secondaire avec la version 15, tu la synchronises en parallèle et ensuite tu fais un failover quand elle est prête, mais c'est plus complexe. La plupart des gens que je connais finissent par choisir pg_upgrade avec une fenêtre de maintenance courte parce que c'est le plus pratique et le plus rapide pour un volume comme ça.
Avec 50GB tu dois être prudent mais pg_upgrade est vraiment la bonne option si tu peux tolérer ce downtime de 5-10 minutes. Ce que la plupart ne mentionnent pas c'est que PostgreSQL 12 à 15 c'est un saut que pg_upgrade gère sans problème en une seule passe, donc tu n'as pas besoin de versions intermédiaires. Mon conseil : avant toute chose, fais une sauvegarde complète avec pg_basebackup ou pg_dump en parallèle (utilise pg_dump avec l'option -j pour paralléliser, ça réduit pas mal le temps), et puis exécute pg_upgrade sur ton serveur de production pendant une fenêtre de maintenance. Cela dit, après l'upgrade lance ANALYZE sur les grandes tables parce que certaines statistiques internes changent et tu pourrais avoir des requêtes lentes si tu ne le fais pas.
Écoute, si tu peux tolérer au moins 10-15 minutes d'interruption, pg_upgrade est clairement ton meilleur choix parce qu'il fait la migration sur le même serveur sans exporter/importer toutes les données (avec 50 GB ça t'économise un temps fou). Ce que personne n'a mentionné ici, c'est qu'avant quoi que ce soit, tu dois vérifier s'il y a des extensions installées qui ne sont pas compatibles entre les versions, parce que ça peut bloquer tout le processus au dernier moment et te laisser avec des mauvaises surprises une fois que tu es déjà en train de faire la conversion. Mon conseil : fais quand même une sauvegarde complète avec pg_basebackup (au cas où), teste tout sur un serveur de staging d'abord, et après là tu peux lancer pg_upgrade en production.
Se connecterpour répondre.
