Vous n'êtes pas identifié(e).
Bonjour,
Désolé par avance du pavé, mais j'ai estimé que l'historique de mes recherches et actions seraient nécessaires à la résolution de mon problème.
Contexte:
Je suis un "grand débutant" sous postgreSQL (formation sur le tas, pas d'études d'informatique).
Nous utilisons un serveur debian 6.0.
Suite à une erreur dans un script de sauvegarde, j'ai rempli le disque du serveur hébergeant pSQL à 100%.
En me connectant au serveur via pgAdminIII je rencontrais une erreur du type (de mémoire, je n'ai pas noté l'intitulé exact):
accès impossible à la transaction #######
Accès impossible au fichier "pg_clog/XXXX"
Une fois le ménage réalisé (sans toucher aux fichiers de pSQL), j'ai redémarré et forcé un fsck ( = checkdisk pour les windowsiens), espérant supprimer les inodes pendants et résoudre le soucis.
Le fsck se déroule sans erreurs. Donc pas de souci de disque persistant.
Pour être sur j'ai lancé un test court smarmontools, passé avec brio.
J'en déduis que mon disque se porte bien et que l'erreur d'écriture des fichiers pg_clog/0FF# dépendait du remplissage du disque à 100%.
Après ces vérifications, je rencontrais toujours la même erreur.
En farfouillant un peu sur le net je suis tombé sur ce fil:
http://forums.postgresql.fr/viewtopic.php?id=359
J'ai alors créé les fichiers manquants grâce aux commandes suivantes:
dd bs=256K count=1 < /dev/zero >> /var/lib/pgsql/data/pg_clog/0FF1
dd bs=256K count=1 < /dev/zero >> /var/lib/pgsql/data/pg_clog/0FF5
dd bs=256K count=1 < /dev/zero >> /var/lib/pgsql/data/pg_clog/0FF7J'ai bien compris le message de gleu, en fin de discussion qui explique que cette solution de facilité. C'est un risque mesuré que j'ai souhaité prendre.
Je pensais mon problème réglé, mais j'ai eu besoin de réindexer la table pg_attritbute grâce à la commande:
REINDEX TABLE pg_attribute ;Je pensais le problème résolu, mais une nouvelle erreur est apparue, et c'est là que je sèche!
Point bloquant:
Je rencontre l'erreur suivante lors de l'ouverture d'une table via pgAdminIII:
"ERREUR: catalog is missing 2 attribute(s) for relid 2432122"
En cliquant sur valide, pgAdmin me liste l'intégralité des données de la table en question (saisie_observation).
J'ai 62031 données, lisibles, exploitables, etc.
Par contre le message d'erreur persiste.
En me connectant via psql je n'obtiens pas d'erreur. Ce qui me rend perplexe!
De plus, psql ne me renvoie pas le même résultat si j'utilise la commande
\dt saisie.* pour lister les tables de mon schéma, ou si j'utilise l'autocompletion.
Voici le résultat de l'autocomplétion:
SELECT count(*) FROM saisie.saisie_observation
saisie.saisie_observation saisie.saisie_observation_0 saisie.saisie_observation_1 saisie.saisie_observation_10 saisie.saisie_observation_11
saisie.saisie_observation_12 saisie.saisie_observation_13 saisie.saisie_observation_14 saisie.saisie_observation_15 saisie.saisie_observation_16
saisie.saisie_observation_18 saisie.saisie_observation_19 saisie.saisie_observation_2 saisie.saisie_observation_20 saisie.saisie_observation_23
saisie.saisie_observation_24 saisie.saisie_observation_25 saisie.saisie_observation_27 saisie.saisie_observation_3 saisie.saisie_observation_4
saisie.saisie_observation_40 saisie.saisie_observation_41 saisie.saisie_observation_42 saisie.saisie_observation_43 saisie.saisie_observation_44
saisie.saisie_observation_49 saisie.saisie_observation_5 saisie.saisie_observation_50 saisie.saisie_observation_52 saisie.saisie_observation_54
saisie.saisie_observation_57 saisie.saisie_observation_6 saisie.saisie_observation_61 saisie.saisie_observation_69 saisie.saisie_observation_7
saisie.saisie_observation_71 saisie.saisie_observation_72 saisie.saisie_observation_74 saisie.saisie_observation_77 saisie.saisie_observation_8
saisie.saisie_observation_83 saisie.saisie_observation_85 saisie.saisie_observation_87 saisie.saisie_observation_89 saisie.saisie_observation_9
saisie.saisie_observation_90 saisie.saisie_observation_91 saisie.saisie_observation_93 saisie.saisie_observation_95 saisie.saisie_observation_96
saisie.saisie_observation_id_obs_seq saisie.saisie_observation_59pgAdminIII ne vois pas l'intégralité des tables disponibles via l'autocomplétion de psql. Pourquoi?
Enfin si j'essaie de lancer à nouveau mon script de sauvegarde (pg_dumpall), j'ai les erreurs suivantes:
pg_dump: numérotation des colonnes invalide pour la table « saisie_observation_41 »
pg_dumpall : échec de pg_dump sur la base de données « eemyde », quitteJ'aimerais tirer tout ça au clair, supprimer cette erreur, comprendre son origine et pouvoir sauvegarder mes données comme avant!
Merci d'avance pour votre aide et vos idées, car tout ça est très flou pour moi.
PS: j'espère avoir posté au bon endroit, ce sont mes premiers pas sur ce forum.
Hors ligne
À première vue, je dirais qu'en créant des fichiers de clog à 0 (donc en forçant toutes les transactions comme commitées), vous avez maintenant un décalage entre la définition de vos table et la structure physique. Je trouve que c'est un coup de chance, car l'incohérence de vos données vous saute aux yeux immédiatement. Comme pour le thread précédant, la seule solution vraiment sûre est de restaurer une sauvegarde.
Au passage, avez-vous supprimé des fichiers de pg_clog durant le nettoyage, ou est-ce que le fsck en a supprimé ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonsoir,
J'avoue ne pas bien saisir la notion de décalage entre" la définition de la table et la structure physique", de quoi s'agit-il?
Pour ma culture générale, existe t-il un moyen de faire correspondre la définition de la table et la structure physique d'une table?
Concernant la suppression des fichiers, ce n'est ni le fsck ni moi qui les ai supprimé.
Ils étaient absents avant que je lance le fsck, d'où l'erreur qui m'a fait prendre conscience qu'il y avait soucis.
En écrivant ces lignes, je me rend compte qu'il est possible que le soucis soit antérieur à mon problème de disque plein mais que je ne me sois pas rendu compte du problème...
Le problème viendrait alors d'ailleurs.
Affaire à suivre.
Merci du retour, et je vais m'atteler à restaurer une sauvegarde.
Bonne soirée.
Hors ligne
La définition de la table et de ses colonnes dans le catalogue système diffère de la réalité des données sur disque. C'est donc plutôt mauvais signe.
Vous pouvez sinon regarder du côté de la sortie de dmesg ou des différents logs systèmes voir s'il n'y a pas eu un autre problème de détecté.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
L'épluchage des logs m'indique que le soucis est survenu le 21 janvier (log postgresl).
Il est passé inaperçu jusqu'alors!
Mes logs systèmes ne remontent pas à cette date, du coup je suis coincé, impossible de trouver la cause exacte...
Je m'attelle à la restauration de la BDD ce jour.
Merci beaucoup pour toutes ces informations.
Hors ligne