5.6.2.9 Comment réparer des tables

Dans la section présente, nous allons uniquement parler de l'utilitaire myisamchk sur les tables MyISAM (extensions .MYI et .MYD ). Si vous utilisez les tables ISAM (extensions .ISM et .ISD ), vous devriez vous servir de isamchk à la place.

Les symptômes de corruption de tables sont des requêtes qui s'interrompent inopinément :

• tbl_name.frm locked against change : tbl_name.frm est verrouillée en écriture
• Can't find file tbl_name.MYI (Errcode: ###) : Impossible de trouver le fichier tbl_name.MYI (Errcode: ###)
• Unexpected end of file : Fin de fichier inattendue
• Record file is crashed : Fichier de données crashé
• Got error ### from table handler : Reception de l'erreur ### de la part du gestionnaire de table

  Pour obtenir plus d'informations sur l'erreur, vous pouvez exécuter la commande perror ### . Voici les erreurs les plus courantes :

  shell> perror 126 127 132 134 135 136 141 144 145 126 = Index file is crashed / Wrong file format : le fichier d'index est corrompu / le format du fichier est incorrect. 127 = Record-file is crashed : le fichier de données est corrompu. 132 = Old database file / ce fichier provient d'une vieille base de données. 134 = Record was already deleted (or record file crashed) / La ligne était déjà effacée. 135 = No more room in record file / Plus de place dans le fichier de données. 136 = No more room in index file / Plus de place dans le fichier d'index. 141 = Duplicate unique key or constraint on write or update / Doublon pour une clé unique trouvé durant la lecture ou l'écriture. 144 = Table is crashed and last repair failed / la table est corrompue et la dernière réparation a échoué. 145 = Table was marked as crashed and should be repaired / La table a été marquée comme corrompue et doit être réparée.

  Notez que l'erreur 135, "no more room in record file", n'est pas une erreur qui sera facile à corriger. Dans ce cas, vous devez utiliser la commande suivante :

  ALTER TABLE table MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

Le processus de réparation se déroule en 4 étapes décrites ici. Avant de vous lancer, vous devriez vous placer dans le dossier de données et vérifier les permissions des fichiers de données. Assurez-vous qu'ils sont bien lisibles par l'utilisateur Unix que MySQL utilise (et à vous aussi, car vous aurez besoin d'accéder à ces fichiers durant la vérification. Si vous devez corriger ces fichiers, vous aurez aussi besoin des droits d'écriture.

La section du manuel sur l'entretien des tables inclut la présentation des options des utilitaires isamchk / myisamchk : Utilisation de myisamchk pour maintenir les tables et recouvrir les données .

Si vous allez réparer une table en ligne de commande, il est recommandé d'arrêter le serveur mysqld . Notez que lorsque vous exécutez une commande mysqladmin shutdown sur un serveur distant, le serveur mysqld sera encore opérationnel pendant un instant après que mysqladmin ait terminé, jusqu'à ce que toutes les requêtes et toutes les clés aient été écrites sur le disque.

Exécutez la commande myisamchk *.MYI ou myisamchk -e *.MYI si vous avez plus de temps. Utilisez -s (silencieux) pour supprimer les informations peu pertinentes.

Vous n'aurez à réparer que les tables pour lesquelles myisamchk vous annonce une erreur. Pour de telles tables, passez à l'étape 2.

Etape 2 : réparation simple et facile

Premièrement, essayez myisamchk -r -q tbl_name ( -r -q signifie ``mode de réparation rapide''). Cette commande va tenter de réparer le fichier d'index sans toucher au fichier de données. Si le fichier de données contient toutess les données qu'il est sensé contenir, et que les points d'ancrage pour les effacements sont corrects, cette commande doit réussir, et la table sera alors réparée. Passez alors à la table suivante. Sinon, suivez la procédure suivante :

• Faites une copie de sauvegarde de votre fichier de données.
• Utilisez la commande myisamchk -r tbl_name ( -r signifie ``mode de réparation''). Cette commande va supprimer les lignes invalides et effacer ces lignes du fichier de données, puis reconstruire le fichier d'index.
• Si l'instruction précédente a échoué, utilisez myisamchk --safe-recover tbl_name . Le mode restauration sécuritaire utilise une vieille méthode de réparation qui peut gérer certains cas rares, mais elle est bien plus lente.

Si vous obtenez des erreurs étranges lors de la répaaration (comme des erreurs de type out of memory ), ou si myisamchk crashe, passez à l'étape 3.

Nous ne devriez atteindre cette étape que si les 16 premiers ko du fichier d'index sont détruits, ou qu'il contient des données erronées, ou si le fichier d'index manque. Dans ce cas, il est nécessaire de créer un nouveau fichier d'index. Faites ceci :

• Déplacez le fichier de données dans une archive sûre.
• Utilisez le fichier description de la table pour créer de nouveaux fichiers de données et d'index vides.

  shell> mysql db_name mysql> SET AUTOCOMMIT=1; mysql> TRUNCATE TABLE table_name; mysql> quit

  Si votre version SQL ne dispose pas de TRUNCATE TABLE , utilisez la commande DELETE FROM table_name .
• Copiez l'ancien fichier de données à la place du nouveau fichier de données (ne faites pas un simple déplacement de fichier. Utilisez une copie, au cas où un problème surviendrait).

Depuis MySQL 4.0.2, vous pouvez aussi utiliser REPAIR ... USE_FRM qui effectue toute cette opération automatiquement.

Vous ne devriez atteindre cette étape que si votre fichier de description .frm a aussi crashé. Cela ne devrait jamais arriver, car le fichier de description n'est jamais modifié une fois que la table est créée.

• Restaurez le fichier de description avec une sauvegarde, et retournez à l'étape 3. Vous pouvez aussi restaurer le fichier d'index et retourner à l'étape 2. Dans ce dernier cas, vous pouvez démarrer avec l'option myisamchk -r .
• Si vous n'avez pas de sauvegarde, mais que vous savez exactement comment la table a été créée, vous pouvez créer une telle table dans une autre base. Supprimez alors le nouveau fichier de données, puis déplacez les fichiers de description .frm et d'index .MYI dans votre base de données crashée. Cela vous donnera un nouveau fichier d'index et de description, mais laisse intact le fichier de données .MYD . Retournez à l'étape 2 et essayez de reconstruire le fichier d'index.