Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous avons actuellement un problème avec application web utilisant une base de données PostgreSQL.
Depuis quelques jours maintenant, certaines lignes de certaines tables ne sont plus accessible.
L'application fonctionne toujours, mais seule quelques users n'arrive plus à accéder à leur page.
Après recherche, voici les erreurs qui nous sont retournées :
pg_dump: ERROR: could not access status of transaction 174194688
DETAIL: could not open file "pg_clog/00A6": No such file or directory
Connaissez-vous un moyen de récuperer la BD sans revenir en arrière depuis un dump ?
Y-a-t'il un risque de perte de données ?
Merci d'avance pour votre aide
Cordialement,
Emmanuel
Système : SLES 10 SP2
PostgreSQL : 8.1.9
Hors ligne
Le problème vient des fichiers indiquant si les transactions ont été COMMITées ou ROLLBACKées. Le problème est soit logicielle, au niveau du driver du disque, soit matérielle, directement au niveau du disque.
À mon sens, la meilleure solution dans ce cas est de restaurer une sauvegarde. Mais la première chose à faire est de comprendre pourquoi ce fichier n'existe plus. Avez-vous supprimé un fichier ? avez-vous eu un problème disque ? ou de système de fichiers ? un crash serveur ?
Bref, la première chose est de s'assurer du disque et du système de fichiers. La seconde chose à faire est de restaurer une sauvegarde.
Guillaume.
Hors ligne
Oh, de plus, 8.1.9 est une vieille version. Vous feriez mieux d'en profiter pour mettre à jour vers la 8.1.17, dernière version mineure de cette branche à ce jour.
Guillaume.
Hors ligne
Merci Gleu pour ta rapidité et ton aide.
En ce qui concerne nos serveurs ce sont des machines VMWare ESX haute performance. Je ne dis pas quels sont exempt de toutes défaillances, mais elle sont tellement surveillée que s'il y avait le moindre pb, on serait prévenu.
D'abord, tous les utilisateurs n'utilisent pas notre application tous les jours.
De plus, la panne n'empèche pas notre application de tourner, et nous nous en sommes donc apperçu que plusieurs jour après le début du problème, et donc certains users ont continués à travailler dessus (sauf les quelques personnes dont les lignes sont corrompues, qui nous ont prévenu)
Il nous est donc difficile de repartir d'un dump exécuté plusieurs jours auparavent.
Après quelques recherches sur le net, nous avons trouvé une solution qui consiste à créer les fichiers manquant (de la même taille que les autres) rempli de 0 (ou de 0x55) avec la commande :
dd bs=8k count=1 < /dev/zero >> /var/lib/pgsql/data/pg_clog/00A6Cela semble fonctionner, après avoir remplacer tous les fichiers manquant, nous avons réussi à récupéré la base.
Cependant un doute subsiste :
Est-ce que toutes les informations de la base sont correcte ?
Y-a-t'il un risque de perte ?
Nous avons aussi prévu de faire une mise à jour de version de postgres prochainement.
Merci
Hors ligne
Les informations de la base sont probablement incorrectes, sauf dans l'hypothèse que toutes les transactions aient toujours commité.
Le risque de perte est assez important. Et vous ne vous en rendrez compte que dans des mois, quand les utilisateurs constateront des incohérences.
Marc.
Hors ligne
Ce que je ne comprends pas, c'est pourquoi les logs des transactions sont nécessaires pour exporter les données ?
Les données de la bases ne sont-elles pas dans le dossier pgsql/data/base ?
Hors ligne
les logs des transactions sont nécessaires parce que postgresql fonctionne avec un modèle MVCC : chaque enregistrement peut exister en plusieurs versions dans les tables, et chaque version est marquée par une transaction de création et une transaction de destruction. Mais une transaction peut se terminer soit en commit soit en rollback. Dans les deux cas, la seule chose que PostgreSQL fasse, c'est marquer l'état final de cette transaction dans la clog.
Le problème est donc qu'à l'heure actuelle, dans votre base, il y a des enregistrements ayant des transactions de début/fin d'état inconnu à cause de la perte de cette clog. Et donc de gros doutes quant à leur visibilité.
Marc.
Hors ligne
Oui, en fait, avec votre commande, vous avez en quelque sort forcé le fait que toutes les transactions ont été commitées. Si certaines étaient rollbackées, vos données ne seront pas cohérentes. Bref, vous avez choisi la solution de facilité qui risque de vous revenir rapidement dans la figure.
Personnellement, je préfère perdre quelques jours, plutôt que quelques mois car si vous vous rendez compte dans un ou deux mois que les données ne sont pas cohérentes, vous aurez deux choix : 1. corriger à chaque erreur trouvée (ça risque de vous prendre énormément de temps pour un résultat hasardeux), 2. recharger la sauvegarde qui datera dans ce cas de deux/trois mois.
Bref, reprenez la sauvegarde, c'est comme je disais la meilleure solution.
Guillaume.
Hors ligne
Pages : 1