Hier soir, gros bug sur le site : plus moyen d’accéder aux pages du site ou de sauvegarder un article. Je lance un top, le serveur n’a pas l’air d’être surchargé du tout. Je relance Apache, Varnish et MySQL et là…

Stopping MySQL database server: mysqld failed!
/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! ... failed!

Ah cette erreur-là, je l’ai déjà eue ! Je fais un peu de ménage et je relance MySQL :

/etc/init.d/mysql restart 
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
ERROR 144 (HY000) at line 1: Table './skyminds/wp_posts' is marked as crashed and last (automatic?) repair failed

Et là, c’est le drame : le terminal est dans les choux comme attendant quelque chose et en lançant le site, il n’y a plus aucune information. Rien que le design, plus d’articles. Gloups.

Je jette un coup d’oeil sur le serveur, j’ai mes sauvegardes des derniers jours mais pas de tout ce que j’ai écrit aujourd’hui. Je tente un REPAIR mais phpmyadmin refuse catégoriquement :

SQL show index from `wp_posts` failed : Table './skyminds/wp_posts' is marked as crashed and last (automatic?) repair failed

La solution : lancer myisamchk

La solution que j’ai utilisé consiste à lancer la commande myisamchk, qui est une commande de bas niveau qui va vérifier et réparer notre table.

On commence par arrêter le serveur MySQL :

/etc/init.d/mysql stop

et on lance myisamchk avec ces paramètres sur notre base de données qui se trouve sous /var/lib/mysql/:

myisamchk -r -v -f --sort_buffer_size=128M --key_buffer_size=128M /var/lib/mysql/skyminds/wp_posts.MYI

Voilà ce que cela retourne :

- recovering (with sort) MyISAM-table '/var/lib/mysql/skyminds/wp_posts.MYI'
Data records: 0
- Fixing index 1
- Searching for keys, allocating buffer for 295411 keys
- Dumping 3420 keys
- Fixing index 2
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 3
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 4
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 5
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 6
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 7
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 8
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 9
- Searching for keys, allocating buffer for 3421 keys
- Dumping 3420 keys
- Fixing index 10
- Searching for keys, allocating buffer for 1177347 keys
- Dumping 275199 keys
- Fixing index 11
- Searching for keys, allocating buffer for 1177347 keys
- Dumping 275199 keys
- Fixing index 12
- Searching for keys, allocating buffer for 1177347 keys
- Dumping 275199 keys
Data records: 3420

On relance MySQL :

/etc/init.d/mysql start

et cette fois, tout se passe bien :

Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..

Tout est revenu mais je me dis que je devrais peut-être passer à 2 sauvegardes par jour…

A lire :  What is a browser ?

Pour développer votre projet WordPress ou Woocommerce, faites appel à mon expertise pour réaliser un site rapide, performant et fonctionnel.

Contactez-moi

Si vous avez trouvé une faute d’orthographe, informez-nous en sélectionnant le texte en question et en appuyant sur Ctrl + Entrée s’il vous plaît.

Articles en rapport:

MySQL : résoudre l’erreur “Table is marked as crashed and last (automatic?) repair failed”

par Matt Lecture: 3 min

Pin It on Pinterest

Share This

Spelling error report

The following text will be sent to our editors: