Re: Re: détecter les corruptions de données

Le Sunday 02 August 2009 21:20:04, William Dode a écrit :
> 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 !

C'est bien pour ça que j'ai dis que j'exagérais … désolé si c'était vexant, ça
n'était pas mon but.

>
> 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.

Il n'y a pas, de mémoire, de checksum de block ou d'enregistrement dans
postgresql. Une erreur de postgresql ou du disque deux fois au même endroit
est quand même assez improbable (surtout que si il y a eu update, il est
probablement physiquement dans un block différent)

Est-ce sur un (ou des) disques ou un contrôleur raid ? Dans le premier cas, il
pourrait être intéressant de faire une interrogation SMART.

>
> > 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...

Ça me semble le mieux en effet. Avec cela on en aura le cœur net.

Sinon on doit pouvoir 'émuler' un checksum avec une procédure stockée, un
trigger et pgcrypto. Mais ça risque de virer usine à gaz :)