Corruptions de tables InnoDB

Salut,

Cet après-midi, une de nos machines OVH est tombée. Le support est intervenu et a changé la carte mère après avoir diagnostiqué une carte réseau HS (ça m'étonne mais admettons).

J'ai repris la main suite au reboot avec plein de problèmes : load average très haut, ssh quasiment inutilisable, etc. Le serveur est ensuite retombé. Impossible de reprendre la main et le support OVH avait déjà diagnostiqué que la machine était HS (je n'ai donc pas demandé un hard reboot pour éviter de court-circuiter le travail du tech). La main m'est rendue, la machine revient sans que le technicien n'arrive à diagnostiquer ce qui c'était produit, juste qu'un reboot avait suffit à relancer la machine.

Bref, entre temps, je vois que mySQL n'a pas démarré et qu'il refuse de le faire. Je vois dans le syslog que des tables InnoDB sont corrompues, ce qui empêche mySQL de démarrer.

Dans l'urgence et ne trouvant rien sur le net qui puisse m'aider (j'ai trouvé innodb_force_recovery dans la doc mais ça n'a rien changé), j'ai décidé de restaurer une sauvegarde de cette nuit, histoire de pouvoir relancer les sites au plus vite, même si la journée était perdue.

Avez-vous déjà eu ce genre de problème ? A priori ça viendrait du fait de l'arrêt brutal de la machine qui aurait corrompu les tables pendant l'écriture. Y a-t-il une solution dans ce cas pour reconstruire les tables sans tout perdre ?

Comment s'en prémunir ? Revenir sur du MyISAM à la place d'InnoDB ?

J'ai déjà eu le cas sur mon serveur mail.

InnoDB, je le déconseille de plus en plus à cause de ces conneries de corruption.
Ceci étant, quand j'ai eu le plantage, je n'ai pas réussit à faire repartir la base. Il faut donc faire un démarrage forcé en recovery de type 1 et il faut tenter de l'exporter. Si ça ne passe pas, il faut comprendre quel est le type de la corruption dans les logs et prendre le type de recovery correct.

Personnellement, j'ai jamais réussit à exporter la base, tu moins, pas complètement, j'ai eu une grosse partie supprimée, j'ai donc préféré repartir sur un backup.

Plus d'infos ici : http://dev.mysql.com/doc/refman/5.0/fr/forcing-rec...

C'est bizarre, on utilise intensivvement innoDB pour les fonctionnalites transactionnelles, et meme apres differents crash, le recovery a toujours fonctionne quant il s'est avere necessaire.

Par contre, mysql n'explique pas forcement qu'il est en train de reparer, le demarrage a l'air de ne pas fonctionner, mais en fait il repare la base grace au journal, mais aucun message ne le dit, il faut ouvrir les logs pour se rendre compte qu'il est en train de travailler. En general ca prend pas mal de temps, car il va "defaire" toutes les transactions qui ne se sont pas finie correctement pour retrouver un etat coherent de la base, ca peut prendre quelques heures. C'est pour ca aussi que le load peut etre tres eleve, car ca utilse intensivement le disque.

A mon avis, c'est pas moins stable, ni moins reparable que MyIsam, c'est juste que c'est pas ergonomique ni bavard du tout, ce qui fait que c'est difficile de bien comprendre ce qu'il se passe exactement.

C'est un Kimsufi 2XL donc pas de Raid. Après, c'est possible qu'il y ait eu un soucis de disque mais il n'y a pas eu de fsck après la coupure.

Toujours est-il que je flippe un peu et je ne sais pas trop comment me prémunir de ce genre de bordels à l'avenir... (ça m'était jamais arrivé et je ne savais pas trop quoi faire).