Skip navigation links
5.7.3.10 Optimisation de table »
Section Navigation      [Toggle]

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

Depuis MySQL version 3.23.14, vous pouvez réparer les tables MyISAM avec la commande SQL REPAIR TABLE. See Section 13.5.2.6, « Syntaxe de REPAIR TABLE ».

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;

Dans d'autres cas, vous devrez réparer vos tables. myisamchk peut généralement détecter et corriger la plupart des erreurs.

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.

Si vous utilisez MySQL version 3.23.16 et plus récent, vous pouvez (et vous devriez) utiliser les commandes CHECK et REPAIR pour réparer vos tables MyISAM. Voyez Section 13.5.2.3, « Syntaxe de CHECK TABLE » et Section 13.5.2.6, « Syntaxe de REPAIR TABLE ».

La section du manuel sur l'entretien des tables inclut la présentation des options des utilitaires isamchk/myisamchk : Section 5.7.3, « Utilisation de myisamchk pour la maintenance des tables et leur recouvrement ».

La section suivante est destinée aux cas où les commandes ci-dessus ont échoué ou que vous voulez exploiter les fonctionnalités avancées que isamchk/myisamchk proposent.

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.

Etape 1 : Vérifier vos tables

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.

Si le serveur mysqld a terminé, vous devriez utiliser l'option --update pour indiquer à myisamchk d'enregistrer la vérification des tables ('checked').

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

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

Etape 2 : réparation simple et facile

Note : Si vous voulez réparer très rapidement, vous devriez ajouter -O sort_buffer=# -O key_buffer=# (où # vaut environ le quart de la mémoire du serveur), à toutes les commandes isamchk/myisamchk.

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 :

  1. Faites une copie de sauvegarde de votre fichier de données.

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

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

Etape 3 : Réparations difficiles

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 :

  1. Déplacez le fichier de données dans une archive sûre.

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

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

Retournez à l'étape 2. myisamchk -r -q doit alors fonctionner (et ceci ne doit pas être une boucle infinie).

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

Etape 4 : Réparation très difficiles

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.

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

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

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.