Que faire quand votre serveur crash, pour diverse raison (bug, power off, problème hardware) et qu’au redémarrage MSQL vous donne un message ?
WARNING: mysqlcheck has found corrupt tables
Le plus prudent est d’avoir un backup très récent !
Mais que faire si vous n’en avez pas de récent, ou même pas de backup du tout ?
Je me base les documentations suivantes :
- l’article Réparation Mysql en masse de Un blog qui nous veut du bien
- CHECK TABLE Syntax du site MySQL
- REPAIR TABLE Syntax du site MySQL
Le serveur tourne sous Debian, mais les commandes sont valables pour pratiquement tout distribution Linux ou autres (BSD, etc) et pour toute version récente de MySQL.
MySQL a le moyen de réparer (ou du moins d’essayer) les tables corrompues.
En général, cela fonction dans la majorité des cas… mais pas tous… ce qui justifie bien la nécessité d’un BACKUP régulier !
Il y a au moins 2 moyens de procéder.
- utiliser mysqlcheck pour tout réparer en bloc, mais cela nécessite un arrêt du service MySQL, ce qui perturbera les autres applications ou sites Web se trouvant sur votre serveur
- utiliser une commande “repair table” dans MySQL. Cela ne nécessite pas l’arrêt de MySQL et c’est relativement simple… si vous n’avez pas des dizaines de tables corrompues
Je vais utiliser la 2ème méthode : réparer table par table.
Connectez vous à MySQL.
Le user “root” est le userid root de MySQL. Ce n’est pas nécessairement “root”. Il peut être différent de votre “root” Linux !
$ mysql -u user_root_mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6258
Server version: 5.0.32-Debian_7etch11-log Debian etch distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
Vous êtes dans MySQL. Il attend vos commandes.
Il faut d’abord préciser sur quelle base de données vous voulez travailler, et ensuite les commandes pour contrôler et réparer la ou les tables corrompues.
Ma base de données s’appelle ‘”mabase” et les tables à l’intérieur de cette base s’appellent “culbutte_accesslog” et “culbutte_cache_menu”.
Utilisez évidemment les noms de votre DB et de vos tables corrompues 😉
mysql> USE mabase;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql>
Vérification des tables :
mysql> CHECK TABLE culbutte_accesslog;
+-----------------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------+-------+----------+----------+
| culbutte.culbutte_accesslog | check | status | OK |
+-----------------------------+-------+----------+----------+
1 row in set (0.13 sec)
La première table, bien que n’ayant pas été fermée correctement, n’est pas corrompue 😉
mysql> CHECK TABLE culbutte_cache_menu; +------------------------------+-------+----------+----------------------+ | Table | Op | Msg_type | Msg_text | +------------------------------+-------+----------+----------------------+ | culbutte.culbutte_cache_menu | check | error | Table './culbutte/ culbutte_cache_menu' is marked as crashed and should be repaired | +------------------------+-------+----------+----------------------------+ 1 row in set (0.00 sec)
Malheureusement, cette table est corrompue et doit être réparée !
Réparons la. La commande est très simple :
mysql> REPAIR TABLE culbutte_cache_menu;
+------------------------------+--------+----------+---------------------+
| Table | Op | Msg_type | Msg_text |
+------------------------------+--------+----------+---------------------+
| culbutte.culbutte_cache_menu | repair | info | Wrong bytesec:
0- 0- 0 at 4335740; Skipped |
| culbutte.culbutte_cache_menu | repair | status | OK |
+------------------------------+--------+----------+---------------------+
2 rows in set (0.11 sec)
Vérifions une dernière fois :
mysql> CHECK TABLE culbutte_cache_menu;
+------------------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+------------------------------+-------+----------+----------+
| culbutte.culbutte_cache_menu | check | status | OK |
+------------------------------+-------+----------+----------+
1 row in set (0.01 sec)
Allons sur le site (en Drupal, mais ça aurait pu arriver sur n’importe quel site ou application puisque le problème est un reboot du serveur).
Le message d’erreur n’avait pas disparu. J’ai du vider le cache (Flush all cache via le Admin-menu de Drupal) pour régénérer la page.
A ce moment là, le message d’erreur a disparu et le site tourne correctement 😉
Ouf …
