Skip site navigation (1) Skip section navigation (2)

Re: BD impossible à recharger

From: Alain <eurlix(dot)alain(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Subject: Re: BD impossible à recharger
Date: 2012-04-05 20:15:52
Message-ID: 20120405221552.83fb0c59.eurlix.alain@free.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generalepgsql-general
On Thu, 05 Apr 2012 21:20:57 +0200
Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:

> On Thu, 2012-04-05 at 21:19 +0200, Guillaume Lelarge wrote:
> > On Thu, 2012-04-05 at 21:03 +0200, Alain wrote:
> > > On Thu, 5 Apr 2012 20:02:48 +0200
> > > Alain <eurlix(dot)alain(at)free(dot)fr> wrote:
> > > 
> > > > On Thu, 05 Apr 2012 18:38:51 +0200
> > > > Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
> > > > 
> > > > > On 04/05/2012 06:25 PM, Alain wrote:
> > > > > >
> > > > > > Autant que je me rappelle, le premier message d'erreur concernait un
> > > > > > utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> > > > > > créé l'utilisateur et relancé. 
> > > > > 
> > > > > En effet, les objets globaux ne sont pas créés par pg_restore.
> > > > > 
> > > > > Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
> > > > > récupérer la liste des users et groups
> > > > > 
> > > > > > J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> > > > > > indispensable.
> > > > > > J'avais peut-être lancé initialement la restauration sans le "-c" et
> > > > > > certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> > > > > > majeure partie des tables sont créées (98/102).
> > > > > > Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> > > > > > problème et mes souvenirs peuvent être un peu confus.
> > > > > > Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> > > > > > situation initiale et recommencer à zéro ?
> > > > > >
> > > > > 
> > > > > Je vous conseille en effet cette option (dropdb puis createdb à
> > > > > nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
> > > > > le risque d'erreurs.
> > > > > 
> > > > > -- 
> > > > > Sébastien Lardière
> > > > > Hi-Media Nantes
> > > > > DBA PostgreSQL
> > > > > 0228082071 / 0626595833
> > > > > 
> > > > > 
> > > > > -- 
> > > > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > > > To make changes to your subscription:
> > > > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > > > > 
> > > > Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
> > > > mauvais nom (pas abonné) :
> > > > Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
> > > > 
> > > > J'ai lancé : pg_restore --list gesdil_sv04 
> > > > sans problème.
> > > > 
> > > > Pas de problème signalé non plus sur "pg_restore -l"  
> > > > Par contre, pg_restore -s ne crée que 100 tables sur 102,
> > > > sans les commentaires ce qui rend difficile le diff,
> > > > Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
> > > > table des articles est la principale (855 563 éléments) et c'est la
> > > > principale.
> > > > 
> > > > Les autres tables créées sont vides, évidemment ...
> > > > 
> > > > 
> > > > J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
> > > > mais avec "-v", il risquait d'y en avoir pour un certain temps ...
> > > > J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)
> > > > 
> > > > J'aurai le résultat dans une ou deux heures, ou demain, ...
> > > > S'il manque une ou des tables, je pense arriver à les récupérer.
> > > > 
> > > > Merci pour votre aide, ainsi qu'à Guillaume Lelarge
> > > > -- 
> > > > Alain <eurlix(dot)alain(at)free(dot)fr>
> > > > 
> > > > -- 
> > > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > > To make changes to your subscription:
> > > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > > > 
> > > Bonsoir,
> > > 
> > > J'ai crié victoire un peu trop tôt :
> > > pg_restore a planté silencieusement et la BD gesdil est vide.
> > > (Même les tables crées par "pg_restore -s " ont disparu.
> > > 
> > > J'en reviens à l'idée de restaurer les tables une par une (il n'y en a
> > > qu'une centaine et je dois pouvoir faire un script pour ça).
> > > 
> > > Avez-vous une autre idée ?
> > > 
> > 
> > Comme déjà dit, sans plus de rigueur, on n'y arrivera pas. Votre
> > pg_restore plante sur quoi ? le lancez-vous sur une base vide ? avec
> > quelles options ?
> > 
> 
> Autre chose, si pg_restore ne dit rien, c'est qu'il a réussi ce que vous
> lui avez demandé de faire. C'est pourquoi les options que vous lui avez
> donné sont si importantes.
> 
> 
> -- 
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
> 
> 
Comme indiqué par Sébastien Lardière, j'ai à chaque fois fait
"dropdb gesdil" puis "createdb gesdil" 
Je l'ai lance comme ça :
$ pg_restore  gesdil_sv04 >restore.como 2>&1 &
[1] 18438
et j'ai obtenu ceci :
-rw-rw-r--  1 auberon auberon 228982784 avr  5 21:00 restore.como
Mais au final la BD gesdil était vide !
(Même plus les tables crées par pg_restore -s )
Ça parait aberrant, car il n'y avait pas de -v, mais j'ai considéré
qu'il avait conservé qqchose du lancement précédent, avec -v, que
j'avais breaké !

Je viens de réussir à remonter la sauvegarde d'aujourd'hui, gesdil_sv05
et il me reste à faire que les requêtes soient traitées sur cette
machine.
J'ai changé PGHOSTADDR, après avoir modifié pg_hba.conf, mais ça ne
semble pas suffisant.

-- 
Alain <eurlix(dot)alain(at)free(dot)fr>


In response to

Responses

pgsql-fr-generale by date

Next:From: Thomas ReissDate: 2012-04-05 20:27:17
Subject: Re: [pgsql-fr-generale] BD impossible à recharger
Previous:From: Guillaume LelargeDate: 2012-04-05 19:20:57
Subject: Re: BD impossible à recharger

pgsql-general by date

Next:From: Thomas ReissDate: 2012-04-05 20:27:17
Subject: Re: [pgsql-fr-generale] BD impossible à recharger
Previous:From: Guillaume LelargeDate: 2012-04-05 19:20:57
Subject: Re: BD impossible à recharger

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group