Discussion :

[Poulou]

Bonjour,
J'ai assez régulièrement ce message sur ma base MySQL (ainsi que 'Can't open file: xxxx.MYD (errno: 145)', l'erreur 145 correspondant à 'Table was marked as crashed and should be repaired'). A quoi est-ce que ça peut être du ? Mauvaise spécifications des index ou MySQL qui s'embrouille ? Des solutions ?
Pour tout renseignements n'hésitez pas !...

[Invité]

tu devrais d'urgence utiliser myisamcheck, ton fichier d'index a l'air corrompu, mysql te le dit en plus (should be repaired).

[omiossec]

Pour la solution il faudrait utiliser l'utilitaire myisamchk pour reparer la table en question.
Arreter le serveur, faite une sauvegarde des fichiers de données.
executer myisamchk nom_de_la_table

[Poulou]

C pas un problème de solution, je sais bien ce qu'il faut faire !...
Ce qui m'intéresse c le pourquoi de ce message d'erreur ? Pourquoi arrive t-il à MySQL de corrompre le fichier d'index, assez régulièrement en plus ?

[Invité]

C pas un problème de solution, je sais bien ce qu'il faut faire !...

mais c'est agréable ça

quel est ta plateforme? tu as eu un arrêt brutal de ta base?

[Poulou]

Mes plus plates excuses, ça n'avait pas pour but d'être désagréable

Pour le problème, je suis sous Linux. Pas de pbs particulier mais dans le fichier de logs lors d'un INSERT qui plante j'ai le message : "Mysql error : Duplicate entry '5903252' for key". Je suis donc obligé de réparer la table mais un myisamcheck sur 1Go c long !

[Invité]

Tant que tu n'auras pas réparé, ça va persister voir même très probablement empirer.
Tu risque une bonne corruption généralisée, et un fichier bon à jeter.

[Poulou]

Je répare le fichier mais ça revient régulièrement d'où mon problème... Je ne sais pas à quoi cela peut être du...

[Invité]

Le réflexe habituel c'est de passer à la dernière version de mysql, tu tourne avec laquelle?

[Poulou]

3.23.40
Yop il va falloir que je passe à la 51 mais je suis pas convaincu que ça puisse résoudre le problème au vu du changelogs entre ces 2 versions.

[Invité]

Tu insère tes données comment?

[omiossec]

Ok j'avais mal lu le message.
Question sur le message d'erreur de tes log quel est le champs qui est en cause. Quel est son type d'indexation. Comment sont fait les index ?.

[Poulou]

C un code C qui appelle ma requête SQL, j'ai donc un truc dans le genre mysql_query (&sql,query) dans mon code avec query un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
INSERT INTO base (chmp1,...,chmp32) VALUES (valeur1,...,valeur32)

donc ça me semble correct de ce côté là.

Après au niveau des index, la table en contient énormément : 23 ! (c'est une application que je reprends donc c pas ma conception ! En fait à chaque fois qu'il y a une requête SELECT ils ont créé un index correspondant aux champs de la clause WHERE). Ils sont définis normalmeent par des KEY nomclé (nomchamp1,...,nomchamp3). Y'a t'il un autre moyen de "faire les index" comme dit omiossec ? Pour le message d'erreur "Mysql error : Duplicate entry '5903252' for key" je pense que c'est la clé primaire (un auto-incrément) qui est en cause.

Voilà, merci pour vos réponses et votre intérêt pour mon problème

[jmmolina]

Bonjour,

Désolé de faire remonter ce message mais je pense avoir un élément de réponse qui pourrait en aider certains, je le trouve bien aujourd'hui, peut-être qu'en 2010 quelqu'un nous lira .

Plus sérieusement le problème ne vient pas forcément de MySQL mais peut venir du disque. Sur 1 Go de données quelques secteurs physiques du disque peuvent être endommagés. Le myisamchk se charge uniquement de vérifier et réparer les tables, il ne peut rien vers quand il y a un problème physique. Le mieux est alors d'utiliser un outil de vérification du disque, chaque secteur du disque est alors passé au crible. Les grands fabricants proposent généralement un tel outil, à lancer sous DOS quand rien ne peut venir perturber la vérification. C'est d'après moi le meilleur moyen pour être sûr d'une chose : mon disque n'est pas endommagé, les secteurs endommagés sont marqués comme tel sur la FAT et ne peuvent donc en aucun cas être utilisés par une application. Si de tels secteurs ne sont pas marqués comme endommagés, n'importe quelle application, comme MySQL par exemple, peut inscrire des données dessus, ces dernières sont valables quelques heures, peut-être quelques jours, mais on les perd forcément à un moment ou à un autre.

Donc il y a 2 choses à vérifier :
- L'intégrité de la base avec myisamchk
- L'intégrité du disque avec l'outil du fabricant ou un outil professionnelle (mais je fais plus confiance aux outils des fabricants, gratuit et adapté pour la matériel à vérifier)

Je parle en connaissance de causes car il m'est arrivé de perdre des disques durs. Une mauvaise série IBM, mais comme toute la série était mauvaise forcément on avait peut de chance de bien tomber, souvenez-vous ^^. Un disque dur tellement brûlant qu'il aurait pu faire fondre les glaciers du pôle nord, quoique un bon boîtier, surtout bien ventilé, c'est une meilleure santé pour votre matériel, tout particulièrement vos disque durs. Je recommande un boîtier type Textorm avec 2 ventilateurs, donc 1 spécialement pour le rack des disques durs.

Rendez-vous en 2010 pour le prochain message,
JM