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 ?
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.
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.
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.
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.
PostgreSQL 12 à 15 fonctionne directement sans passer par les versions intermédiaires, donc pg_upgrade est ton chemin. Ce qui compte vraiment ici, c'est qu'avant de lancer pg_upgrade, tu dois faire une sauvegarde complète avec pg_dump ou une sauvegarde physique - pas pour la migration elle-même, mais comme filet de sécurité. Beaucoup de gens sautent cette étape parce qu'ils font confiance à pg_upgrade pour fonctionner, mais si quelque chose se passe mal avec 50 GB de données, tu ne veux vraiment pas être en train de prier.
Le processus est plutôt direct : tu installes PostgreSQL 15 sur le même serveur (ou sur un serveur parallèle si tu préfères), tu arrêtes les écritures dans la BD, tu lances pg_upgrade avec le flag `-k` pour garder les anciens fichiers comme sauvegarde, et laisse-le tourner. Avec 50 GB ça peut prendre 5-15 minutes selon le matériel, mais après tu as tout converti sur place sans exporter/importer quoi que ce soit. Une fois que tu confirmes que tout fonctionne bien, c'est seulement là que tu supprimes les anciens fichiers de la version 12.
Ce qui est important et que tu ne vois pas mentionné partout, c'est vérifier les extensions et les configurations custom. Si tu as des extensions installées, pg_upgrade peut avoir des problèmes - tu dois qu'elles existent aussi dans PostgreSQL 15. Avant de faire quoi que ce soit, vérifie `SELECT extname FROM pg_extension;` dans ta BD actuelle et confirme que toutes ces extensions supportent la version 15. C'est là que ça échoue le plus souvent, pas vraiment dans la migration de données elle-même.
Se connecterpour répondre.
