Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 06/01/2019 16:01:37
- cecile
- Membre
problème avec pg_dumpall
Bonjour
J'ai deux VM h1 et h2 avec l'os Red Hat Enterprise Linux Server release 6.5 (Santiago)
et (PostgreSQL) 9.3.5.
sur la VM h1, j'ai fait nohup pg_dumpall > all.sql &. Puis, j'ai transféré all.sql sur la VM h2
sur la VM h2, j'ai fait nohup psql -f all.sql &. (import)
Sur h2, à la fin de l'import, je constate que : ma base ma_base n'a pas bougée. Elle aurait du grossir car ma_base depuis h1 est plus grosse.
Mais la base postgres a grossi. Sa taille est sensiblement égale à celle de ma_base.
une requette sur la base postgres donne le même resultat que sur la base ma_base.
C'est comme si on avait importé la base ma_base sur la base postgres.
Il y a t'il une expplication à cela ? Est ce un bug ?
Peut-on dropper la base postgres et la recréer ( createdb postgres with template template1 )sans crainte ?
puis faire l'export, sur h1, de ma_base (nohup pg_dump ma_base > ma_base.sql &) et l'importer sur h2 avec la commande
nohup psql ma_base < ma_base.sql) ?
Merci pour vos retours
Cordialement
Cecile
Hors ligne
#2 06/01/2019 16:26:40
- gleu
- Administrateur
Re : problème avec pg_dumpall
Il y a t'il une expplication à cela ? Est ce un bug ?
Il faudrait regarder les erreurs renvoyées par la commande pg_dumpall, difficile à dire ainsi.
On peut cependant très honnêtement écarter à 99,99% l'éventualité d'un bug.
Peut-on dropper la base postgres et la recréer ( createdb postgres with template template1 )sans crainte ?
Oui. Par contre, il faudra la recréer en se connectant au serveur à partir d'une autre base et y lancer un CREATE DATABASE (createdb se connecte automatiquement sur la base postgres, or vous l'aurez déjà détruite...).
puis faire l'export, sur h1, de ma_base (nohup pg_dump ma_base > ma_base.sql &) et l'importer sur h2 avec la commande
nohup psql ma_base < ma_base.sql) ?
Il serait beaucoup plus intéressant de comprendre pourquoi la restauration du script de pg_dumpall n'a pas fonctionné. Mais sinon, oui, ça fonctionnera à condition d'utiliser l'option "-h h2" pour psql.
Guillaume.
Hors ligne
#3 06/01/2019 16:47:52
- cecile
- Membre
Re : problème avec pg_dumpall
Bonjour Guillaume,
Pour commencer, une très bonne et heureuse année 2019. Surtout bonne santé.
Merci pour tes réponses.
Je n'ai pas bien compris ce que tu veux dire par : "Mais sinon, oui, ça fonctionnera à condition d'utiliser l'option "-h h2" pour psql."
Encore un grand merci.
Cecile
Hors ligne
#4 06/01/2019 16:56:32
- cecile
- Membre
Re : problème avec pg_dumpall
En fait pour la création et la suppression de la base postgres, je peux le faire avec dropdb et createdb en tant que postgres.
psql -c "drop database postgres" »
psql -c "create database postgres" template1 »
N'est ce pas ?
Hors ligne
#5 06/01/2019 19:01:15
- rjuju
- Administrateur
Hors ligne
#6 06/01/2019 23:25:12
- cecile
- Membre
Re : problème avec pg_dumpall
Bonne année et bonne santé Julien.
Merci
Cecile
Hors ligne
#7 07/01/2019 10:58:45
- gleu
- Administrateur
Re : problème avec pg_dumpall
Il y a de forte chance que la première commande ne passe pas, surtout si vous êtes connectée en tant qu'utilisateur postgres. Pour être sûr que cela fonctionne, faites plutôt :
psql -c "drop database postgres" template1
Le coup de l'option "-h s1" est pour que psql se connecte au serveur s2. Sinon ce sera importé sur s1.
Guillaume.
Hors ligne
#8 07/01/2019 19:07:32
- dverite
- Membre
Re : problème avec pg_dumpall
C'est comme si on avait importé la base ma_base sur la base postgres.
Il y a t'il une expplication à cela ? Est ce un bug ?
En principe ça ne peut pas arriver avec les commandes indiquées parce que
- pg_dumpall place un \connect nomdelabase dans le script avant les ordres de restauration de cette base
- et psql -f all.sql quitte immédiatement si ce \connect échoue
donc comment ça pourrait restaurer dans la mauvaise base?
A contrario c'est une erreur classique de restaurer un dump individuel (pas pg_dumpall) dans la base postgres parce qu'on a oublié un -d à psql, personnellement ça m'est arrivé plus d'une fois.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1