Nothing2Hide

Réparation de corruption des tables sur MySQL

Il ya quelques jours, j'ai commencé à détecter un grand nombre d'erreurs sur php-stats sur l'impossibilité d'exécuter une série de requêtes provenant de différents tableaux.
Les messages reçus étaient de ce type:
# 1016 - Impossible d'ouvrir le fichier: 'nometabella.MYI' (errno: 130)
Au début je m'attendais a un problème dû à une saturation de l'espace disponible pour les db, donc je réaffectées un autre couple de bromure de méthyle, mais n'a pas remarqué des améliorations au bout de deux jours, j'ai commencé à m'inquiéter. Recherche sur Google pour le message d'erreur ci-dessus que j'ai trouvé sur un résultat significatif que signalé un problème similaire et a suggéré groped résoudre le problème en exécutant la commande SQL:

  REPAIR TABLE nometabella; 

Dans mon cas, j'ai réussi à sauver que l'un des trois tableaux, mais la corruption et à ce moment-là, j'ai demandé à un conseil (et des précisions sur la) Support technique TopHost qui répond à suggerendomi d'essayer la commande:

  REPAIR TABLE nometabella USE_FRM; 

Dans ce cas, la réparation a été couronnée de succès et php-stats semble avoir repris son travail correctement. Plus tard, cependant, je voulais essayer de comprendre un peu de "mieux un sens et les conséquences possibles de ces interventions que rétablir le respect et j'essaie de mettre sur le" 5,0 MySQL Manuel de référence "sous la rubrique« Syntaxe de REPAIR TABLE »est assez exhaustive .
Pour que je puisse comprendre que:

• La cause de la corruption des tables, ou plus précisément l'indice, est presque toujours due à une panne soudaine de la DB; besoin de comprendre quel est le pourcentage de responsabilité est supportée par le service d'hébergement…
• La commande REPAIR TABLE nometabella; simplement essayer de reconstruire l'index de fichiers;
• La commande REPAIR TABLE nometabella USE_FRM; devraient être utilisés là où le fichier d'index, il n'existe pas de plus ou si elle a la tête de la corruption. L'option USE_FRM il ya que le fichier. MYI être recréé à partir des fichiers. FRM, si cette mesure est plus radical et dangereux. Il en va de même de référence MySQL dit: "Utilisez ce mode uniquement si vous ne pouvez pas utiliser des modes régulières REPARATION. L'. MYI-tête de tableau contient d'importantes métadonnées (en particulier, la valeur actuelle et AUTO_INCREMENT Supprimer lien) qui sont perdus dans la réparation USE_FRM…. Ne pas utiliser USE_FRM si la table est compressé parce que cette information est également stockée dans le fichier. MYI file. "

Vous avez aimé cet article? Abonnez-vous dès maintenant flux RSS!