Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Installation » Linux: Systemd plusieurs services Postgresql ? » 31/10/2017 12:05:47
C'est parfait, merci !
J'ai fait une archive avec les fichiers de conf de la version 9.3 et arrêté l'ensemble de postgresql.
#2 Installation » Linux: Systemd plusieurs services Postgresql ? » 31/10/2017 10:50:18
- Ulysse
- Réponses : 2
Bonjour.
Je suis sous Linux Mint 18, anciennement 17.3 mais upgradé.
Durant l'upgrade, Postgresql est passé de la version 9.3 à la 9.5 et c'est tant mieux.
Par contre, c'est un peu confus avec systemd. Lorsque je lance la commande pour lister les services du système ( systemctl list-units --type=service --all ) , je vois apparaître trois services postgresql :
postgresql.service loaded active exited PostgreSQL RDBMS
● postgresql@9.3-main.service loaded failed failed PostgreSQL Cluster 9.3-main
postgresql@9.5-main.service loaded active running PostgreSQL Cluster 9.5-main
Le package de Postgresql 9.3 n'est plus installé sur l'ordinateur et c'est donc normal que le démarrage de ce service plante. Mais bon, l'ordinateur mouline pour rien au démarrage.
Par contre, je n'arrive pas à empêcher :
- la tentative de démarrage automatique de Postgresql 9.3 qui ne sert à rien
- le démarrage automatique de Postgresql 9.5, car je voudrais que le Postgresql soit lancé uniquement sur commande manuelle.
Les commandes "systemctl disable postgresql@9.3-main.service" (et idem pour 9.5) n'ont pas eu d'effet.
Dans /etc/systemd/system/multi-user.target.wants j'ai bien un fichier postgresql.service, mais je n'en trouve pas d'autre.
#3 Re : Installation » [Résolu] Problème de restoration de dump » 20/10/2017 16:04:30
Il n'y a donc pas de manière de spécifier le tablespace pour une base pas encore créée ?
#4 Re : Installation » [Résolu] Problème de restoration de dump » 20/10/2017 09:43:13
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 ?
#5 Re : Installation » [Résolu] Problème de restoration de dump » 19/10/2017 18:56:13
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.
#6 Re : Installation » [Résolu] Problème de restoration de dump » 19/10/2017 17:21:15
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 ..
#7 Re : Installation » [Résolu] Problème de restoration de dump » 19/10/2017 16:23:24
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.
#8 Installation » [Résolu] Problème de restoration de dump » 19/10/2017 13:02:16
- Ulysse
- Réponses : 10
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 ?
Pages : 1