Discussion :

[turlut]

Bonjour

actuellement nous travaillons sur 2 serveurs de développement, l'un vraiment en tests, l'autre en "pré-intégration".

Sur les 2 serveurs, nous avons une base PostgreSQL 9.1.3 sur laquelle sont installées plusieurs bases utilisateurs - plusieurs roles, chacun ayant son tablespace et son schéma.

Il nous arrive régulièrement de faire un dump d'une base (comprenez 1 role ayant le même nom que sa base et ses objets) sur l'un des serveurs et de le restaurer sur l'autre serveurs qui héberge le même role avec les objets également.

Parfois, lors de la restauration, tous les objets de la base restaurée à partir du dump sont bien là, mais on a également des tables / autres objets appartenant à d'autres bases... Pourtant, en manipulant le fichier dump de la sauvegarde, les objets des autres roles n'y apparaissent pas.

Je ne sais pas si je suis très clair...

Sur mon serveur A, j'ai une base toto, avec un tablespace tbs_toto, un role de connexion toto qui est propriétaire des objets de la base toto. Je fais un dump de la base toto : $PGBIN/pg_dump --format custom $db > $fichier_custom

Sur mon serveur B, j'ai une base toto, avec un tablespace tbs_toto, un role de connexion toto qui est ....bref, comme le serveur A. Sur celui-ci, je fais une resto de la base toto à partir du dump fait sur le serveur A : $PGBIN/pg_restore --clean --dbname $nombase $fichier_custom

Lorsque je regarde la base restaurée sur le serveur B, j'ai bien tous les objets de toto, mais j'ai également des tables appartenant à d'autres bases !!

où est l'erreur dans la manipulation que je fais ?

Merci d'avance pour toutes vos suggestions.

[estofilo]

Le --clean de pg_restore indique d'effacer les objets présents dans le dump au fur et à mesure qu'ils sont recréés, mais sans toucher aux autres objets potentiellement présents dans la base cible.

Pour faire vraiment le ménage dans la base cible faire DROP DATABASE et CREATE DATABASE avant de rejouer le dump.

[turlut]

Bonjour

dans la base cible, il n'y a pas les objets que j'y retrouve après le restore .. C'est bien là tout mon problème.

Le fait de faire un drop database et create ne m'arrange pas car je j'utilise des tablespace pour chaque application. Peut-être est-ce cela qui est mal géré en version 9.1.3 ??

Pour rappel, j'ai sur le même sgdb postgres, une dizaine de bases de données ( toto, titi, tutu etc..) chacune a son tablespace toto_data , titi_data, tutu_data .. , chacune a un role de connexion toto, tata, titi qui est propriétaire de ses objets qui sont dans la base de données du même nom.

Qu'est ce qui peut bien faire qu'en restaurant titi d'un autre serveur qui a exactement les mêmes bases, je me retrouve avec quelques tables de tutu, de titi, dans la base toto que je viens de restaurer ?

Serait-ce un problème de reconnaissance de l'id des objets ? Pourtant chaque schéma est bien séparé des autres.

[estofilo]

Le fait de faire un drop database et create ne m'arrange pas car je j'utilise des tablespace pour chaque application. Peut-être est-ce cela qui est mal géré en version 9.1.3 ??

Je ne saisis pas le raisonnement. En quoi l'usage de tablespaces gênerait un DROP DATABASE? Le DROP DATABASE ne supprime pas de tablespace.

Pour recréer la base il suffirait de faire CREATE DATABASE toto TABLESPACE=tablespace_de_toto;

Au passage, il ne faut pas utiliser 9.1.3 mais mettre à jour en 9.1.14.

D'une manière générale la numérotation des versions postgresql est X.Y.Z où X.Y est la version majeure et Z le niveau de correctif. Il faut toujours utiliser le correctif le plus récent.

[turlut]

oui, oui, je suis d'accord avec vous .. c'est pour faire vite et simple que nous chargeons une base de tests à partir de l'une de production.

Je vais tester de faire le drop, create.

En revanche, je ne suis pas maitre de la version postgres utilisée. On me l'impose. Je suis donc contraint de rester en 9.1.3 jusqu'à décision en haut lieu.