Vous n'êtes pas identifié(e).
Pages : 1
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
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
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
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
Hors ligne
Bonne année et bonne santé Julien.
Merci
Cecile
Hors ligne
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" template1Le coup de l'option "-h s1" est pour que psql se connecte au serveur s2. Sinon ce sera importé sur s1.
Guillaume.
Hors ligne
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