# Table WordPress corrompue après une coupure serveur : réparer sans tout perdre > Une coupure électrique brutale laisse une table wp_posts marquée comme corrompue au redémarrage. Diagnostic et réparation avec les outils MySQL natifs. - Auteur : Clément Hadrot - Publié le : 2021-12-13 - Mis à jour le : 2021-12-13 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/table-wordpress-corrompue-coupure-serveur-reparer/ ## L’essentiel - Une coupure brutale interrompt l'écriture en plein milieu d'une opération - REPAIR TABLE résout la majorité des cas sur des tables MyISAM - Un plan B s'impose si la réparation échoue silencieusement La coupure électrique n'avait duré que quelques secondes, le temps que l'onduleur du datacenter prenne le relais, mais quelques secondes suffisent parfois à interrompre une écriture disque en plein milieu de son exécution. Au redémarrage du serveur, le site affichait une erreur de connexion à la base de données, un symptôme qui prête d'abord à confusion : le service MySQL tournait bien, mais une requête sur la page d'accueil du site provoquait une erreur explicite, remontée dans les logs de WordPress. Le journal d'erreur MySQL confirmait rapidement la piste : `Table './exemple_db/wp_posts' is marked as crashed and should be repaired`. Ce symptôme classique après une coupure brutale touche typiquement les tables encore en moteur MyISAM, dont le mécanisme d'écriture est plus vulnérable à ce type d'interruption que celui d'InnoDB, doté d'un journal de transactions (redo log) permettant une récupération automatique après un arrêt non propre. ## Diagnostiquer l'étendue exacte des dégâts Avant de lancer une réparation à l'aveugle, il faut identifier précisément quelles tables sont concernées. Un outil natif de MySQL/MariaDB permet de vérifier l'intégrité de toutes les tables d'une base en une seule commande : ``` mysqlcheck -u root -p --check exemple_db ``` Cette commande liste chaque table avec son statut : `OK` pour les tables saines, et une mention explicite d'erreur pour celles qui nécessitent une intervention. Sur un site WordPress classique encore partiellement en MyISAM, ce sont généralement `wp_posts` ou `wp_options`, les tables les plus sollicitées en écriture, qui apparaissent en premier dans ce type d'incident. ## Réparer avec les outils natifs, dans le bon ordre > L'essentiel à retenir : Une coupure brutale interrompt l'écriture en plein milieu d'une opération ; REPAIR TABLE résout la majorité des cas sur des tables MyISAM ; Un plan B s'impose si la réparation échoue silencieusement La commande `REPAIR TABLE`, exécutée directement en SQL, résout la majorité des cas de corruption légère à modérée sur une table MyISAM : ``` REPAIR TABLE wp_posts; ``` Cette commande tente de reconstruire les index et de récupérer les lignes de données encore lisibles, en signalant celles qui sont irrécupérables. Le résultat retourné indique le statut de l'opération : `OK` confirme une réparation réussie, tandis qu'un message mentionnant des lignes perdues (`error` ou `warning` dans la colonne `Msg_type`) doit alerter sur une perte de données partielle à documenter avant de poursuivre. L'alternative en ligne de commande, plus pratique pour traiter plusieurs tables d'un coup, produit un résultat équivalent : ``` mysqlcheck -u root -p --auto-repair --check exemple_db ``` ## Quand la réparation échoue : le plan B Il arrive que `REPAIR TABLE` échoue à reconstruire correctement les index, en particulier si le fichier d'index (`.MYI`) a été plus sévèrement endommagé que le fichier de données (`.MYD`) lui-même. Dans ce cas, une réparation forcée peut être tentée directement au niveau du moteur, mais elle comporte un risque réel de perte de données supplémentaire : ``` REPAIR TABLE wp_posts USE_FRM; ``` Cette option reconstruit la table à partir de sa définition de structure (le fichier `.frm`), en reconstituant les index depuis zéro. Avant de tenter cette option, une sauvegarde des fichiers bruts de la table (`.MYD`, `.MYI`, `.frm`) doit impérativement être faite, service MySQL arrêté, pour conserver une chance de récupération manuelle plus poussée si cette tentative échoue également. - Sauvegarder les fichiers bruts de la table avant toute réparation forcée, MySQL arrêté pour éviter tout verrou actif sur les fichiers. - Si la réparation échoue complètement, la restauration depuis la dernière sauvegarde applicative reste le dernier recours fiable. - Comparer le contenu restauré avec ce qui subsistait avant la corruption permet d'évaluer précisément l'étendue de la perte de données, souvent limitée aux tout derniers articles ou commentaires enregistrés juste avant la coupure. ## Ce que cet incident révèle sur le choix du moteur Ce type d'incident touche presque exclusivement les tables encore en moteur MyISAM. Une base entièrement convertie en InnoDB bénéficie d'un journal de transactions qui permet, dans l'immense majorité des cas, une récupération automatique et transparente après un arrêt brutal, sans intervention manuelle ni `REPAIR TABLE` à exécuter. La vulnérabilité de MyISAM face à ce type de coupure est un argument de plus, au-delà des seules considérations de verrouillage, en faveur d'une conversion vers InnoDB sur tout site encore hérité de cette configuration ancienne. > Après chaque incident de ce type, la question à se poser n'est pas seulement « comment j'ai réparé », mais « pourquoi cette table était-elle encore en MyISAM au moment de l'incident ». La réparation soigne le symptôme, la conversion de moteur traite la cause. ## En résumé Une table WordPress marquée comme corrompue après une coupure serveur se répare, dans la grande majorité des cas, avec les outils MySQL natifs : `mysqlcheck` pour diagnostiquer, `REPAIR TABLE` pour corriger. La prévention de ce type d'incident, via un onduleur fiable ou une conversion préalable vers InnoDB, relève d'un chantier distinct, à traiter une fois l'urgence immédiate résolue.