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

Re: détecter les corruptions de données

From: William Dode <wilk(at)flibuste(dot)net>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: détecter les corruptions de données
Date: 2009-08-02 19:20:04
Message-ID: h54ot3$rpg$1@ger.gmane.org (view raw or flat)
Thread:
Lists: pgsql-fr-generale
On 02-08-2009, Marc Cousin wrote:

> Votre mail ne contient aucune information permettant d'avancer : pas de 
> message d'erreur, pas d'explication, rien de ce genre, juste quelque chose du 
> genre : 'postgres corrompt mes données quand il redémarre, vous n'auriez pas 
> une commande pour réparer ça automatiquement ?' (j'exagère volontairement).

Je veux bien ne pas avoir donné assez de détails, mais ce n'est pas la 
peine de me faire dire ce que je n'ai pas dit pour autant !

Quelques détails donc :

La base en question n'est accédée que par une seule appli (web), j'ai 
des dumps tous les jours, les logs apache des accès aussi bien en 
lecture qu'en écriture, je reçois automatiquement les erreurs de l'appli 
par mail. Aucune mise à jour de l'appli ou du système n'a été faite 
pendant cette période.

Le 31/7 à 2h j'ai un dump correct, je vois bien mon enregistrement sans 
problème d'encodage.
Le 31/7 à 9h29 je refait un dump pour travailler chez moi sur la base et 
constate un problème d'encodage sur un enregistrement. Je me dit que ça 
doit venir d'un client, je corrige (j'ai la trace dans le 
.psql_history).
Le 01/08 à 2h le dump montre à nouveau le problème d'encodage, sur le 
même enregistrement, même champ mais mot différent.

Mes logs apache montrent qu'il n'y a eu aucun accès en écriture sur cet 
enregistrement (il y a très peu d'écritures sur cette base).

La chaine est "Chine" et ensuite en hexa ça devient D0 7C 4D C0

Le reboot a eu lieu le 2, je me suis rendu compte à nouveau du problème 
d'encodage seulement aujourd'hui, j'avais donc pensé que c'était la 
cause. Avant la machine avait un uptime de 3 mois.

Ceci dit, je n'ai jamais dit que ça venait de postgresql, ça peut très 
bien venir d'un problème de disque.
Ma question était surtout de savoir s'il y a un moyen de vérifier 
l'intégrité des données à l'aide d'un checksum par enregistrement par 
ex.

>
> Le problème, c'est que je n'ai jamais vu ce comportement sous Postgres, malgré 
> des bases de plusieurs centaines de gigas. Je suis plus porté à croire à un 
> bug dans votre code ou une incompréhension d'un fonctionnement de Postgres. De 
> toutes façons pour le moment, votre mail ne contient aucune information qui 
> permette d'avancer

Pour info, ça fera bientôt une dizaine d'années que j'ai une 30aine de 
bases en production, c'est le deuxième problème de corruption de données 
que je rencontre, le premier c'était des indexes qui se corrompaient de 
manière chronique sur une 7.4, j'avais du transférer la base sur un 
autre cluster. Donc loin de moi l'idée d'accuser postgresql à la 
va-vite!

J'ai activé les logs statement pour avoir une confirmation de plus...


-- 
William Dodé - http://flibuste.net
Informaticien Indépendant


In response to

Responses

pgsql-fr-generale by date

Next:From: Marc CousinDate: 2009-08-02 19:50:13
Subject: Re: Re: détecter les corruptions de données
Previous:From: Marc CousinDate: 2009-08-02 13:20:50
Subject: Re: Re: détecter les corruptions de données

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