Vous n'êtes pas identifié(e).
Pages : 1
Bonjour.
Je suis nouveau avec PostgreSQL, bien que j'ai travaillé dans le passé avec d'autres sgbd (MySQL, Sybase).
J'ai deux serveurs de bases de données avec des données SIG. Le premier mis en place par mon prédécesseur et le second par moi-même, sur deux machines différentes. Ce sont les mêmes versions de PostgreSQL (9.5.9) sur deux machines de type Ubuntu 16.04.
J'ai fait un dump avec pg_dump sur la première machine, sans problème, en quelques minutes.
Mais lorsque je tente d'importer le dump sur la seconde machine, la commande tourne indéfiniment (plus de 12h après quoi, j'ai tué le process), sans résultat. Malgré l'option --verbose, je n'ai aucun message. En me connectant au serveur bdd via PgAdmin, je ne vois absolument rien apparaître, pas une table, mais pas la bdd elle-même.
Bref, cela donne l'impression que la commande est bloquée avant même son exécution.
La commande passée est
pg_restore --verbose --host=localhost --username=postgres --clean --file=/chemin/vers-le/dump.sql
J'ai essayé aussi avec un fichier de type .dump sans plus de résultat. Le fichier de dump sql fait 75 Mo, le fichier de dump en .dump fait 17 Mo.
Une idée sur l'origine de ce problème ?
Dernière modification par Ulysse (31/10/2017 10:40:29)
Hors ligne
La réponse est dans la doc de pg_restore : https://docs.postgresql.fr/9.5/app-pgrestore.html
pg_restore [option_connexion...] [option...] [nom_fichier]
[...]
-f nom_fichier, --file=filename
Spécifie le fichier en sortie pour le script généré ou pour la liste lorsqu'elle est utilisée avec -l. Par défaut, il s'agit de la sortie standard.
Julien.
https://rjuju.github.io/
Hors ligne
Effectivement, bourde de ma part, en mettant comme paramètre pour le fichier de sortie celui d'entrée, cela ne risquait pas bien d'aller.
Je n'ai par contre pas compris pourquoi les options --dbname et --file ne sont pas compatibles ...
En tous cas, merci pour l'aide.
J'ai modifié ma commande en :
pg_restore --host=localhost --username=postgres --dbname=scoters --clean /chemin/vers-le/monDump.dump > restore_dump.log 2>&1Je suis donc repassé sur le fichier .dump et j'ai enlevé le --verbose, mais j'ai redirigé le stdout et stderr dans un fichier de log pour faciliter l'analyse.
Bien sûr, j'ai quelques erreurs. Certaines étaient dûes à l'absence des certains rôles dans le serveur cible. C'est rectifié.
Pour les autres erreurs, c'est moins évident.
J'ai eu des erreurs sur des DROP INDEX pour des index qui n'existaient (pas n'est vraiment une erreur, me semble t'il), mais je ne comprenais pas pourquoi j'avais ce genre d'erreur alors que j'ai mis l'option --clean , puis en relisant la doc, j'ai ajouté la commande --create et c'est allé mieux.
J'ai toujours des soucis à comprendre l'utilisation de l'option --dbname : si je ne le mets pas, je me retrouve avec dans on fichier de log l'intégralité des commandes sql (77 Mo de logs ..). Si je mets le nom de la bdd à recréer, j'ai une erreur car il ne peut pas faire le DROP DATABASE de la bdd dans laquelle il est connecté. Par défaut, j'ai mis une autre bdd vide, hésitant à mettre directement postgres .
Une autre erreur que j'ai est liée à l'absence de l'extension postgis. Il faut donc que je l'installe.
Dernière modification par Ulysse (19/10/2017 16:23:41)
Hors ligne
Et après installation des paquets postgis , postgresql-9.5-postgis-scripts , postgresql-9.5-postgis , la commande suivante a l'air de fonctionner, sans erreur d'après les logs :
pg_restore --host=localhost --verbose --username=postgres --dbname=une_autre_base_existante --clean --create /chemin/vers-le/monDump.dump > restore_dump.log 2>&1 Je suis toutefois encore preneur de un conseil ou deux ..
Hors ligne
--dbname est le nom de la base de connexion. Donc si vous indiquez le nom de la base à supprimer puis créer, il ne peut plus le faire vu qu'il est connecté (et on ne peut pas supprimer une base si on est connecté dessus). Donc, dans le cas où vous utilisez l'option --clean, l'option --dbname doit préciser le nom d'une base de connexion qui n'est pas celle à créer. Il trouve le nom de la base à créer dans l'archive et correspond au nom de la base sauvegardée. Donc généralement, on fait un --dbname postgres pour ne pas avoir à créer une base vierge pour ça.
Guillaume.
Hors ligne
Merci pour cette confirmation.
Par contre, je cherche comment préciser dans quel tablespace je veux que la base de données soit créée. Je ne vois pas d'option pour cela dans pg_restore et je n'ai pas encore trouvé non plus comment préciser au serveur PostgreSQL dans quel tablespace il devrait créer les nouvelles db par défaut.
Hors ligne
Vous pouvez soit manuellement créer une base de données dans le bon tablespace, et ne pas utiliser les options clean et create, soit configurer le paramètre default_tablespace sur le serveur. Dans le second cas, ce paramètre s'appliquera à toute l'instance. Vous pouvez sinon configurer ce paramètre à un utilisateur en particulier (alter role nom_role set default_tablespace = 'blabla').
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour.
J'ai fait un SET default_tablespace = <mon_tablespace> ;
puis j'ai fait un CREATE DATABASE test ; pour vérifier où elle était créée et elle a malgré tout été créée dans le tablespace pg_default et non pas dans mon_tablespace ...
Qu'est ce qui ne va pas ?
Hors ligne
default_tablespace n'est utilisé que pour la création de tables et index où l'option tablespace n'est pas précisée. Pour une base, il faut le spécifier manuellement.
Julien.
https://rjuju.github.io/
Hors ligne
Il n'y a donc pas de manière de spécifier le tablespace pour une base pas encore créée ?
Hors ligne
bonjour,
si comme le dit rjuju :
CREATE DATABASE toto OWNER tata_ventes TABLESPACE titi;
Cordialement,
Sébastien.
Hors ligne
Pages : 1