WordPress « la base de données nécessite une réparation » : ce que cela signifie et comment réparer en toute sécurité

Ce que WordPress veut réellement dire

WordPress affiche « la base de données nécessite une réparation » lorsqu’il estime qu’une ou plusieurs tables sont endommagées ou
incohérentes au point que les requêtes normales échouent. Le déclencheur immédiat est généralement une erreur renvoyée par MySQL/MariaDB
au démarrage ou lors d’une requête : une table marquée comme crashée, un index manquant, une page corrompue, une EOF inattendue, ou un
décalage entre ce que WordPress attend et ce qu’il peut lire.

Sous le capot, WordPress utilise un petit contrôle dans sa couche base de données et, s’il détecte certains échecs, il propose un flux de
réparation via un script intégré (wp-admin/maint/repair.php). Celui-ci peut exécuter des opérations SQL comme
REPAIR TABLE et OPTIMIZE TABLE — ce qui convient pour certains moteurs de stockage et est presque sans objet
pour d’autres.

Voici la vérité opérationnelle clé : WordPress peut détecter que la base de données est mal en point, mais il ne peut pas diagnostiquer si
vous avez une corruption logique (données incorrectes), une corruption physique (pages cassées sur le disque), ou des
problèmes d’accessibilité (timeouts, disque plein, boucles de récupération après crash). C’est à vous de déterminer laquelle de ces
situations vous avez en main.

Une bonne citation à garder en tête pendant les incidents : « L’espoir n’est pas une stratégie. » — Vince Lombardi. C’est direct, mais
pertinent.

Feuille de diagnostic rapide (premier/deuxième/troisième)

Quand le site est en panne, vous n’avez pas le temps d’admirer les ruines. Vous devez identifier rapidement le goulot d’étranglement : la
santé du moteur de base de données, des tables endommagées, ou le stockage en dessous.

Premier : confirmez que ce n’est pas juste un problème de connectivité ou d’identifiants

• Vérifiez les journaux du serveur web pour des échecs mysqli_real_connect, des erreurs d’authentification, des problèmes de
  résolution DNS, ou Too many connections.
• Confirmez que DB_NAME, DB_USER, DB_PASSWORD, DB_HOST dans wp-config.php
  correspondent à la réalité (et n’ont pas été modifiés sans prévenir WordPress).
• Essayez un simple ping DB depuis l’hôte WordPress. Si vous ne pouvez pas vous connecter, la « réparation » ne démarrera même pas.

Deuxième : consultez les journaux d’erreurs de la base pour la plainte réelle

• Recherchez des messages de récupération après crash, des avertissements de corruption InnoDB, « table is marked as crashed », « page checksum mismatch » ou « disk full ».
• Si InnoDB est en boucle de récupération après crash, ne redémarrez pas en rafale. Vous pouvez creuser la fosse encore plus profondément.

Troisième : établissez si le stockage sous-jacent vous ment

• Vérifiez l’espace disque et l’épuisement des inodes. Un « réparation nécessaire » est parfois « nous n’avons pas pu écrire la dernière transaction ».
• Consultez les journaux du noyau pour des erreurs d’E/S, des remontages de système de fichiers, une dégradation RAID, ou un volume cloud qui a eu un mauvais moment.
• Si la couche de stockage est instable, réparer des tables revient à repeindre une maison pendant qu’elle est en feu.

Faits intéressants et contexte (ce qui compte)

1. Historiquement, WordPress supportait fortement MyISAM ; les installations modernes utilisent typiquement InnoDB par défaut dans MySQL/MariaDB.
   Cela compte parce que « réparer » est un concept centré sur MyISAM.
2. Le script de réparation intégré à WordPress précède l’ère où les hébergeurs managés ont rendu l’accès à la BD « le problème de quelqu’un d’autre » — et il suppose que vous pouvez exécuter des opérations de réparation depuis la couche application.
3. InnoDB utilise un journal de redo et une récupération après crash ; après une perte de courant, il s’auto-répare souvent sans réparation au niveau table, si le disque est sain.
4. Les tables MyISAM peuvent être « marquées comme crashées » après un arrêt non propre parce que le moteur n’a pas de récupération transactionnelle comme InnoDB.
5. OPTIMIZE TABLE peut verrouiller les tables un temps substantiel selon le moteur et la version MySQL/MariaDB — une « réparation facile » peut devenir un multiplicateur de panne.
6. Un site WordPress peut sembler cassé à cause de la corruption d’une seule table : wp_options. Cette table est un point chaud pour les plugins
   et est souvent la première à montrer des symptômes.
7. Le message d’erreur est parfois trompeur : une requête échouant avec « incorrect string value » ou « illegal mix of collations » peut remonter
   de manière à ressembler à une « corruption », alors qu’il s’agit en réalité d’un décalage de charset/collation après une mise à jour ou une restauration.
8. Les avertissements de « corruption » InnoDB proviennent parfois du stockage sous-jacent renvoyant des données périmées ou erronées (cache défaillant,
   contrôleur, ou disque virtuel instable). Les bases de données sont excellentes pour détecter les mensonges, pas pour les corriger.

Causes courantes et modes de défaillance

1) Arrêts non propres et récupération après crash

Perte de courant, panic du noyau, tués par OOM, redémarrages forcés par une plateforme d’hébergement — les bases de données détestent les surprises. InnoDB est conçu pour récupérer,
mais la récupération nécessite des E/S disque fonctionnelles et suffisamment d’espace libre pour les journaux et le travail temporaire. MyISAM est plus fragile ; il peut marquer
des tables comme crashées et nécessiter des réparations explicites.

2) Disque plein (ou inodes plein) se faisant passer pour une « corruption »

Quand le système de fichiers atteint 100 %, les écritures échouent. InnoDB peut se retrouver coincé avec des opérations partiellement écrites ou incapable d’étendre son espace de tables.
WordPress voit alors des échecs de requêtes et propose une réparation.

3) Corruption réelle sur disque

C’est la vraie : secteurs défectueux, RAID cassé, stockage en bloc réseau mal configuré, ou un système de fichiers endommagé. InnoDB se plaindra de mismatch de checksum ou de « page corruption ».
À ce stade, la « réparation » depuis WordPress est surtout de la mise en scène. Il vous faut des sauvegardes, des tactiques de récupération, et parfois une extraction contrôlée.

4) Comportement de plugins et lignes trop volumineuses

Certains plugins traitent la base comme un tiroir à bazar : énormes blobs sérialisés dans wp_options, transients infinis, ou tables de logs qui gonflent jusqu’à ce que les requêtes expirent.
Vous pouvez voir des erreurs qui ressemblent à une base cassée, alors qu’elle est simplement noyée.

5) Opérations « d’optimisation » qui tournent mal

OPTIMIZE TABLE, modifications de schéma et suppressions massives peuvent déclencher de l’I/O massive, une utilisation temporaire du disque élevée et des verrous longs.
Dans des environnements partagés, vous pouvez affamer la base suffisamment pour que WordPress se casse et réclame une réparation.

Blague #1 : « Database needs repair » est la façon de WordPress de dire : « Je vais bien, mais la chose dont je dépends vit un moment formatif. »

Tâches pratiques : commandes, sortie attendue et décisions

Ci‑dessous des tâches pratiques que vous pouvez exécuter sur un hôte Linux typique avec MySQL/MariaDB et WordPress. Chaque tâche inclut des commandes, une sortie d’exemple,
ce que signifie la sortie, et la décision à prendre ensuite. Copiez/collez avec précaution ; les systèmes de production sont allergiques aux approximations.

Tâche 1 : Confirmer que WordPress peut résoudre et atteindre l’hôte DB

cr0x@server:~$ getent hosts db.internal
10.20.30.40    db.internal

Ce que ça signifie : La résolution de nom fonctionne et vous avez une IP.

Décision : Si cela échoue, corrigez DNS/hosts/routage VPC avant d’utiliser les outils de réparation WordPress.

Tâche 2 : Connectivité TCP basique vers le port DB

cr0x@server:~$ nc -vz db.internal 3306
Connection to db.internal 3306 port [tcp/mysql] succeeded!

Ce que ça signifie : Le chemin réseau et les groupes de sécurité/firewall autorisent les connexions DB.

Décision : Si c’est bloqué, arrêtez. Les réparations de tables n’aideront pas un port fermé.

Tâche 3 : Valider les identifiants DB depuis wp-config.php

cr0x@server:~$ php -r 'require "wp-config.php"; echo DB_HOST, " ", DB_NAME, " ", DB_USER, PHP_EOL;'
db.internal wordpressdb wpuser

Ce que ça signifie : Vous avez extrait les cibles de connexion configurées.

Décision : Si ces valeurs ne correspondent pas aux valeurs attendues (rotation récente des secrets, migration DB), corrigez la config d’abord.

Tâche 4 : Tenter une connexion MySQL simple et une requête

cr0x@server:~$ mysql -h db.internal -u wpuser -p -e "SELECT 1;"
Enter password: 
1
1

Ce que ça signifie : L’authentification fonctionne et le serveur répond.

Décision : Si vous obtenez « Access denied », la réparation est hors sujet — corrigez identifiants/privileges.

Tâche 5 : Vérifier l’espace disque et les inodes libres sur l’hôte DB

cr0x@server:~$ df -h /var/lib/mysql
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  200G  198G  2.0G  99% /var/lib/mysql

Ce que ça signifie : Vous êtes à un fichier temporaire d’un mauvais moment.

Décision : Libérez de l’espace d’abord (logs, anciennes sauvegardes, binlogs) avant toute opération de réparation/optimisation.

cr0x@server:~$ df -i /var/lib/mysql
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/nvme0n1p3  13M     13M     2K   100% /var/lib/mysql

Ce que ça signifie : L’épuisement d’inodes peut casser les écritures même si l’espace « disque » semble correct.

Décision : Nettoyez les fichiers petits en excès (tmp, logs). Si la DB ne peut pas créer de fichiers, les réparations peuvent échouer en cours d’exécution.

Tâche 6 : Lire les journaux MySQL/MariaDB pour la panne réelle

cr0x@server:~$ sudo tail -n 60 /var/log/mysql/error.log
2025-12-27T07:10:12.002345Z 0 [Warning] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=123, page number=456]
2025-12-27T07:10:12.002400Z 0 [ERROR] InnoDB: Page checksum mismatch on read.
2025-12-27T07:10:12.002430Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption

Ce que ça signifie : Ce n’est pas « exécutez REPAIR TABLE ». C’est du ressort de l’intégrité du stockage.

Décision : Arrêtez d’écrire. Prenez un snapshot/sauvegarde. Planifiez une récupération/extraction à partir des sauvegardes ou un sauvetage contrôlé.

Tâche 7 : Vérifier les tables MyISAM marquées comme crashées

cr0x@server:~$ mysql -h db.internal -u root -p -e "SELECT TABLE_SCHEMA,TABLE_NAME,ENGINE,TABLE_ROWS,CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_SCHEMA='wordpressdb' AND ENGINE='MyISAM';"
Enter password:
+-------------+-------------------+--------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME        | ENGINE | TABLE_ROWS | CREATE_OPTIONS |
+-------------+-------------------+--------+------------+----------------+
| wordpressdb  | wp_search_cache   | MyISAM |      12034 |                |
+-------------+-------------------+--------+------------+----------------+

Ce que ça signifie : Vous avez au moins une table MyISAM. Celles-ci peuvent légitimement nécessiter REPAIR TABLE.

Décision : Identifiez si le message d’erreur référence spécifiquement ces tables. Si oui, réparez-les — après avoir sauvegardé.

Tâche 8 : Exécuter une vérification de table pour localiser la corruption (rapide, faible risque)

cr0x@server:~$ mysqlcheck -h db.internal -u root -p --databases wordpressdb
Enter password:
wordpressdb.wp_posts                                 OK
wordpressdb.wp_options                               OK
wordpressdb.wp_search_cache                          error    : Table is marked as crashed and should be repaired
wordpressdb.wp_search_cache                          status   : Operation failed

Ce que ça signifie : Une table est explicitement marquée comme crashée.

Décision : Réparez uniquement la ou les tables affectées. Ne « optimisez tout » pas par ennui.

Tâche 9 : Sauvegarder avant réparation (dump logique)

cr0x@server:~$ mysqldump -h db.internal -u root -p --single-transaction --routines --triggers wordpressdb | gzip -1 > /tmp/wordpressdb.sql.gz
Enter password:

Ce que ça signifie : Vous avez pris une sauvegarde logique cohérente (au mieux ; peut échouer si des tables sont illisibles).

Décision : Si le dump échoue sur une table spécifique, notez-la. Envisagez d’exporter table par table pour sauver ce que vous pouvez.

Tâche 10 : Réparer une table MyISAM directement (ciblé)

cr0x@server:~$ mysql -h db.internal -u root -p -e "REPAIR TABLE wordpressdb.wp_search_cache;"
Enter password:
+------------------------------+--------+----------+----------+
| Table                        | Op     | Msg_type | Msg_text |
+------------------------------+--------+----------+----------+
| wordpressdb.wp_search_cache  | repair | status   | OK       |
+------------------------------+--------+----------+----------+

Ce que ça signifie : La réparation de la table a réussi.

Décision : Relancez mysqlcheck. Si c’est propre, remettez le site en ligne et surveillez les journaux pour une récidive.

Tâche 11 : Si WordPress est accessible, utilisez WP-CLI pour vérifier/réparer (plus sûr que l’exposition web)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp db check
Success: Database checked.
cr0x@server:~$ wp db repair
Success: Database repaired.

Ce que ça signifie : WP-CLI a exécuté avec succès les étapes de maintenance DB que connaît WordPress.

Décision : Si WP-CLI échoue avec des erreurs SQL, retournez aux journaux MySQL et aux vérifications ciblées. Ne recommencez pas aveuglément.

Tâche 12 : Inspecter la taille et la croissance de la table la plus lourde (souvent wp_options)

cr0x@server:~$ mysql -h db.internal -u root -p -e "SELECT table_name, ROUND((data_length+index_length)/1024/1024,1) AS mb FROM information_schema.TABLES WHERE table_schema='wordpressdb' ORDER BY (data_length+index_length) DESC LIMIT 10;"
Enter password:
+----------------+------+
| table_name     | mb   |
+----------------+------+
| wp_options     | 512.4|
| wp_posts       | 240.7|
| wp_postmeta    | 210.3|
| wp_actionscheduler_logs | 180.9|
+----------------+------+

Ce que ça signifie : Votre table options est énorme, ce qui corrèle souvent avec des requêtes lentes, des timeouts et des symptômes de « réparation ».

Décision : Investiguer les options autoload et le comportement des plugins. C’est une remédiation, pas une réparation.

Tâche 13 : Identifier le bloat autoload dans wp_options

cr0x@server:~$ mysql -h db.internal -u root -p wordpressdb -e "SELECT COUNT(*) AS autoloaded_rows, ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"
Enter password:
+----------------+-------------+
| autoloaded_rows| autoload_mb |
+----------------+-------------+
|          12456 |       88.40 |
+----------------+-------------+

Ce que ça signifie : WordPress charge les options autoloadées sur de nombreuses requêtes. 88 Mo n’est pas « acceptable ». C’est une auto-DDOS que vous hébergez.

Décision : Réduisez les options autoloadées (paramètres de plugins, transients) et ajoutez de la mise en cache. Ne lancez pas une « réparation » et appelez cela résolu.

Tâche 14 : Vérifier les requêtes longues ou attentes de verrou (les tentatives de réparation peuvent aggraver cela)

cr0x@server:~$ mysql -h db.internal -u root -p -e "SHOW FULL PROCESSLIST\G"
Enter password:
*************************** 1. row ***************************
     Id: 8123
   User: wpuser
   Host: 10.20.40.55:52111
     db: wordpressdb
Command: Query
   Time: 128
  State: Waiting for table metadata lock
   Info: OPTIMIZE TABLE wp_postmeta

Ce que ça signifie : Quelqu’un optimise et bloque les autres. Cela peut faire paraître WordPress « cassé ».

Décision : Arrêtez/tuez l’opération bloquante si approprié, puis planifiez la maintenance pendant une fenêtre avec un vrai plan.

Tâche 15 : Vérifier rapidement la santé du moteur InnoDB

cr0x@server:~$ mysql -h db.internal -u root -p -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,120p'
Enter password:
------------
TRANSACTIONS
------------
Trx id counter 987654321
Purge done for trx's n:o < 987650000 undo n:o < 0 state: running but idle
History list length 12

Ce que ça signifie : InnoDB tourne et n’est pas manifestement coincé avec une liste d’historique massive ou un rollback actif.

Décision : Si le status montre récupération après crash, corruption répétée ou « waiting for » I/O, concentrez-vous sur le stockage et les options de récupération.

Tâche 16 : Signaux d’erreur basiques du stockage (ne sautez pas ceci)

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Sat Dec 27 07:08:10 2025] blk_update_request: I/O error, dev nvme0n1, sector 123456789
[Sat Dec 27 07:08:10 2025] EXT4-fs error (device nvme0n1p3): ext4_find_entry:1463: inode #262144: comm mysqld: reading directory lblock 0

Ce que ça signifie : Votre base lit des données corrompues parce que le disque échoue ou le système de fichiers est endommagé.

Décision : Arrêtez les écritures, faites un snapshot si possible, migrez vers un stockage sain et restaurez depuis des sauvegardes. « Réparer les tables » n’est pas la solution.

Utiliser WP_ALLOW_REPAIR en toute sécurité (et ne pas en faire un open bar)

WordPress inclut un endpoint de réparation intégré à wp-admin/maint/repair.php. Il est désactivé par défaut et peut être activé
en ajoutant define('WP_ALLOW_REPAIR', true); dans wp-config.php.

Le bon côté : c’est simple et peut réparer certains problèmes de table, principalement autour de MyISAM. Le mauvais côté : c’est une page
de maintenance accessible via HTTP, et WordPress avertit explicitement qu’elle ne nécessite pas de connexion lorsqu’elle est activée. Cela signifie que si vous la laissez activée,
vous invitez des inconnus à utiliser vos fonctions de maintenance de base de données. Ils ne voleront peut‑être pas de données, mais ils peuvent créer de la charge et verrouiller les tables.

Modèle d’utilisation sûr

• Privilégiez WP-CLI (wp db check / wp db repair) si vous avez un accès shell.
• Si vous devez utiliser la page web de réparation, activez WP_ALLOW_REPAIR brièvement, exécutez la réparation, puis retirez-le immédiatement.
• Restreignez l’accès au niveau du serveur web (allowlist d’IP) pendant qu’il est activé.

Exemple : activer temporairement la réparation

cr0x@server:~$ sudo sed -i "s/^.*WP_ALLOW_REPAIR.*$/define('WP_ALLOW_REPAIR', true);/g" /var/www/html/wp-config.php

Ce que ça signifie : Vous avez activé le mode réparation (cela suppose qu’une ligne existait déjà ; soyez prudent avec les éditions automatiques).

Décision : Ajoutez immédiatement une restriction d’IP ou mettez le site derrière une page de maintenance pendant que vous exécutez la réparation.

Exemple : verrouiller l’endpoint de réparation sur votre IP (Nginx)

cr0x@server:~$ sudo nginx -T | sed -n '1,80p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Ce que ça signifie : La syntaxe de configuration est valide avant de recharger.

Décision : Ajoutez un bloc location pour /wp-admin/maint/repair.php et restreignez-le, puis rechargez Nginx.

Blague #2 : Laisser WP_ALLOW_REPAIR activé, c’est comme laisser votre voiture tourner dehors devant le bureau — techniquement pratique, socialement ambitieux.

InnoDB vs MyISAM : réparations très différentes

MyISAM : REPAIR TABLE est réel

Si la table affectée est MyISAM, REPAIR TABLE peut reconstruire des index et corriger certains problèmes structurels. Il peut
encore échouer si le fichier de données est fortement endommagé, mais c’est une réponse légitime après avoir sauvegardé ce que vous pouvez.

La corruption MyISAM se manifeste généralement par « Table is marked as crashed » ou « Can’t open file ». Les réparations peuvent être rapides pour
les petites tables et brutales pour les grandes. De plus, MyISAM utilise des verrous au niveau table ; les réparations peuvent bloquer lectures/écritures.

InnoDB : « réparer » signifie souvent « récupérer »

Avec InnoDB, REPAIR TABLE ne fait pas ce que les gens pensent. InnoDB s’appuie sur la récupération après crash, les journaux redo et les checksums. Quand InnoDB
signale une corruption, votre meilleure « réparation » est généralement :

• Confirmer la santé du stockage (erreurs I/O, santé du système de fichiers, événements de volumes cloud).
• Restaurer depuis une sauvegarde/snapshot connu bon si disponible.
• Si vous devez sauver des données, utilisez une extraction contrôlée : dumpez ce qui se lit proprement, isolez les tables endommagées, et reconstruisez depuis le schéma + les données survivantes.

Ne confondez pas « optimiser » et « réparer »

De nombreux guides WordPress traitent OPTIMIZE TABLE comme un balai magique. En pratique, cela peut :
verrouiller les tables, les réécrire, nécessiter un espace temporaire énorme, et provoquer un pic d’I/O suffisant pour révéler des problèmes de stockage latents.
C’est une opération de maintenance, pas un médicament d’urgence.

Aspect stockage et hébergement (où la corruption commence souvent)

En tant que SRE, j’ai appris à considérer l’application comme le messager et le stockage comme la scène du crime. La corruption de base de données est fréquemment
la conséquence d’événements d’infrastructure que vous n’avez pas remarqués : un voisin bruyant saturant les IOPS, un reboot de nœud, un système de fichiers remonté en lecture seule,
ou un volume qui a brièvement renvoyé des erreurs puis fait comme si de rien n’était.

Recherchez ces schémas de stockage

• Disque plein : facile à confirmer, facile à corriger, étonnamment fréquent.
• Système de fichiers en lecture seule : pannes soudaines à travers la pile ; MySQL peut s’arrêter ou refuser les écritures.
• Erreurs I/O : les journaux du noyau les montrent ; les journaux DB indiquent des mismatch de checksum ; WordPress affiche « repair ».
• Pics de latence : peuvent se faire passer pour de la corruption quand les requêtes timeout ou que les clients se déconnectent en cours d’opération.

Vérifications pratiques de sanity stockage (Linux)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
NAME         SIZE TYPE MOUNTPOINT     FSTYPE
nvme0n1      500G disk
└─nvme0n1p3  200G part /var/lib/mysql ext4

Ce que ça signifie : Confirme quel périphérique supporte le datadir MySQL.

Décision : Si c’est un volume réseau ou un disque éphémère, adaptez vos attentes et votre posture de sauvegarde.

cr0x@server:~$ mount | grep /var/lib/mysql
/dev/nvme0n1p3 on /var/lib/mysql type ext4 (rw,relatime,errors=remount-ro)

Ce que ça signifie : Le système de fichiers se remontera en lecture seule sur erreurs (comportement par défaut courant).

Décision : Si vous le voyez remonté en lecture seule, vous ne réparez rien tant que vous n’avez pas corrigé le système de fichiers/disque.

Trois mini-récits d’entreprise issus du terrain

Incident n°1 : La panne causée par une mauvaise hypothèse

Une entreprise de taille moyenne faisait tourner WordPress pour un site marketing qui a soudainement affiché « la base de données nécessite une réparation ».
L’ingénieur d’astreinte a vu le message, s’est souvenu de l’endpoint de réparation WordPress, a activé WP_ALLOW_REPAIR, a cliqué sur « Repair and Optimize » et a attendu.

La base de données est devenue plus lente. Puis elle est devenue indisponible. Le site qui était partiellement dégradé est devenu totalement hors ligne,
et la supervision s’est mise à hurler sur des erreurs de connexion. L’ingénieur a supposé « ça répare, laissez-lui du temps ». Cette hypothèse s’est avérée coûteuse.

La cause racine n’était pas la corruption du tout. Le disque de la base était à 99 % plein. L’étape d’optimize a tenté de reconstruire quelques grandes tables,
a créé des fichiers temporaires et a rencontré ENOSPC en cours d’opération. MySQL a commencé à échouer davantage de requêtes, et WordPress — essayant d’être utile — n’a cessé de suggérer la même réparation.

La correction fut ennuyeuse : libérer de l’espace disque, redémarrer MySQL proprement, et relancer une vérification ciblée. Ils n’avaient pas besoin d’optimisation ; ils
avaient besoin d’une gestion de capacité. Le changement post-incident fut encore plus ennuyeux : une alerte à 85 % d’utilisation disque et un runbook disant « libérer l’espace avant les réparations ».
Pas glamour, mais cela a empêché la récidive.

Incident n°2 : Une optimisation qui s’est retournée contre eux

Une autre équipe avait une installation WordPress avec des années de churn de plugins. Quelqu’un a remarqué la croissance de la base et a décidé de « nettoyer » en exécutant des optimisations nocturnes sur toutes les tables.
Ça semblait responsable, comme passer la soie dentaire. Les premières nuits furent calmes.

Puis le trafic a augmenté et le site a commencé à lancer des erreurs intermittentes aux heures de pointe. Les éditeurs se plaignaient que l’enregistrement de brouillons se bloquait parfois.
Le serveur de base affichait une utilisation I/O élevée à des heures étranges, et la latence diurne empirait. Les gens ont blâmé la plateforme d’hébergement, ce que font souvent les gens quand les graphiques sont effrayants.

Le problème : le job d’optimisation réécrivait de grandes tables InnoDB chaque nuit, générant une I/O de fond lourde, chassant le buffer pool et tenant parfois des verrous métadonnées qui entraient en collision avec le trafic réel.
En d’autres termes : la « maintenance » concurrençait la production, et la production a perdu.

Ils ont arrêté l’optimisation nocturne, puis fait un travail ciblé : supprimé un plugin qui stockait de grands blobs autoloadés, nettoyé les transients et ajouté un cache d’objets approprié.
La base a naturellement diminué avec le temps parce qu’ils ont cessé de l’alimenter en déchets. L’optimisation n’a pas résolu le comportement sous-jacent ; elle ne faisait que faire transpirer le système.

Incident n°3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une grande entreprise exploitait plusieurs propriétés WordPress. Rien d’extraordinaire — jusqu’à ce qu’un patch d’infrastructure provoque un reboot inattendu d’une VM DB pendant une poussée de contenu.
WordPress a commencé à afficher des invites de réparation, et quelques pages renvoyaient des erreurs.

L’équipe n’a pas touché à l’endpoint de réparation. Ils ont suivi leur runbook : geler les écritures (mode maintenance), snapshotter le volume, prendre un dump logique frais,
puis seulement lancer des vérifications. Ça a paru lent sur le moment. C’était le bon genre de lent.

Les vérifications ont montré une petite table MyISAM héritée marquée comme crashée (un reste d’un plugin ancien), et tout le reste était en ordre. Ils ont réparé cette table, validé le site et l’ont remis en ligne.
Le snapshot signifiait que si la réparation avait empiré la situation, ils auraient pu revenir instantanément.

Le héros discret fut la pratique que personne ne vante dans les comptes rendus d’incident : toujours prendre un point de reprise récupérable avant de « réparer » quoi que ce soit. Cela a transformé une situation risquée en une tâche de maintenance contrôlée,
et a empêché que l’incident ne devienne une saga de récupération.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « Database needs repair » apparaît juste après une migration

Cause racine : Import incomplet, tables manquantes, mauvais préfixe de table, ou décalage charset/collation provoquant des échecs de requêtes.

Correction : Vérifiez le préfixe de table dans wp-config.php, confirmez le nombre de tables et la présence des tables cœur, et vérifiez le charset/collation de la BD. Réimportez proprement depuis le dump.

2) Symptom : La réparation s’exécute, mais le message revient quelques heures plus tard

Cause racine : Problèmes de stockage sous-jacents récurrents, arrêts non propres répétés, ou une table MyISAM qui se corrompt à chaque crash.

Correction : Éliminez les arrêts non propres ; migrez les tables MyISAM héritées vers InnoDB si possible ; vérifiez les journaux kernel/disque et les événements d’hébergement.

3) Symptom : La page de réparation plante ou expire

Cause racine : Tables volumineuses, verrous métadonnées, ou DB saturée (I/O ou CPU). Parfois la limite d’exécution PHP l’interrompt en cours de route.

Correction : Privilégiez les outils en ligne de commande (mysqlcheck, WP-CLI). Réparez une table à la fois. Planifiez les opérations lourdes en dehors des pics.

4) Symptom : « Error establishing a database connection » plus confusion autour de la réparation

Cause racine : Limites de connexion, DB down, problèmes DNS/réseau, ou mauvais identifiants. Pas de corruption.

Correction : Corrigez la connectivité et les identifiants. Vérifiez max_connections et le comportement de pooling des connexions de l’application.

5) Symptom : MySQL redémarre en boucle après l’alerte de réparation

Cause racine : Récupération InnoDB échouant en raison de corruption, disque plein, ou erreurs système de fichiers.

Correction : Cessez le thrashing. Préservez l’état. Consultez les journaux d’erreurs et la santé disque. Restaurez depuis sauvegarde/snapshot ou effectuez un sauvetage contrôlé.

6) Symptom : L’administration charge, mais le front-end renvoie des 500 aléatoires et des notifications de « réparation »

Cause racine : Bloat autoload, tables plugins qui s’emballent, requêtes lentes qui timeout, ou contention de verrous.

Correction : Identifiez les plus grandes tables, examinez les options autoload, supprimez/ faites pivoter les tables de logs, ajoutez de la mise en cache et optimisez les index si approprié.

7) Symptom : Vous avez réparé une fois et maintenant c’est pire

Cause racine : Vous avez exécuté des opérations d’optimisation/réparation sur un disque défaillant ou sans espace libre, provoquant des réécritures partielles et aggravant les dégâts.

Correction : Restaurez depuis le snapshot/sauvegarde pré-réparation, stabilisez le stockage et la capacité, puis retentez des réparations ciblées avec un plan de rollback.

Listes de contrôle / plan étape par étape

Plan d’urgence (site dégradé ou down)

1. Stabiliser : mettez WordPress en mode maintenance ou réduisez les écritures (désactivez cron, mettez en pause les jobs lourds).
2. Confirmer la connectivité : vérifiez que l’hôte DB est joignable et que les identifiants sont valides.
3. Vérifier la capacité : confirmez l’espace disque et les inodes sur l’hôte DB ; libérez de l’espace si nécessaire.
4. Lire les journaux DB : identifiez s’il s’agit d’un crash MyISAM, d’une récupération InnoDB, ou d’erreurs I/O disque.
5. Prendre une copie récupérable : snapshot du volume si disponible ; puis tentez un mysqldump.
6. Localiser les tables défaillantes : exécutez mysqlcheck ou CHECK TABLE ciblés.
7. Réparer uniquement ce qui est cassé : utilisez REPAIR TABLE pour MyISAM ; évitez les opérations d’optimisation larges.
8. Valider : relancez les vérifications ; testez les pages clés ; surveillez les journaux d’erreurs.
9. Retirer l’exposition de réparation : si vous avez activé WP_ALLOW_REPAIR, retirez-le immédiatement.
10. Surveiller : observez l’I/O disque, le journal d’erreurs MySQL et les erreurs WordPress pendant 24–48 heures.

Plan de stabilité (après récupération)

1. Convertir les tables héritées : migrez les tables MyISAM vers InnoDB quand c’est possible.
2. Corriger l’hygiène des données des plugins : réduisez le bloat autoload, faites pivoter les tables de logs, supprimez les plugins abandonnés.
3. Implémenter des sauvegardes restaurables : à la fois snapshots et dumps logiques, testés régulièrement.
4. Ajouter des garde-fous : alertes d’espace disque, journalisation des requêtes lentes, et politique de fenêtre de maintenance pour les réécritures de tables.
5. Répéter la récupération : faites un exercice de restauration. Une fois. Vous dormirez mieux pour toujours.

FAQ

« Database needs repair » signifie-t-il toujours corruption ?

Non. Cela signifie que WordPress a rencontré des erreurs de base de données compatibles avec des tables endommagées ou des métadonnées incohérentes.
Disque plein, contention de verrous, arrêts non propres et problèmes d’identifiants peuvent tous imiter des symptômes « réparation nécessaire ».

Est-il sûr de cliquer sur « Repair Database » dans WordPress ?

Parfois. C’est relativement sûr pour des problèmes de tables MyISAM et des incohérences mineures. Ce n’est pas un substitut aux sauvegardes, et cela ne réparera pas
une corruption de stockage sous-jacente. Si possible, prenez d’abord un snapshot/dump.

Dois-je exécuter « Repair and Optimize » ?

En urgence, généralement non. Optimize peut être lourd, verrouillant et gourmand en disque. Réparez les tables cassées spécifiques d’abord ; optimisez plus tard
pendant une fenêtre, avec de l’espace libre et un plan de rollback.

Pourquoi cela revient-il après réparation ?

Les réparations répétées signalent en général des arrêts non propres récurrents, un disque en défaillance, ou une table MyISAM fragile toujours utilisée.
Une autre cause fréquente est un plugin générant des écritures abusives et écrasant le système sous charge.

WP-CLI peut-il résoudre cela sans activer WP_ALLOW_REPAIR ?

Oui. wp db check et wp db repair de WP-CLI appliquent la même idée mais via le CLI, ce qui est généralement plus sûr opérationnellement que d’exposer un endpoint web.

Que faire si la base ne démarre pas du tout ?

Alors WordPress ne peut rien réparer. Allez au niveau base de données : vérifiez l’espace disque, la santé du système de fichiers et les journaux d’erreurs MySQL.
Si InnoDB signale une corruption persistante, restaurez depuis sauvegardes/snapshots ou effectuez une extraction de données contrôlée.

Convertir les tables en InnoDB empêchera-t-il cela ?

Cela réduit une catégorie de problèmes (tables MyISAM marquées crash) parce qu’InnoDB dispose d’une récupération après crash. Cela ne vous protège pas contre la
corruption disque, le disque plein, les migrations erronées ou les plugins malveillants.

Puis-je réparer depuis phpMyAdmin ?

Vous pouvez, mais ce n’est pas mon premier choix. Les outils web sont pratiques et ont aussi tendance à expirer en cours d’opération. Pour les réparations et vérifications,
les outils CLI (mysqlcheck, mysql, WP-CLI) sont plus contrôlables et plus faciles à auditer.

Quelle est la sauvegarde la plus sûre à prendre avant réparation ?

Le meilleur est un snapshot de stockage du volume DB (rollback rapide) plus un dump logique (mysqldump --single-transaction) pour la portabilité.
Si la corruption est suspectée, attendez-vous à ce que les dumps échouent sur des tables spécifiques et à sauver ce que vous pouvez.

Dois-je désactiver le cron WordPress pendant les réparations ?

Si le site est instable, oui. Cron et les tâches en arrière-plan peuvent continuer d’écrire pendant que vous essayez de stabiliser, ce qui complique la récupération.
Coupez le bruit, réparez la base, puis réactivez le travail en arrière-plan.

Prochaines étapes à réellement entreprendre

Quand WordPress dit « la base de données nécessite une réparation », ne le traitez pas comme une invite d’interface. Traitez-le comme un signal que la couche de données renvoie
des erreurs et que votre travail est d’identifier quelle classe : connectivité, capacité, récupération moteur, ou véritable corruption.

Vos prochaines étapes pratiques :

1. Exécutez la feuille de diagnostic rapide : connectivité → journaux DB → santé du stockage.
2. Sauvegardez (snapshot + dump) avant toute tentative de réparation.
3. Utilisez mysqlcheck ou WP-CLI pour identifier les tables défaillantes spécifiques.
4. Réparez uniquement ce qui est cassé ; évitez « optimiser tout » pendant un incident.
5. Après récupération, corrigez la cause racine : espace disque, hygiène des données des plugins, modes d’arrêt non propres et sauvegardes testées.

Si vous faites cela correctement, le message « réparation » devient un court événement de maintenance, pas un hobby du week-end.