WordPress database error mysql server has gone away

Pour corriger WordPress database error mysql server has gone away, augmentez d’abord le délai et la taille de paquet acceptés par MySQL, puis identifiez la requête ou le processus qui coupe la connexion. Vérifiez les journaux PHP et MySQL, contrôlez la valeur de max_allowed_packet, le timeout wait_timeout et la mémoire disponible. Après chaque changement, relancez une sauvegarde ou une requête représentative et confirmez que WordPress répond en HTTP 200. Cette erreur signifie que la connexion avec la base de données a été interrompue avant la fin du traitement, pas que toutes les données sont nécessairement perdues.

L’erreur apparaît souvent pendant une importation, une sauvegarde, une mise à jour volumineuse ou une requête qui transporte un contenu trop grand. Elle peut aussi signaler un serveur MySQL redémarré, une saturation mémoire ou un hébergement qui ferme les connexions longues. Le bon diagnostic évite de modifier WordPress au hasard.

Ce que signifie exactement mysql server has gone away

MySQL renvoie ce message quand le client WordPress essaie d’utiliser une connexion que le serveur a fermée ou quand le serveur n’a pas reçu la suite attendue dans le délai prévu. Dans WordPress, le client est généralement PHP via mysqli ou PDO, et le serveur est MySQL ou MariaDB. La cause est donc située entre le code PHP, le réseau local de l’hébergement et le moteur SQL.

Deux scénarios dominent. Le premier est une requête ou un paquet supérieur à max_allowed_packet, fréquent avec un import SQL, une métadonnée volumineuse ou une sauvegarde. Le second est une connexion restée inactive trop longtemps, fermée par wait_timeout ou par un proxy. Un serveur à court de mémoire peut produire le même symptôme après un redémarrage brutal.

Ne confondez pas cette erreur avec « Error establishing a database connection ». La seconde concerne surtout les identifiants, l’hôte ou la disponibilité initiale. La première survient souvent après que WordPress a déjà établi la connexion. Cette distinction oriente immédiatement l’enquête vers les logs et les paramètres de session.

# Afficher les variables utiles avec un compte SQL autorisé
mysql -u wp_user -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"
mysql -u wp_user -p -e "SHOW VARIABLES LIKE 'wait_timeout';"
mysql -u wp_user -p -e "SHOW GLOBAL STATUS LIKE 'Aborted%';

Vérifier les logs avant de modifier la configuration

Commencez par noter l’heure exacte, l’URL ou la commande qui déclenche l’erreur, l’utilisateur concerné et la taille de l’opération. Une page blanche dans l’administration ne suffit pas comme diagnostic. Consultez le journal PHP, le journal MySQL et, si disponible, le journal du serveur web sur la même minute.

Dans WordPress, activez temporairement le journal de débogage sans afficher les erreurs aux visiteurs. Le fichier wp-content/debug.log peut révéler une extension qui lance une requête répétitive, mais il ne remplace pas le journal MySQL. Après le test, désactivez l’affichage et limitez l’accès au fichier de log.

Cherchez les messages Got an error reading communication packets, Lost connection to MySQL server during query, MySQL server has gone away et les redémarrages du service. Une erreur unique pendant un import n’a pas la même gravité qu’un serveur qui redémarre chaque heure.

# wp-config.php, à utiliser temporairement en environnement de diagnostic
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

# Après le test, remettre WP_DEBUG à false en production
# tail -f wp-content/debug.log

Corriger max_allowed_packet pour les gros contenus

max_allowed_packet limite la taille maximale d’un paquet transmis entre le client et MySQL. Une valeur trop basse peut interrompre un import, une restauration ou une requête contenant un article avec beaucoup de blocs. La valeur correcte dépend du volume réel, de la mémoire du serveur et des limites de votre hébergeur.

Sur un serveur maîtrisé, augmentez la valeur progressivement, par exemple à 64M ou 128M, puis redémarrez MySQL si la configuration l’exige. Le réglage doit être cohérent côté serveur et côté client. Sur un hébergement mutualisé, vous ne pourrez souvent pas modifier cette variable. Demandez alors la valeur disponible au support ou fractionnez l’import.

N’augmentez pas ce paramètre à plusieurs gigaoctets pour faire disparaître le message. Une valeur excessive augmente la mémoire potentiellement consommée par les connexions simultanées. Le correctif durable consiste à réduire la requête, importer par lots et corriger l’extension qui fabrique des paquets anormalement gros.

# my.cnf ou fichier de configuration MariaDB, selon l’hébergement
[mysqld]
max_allowed_packet=64M

# Contrôle après redémarrage
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"
# Import fractionné, plutôt qu’un fichier géant
mysql -u wp_user -p wp_database < lot-01.sql

Traiter les timeouts et les connexions longues

Si l’erreur apparaît après plusieurs minutes sans activité, inspectez wait_timeout, interactive_timeout et les timeouts du proxy. Une tâche PHP qui prépare un gros traitement avant d’envoyer sa requête peut laisser la connexion inactive. Les sauvegardes et les imports lancés depuis le navigateur sont particulièrement fragiles.

Préférez une tâche en ligne de commande ou un traitement asynchrone quand votre hébergeur le permet. Découpez les opérations en lots idempotents, c’est à dire relançables sans dupliquer les données. Un import par année, table ou tranche d’identifiants est plus facile à reprendre qu’une requête monolithique.

Côté WordPress, désactivez temporairement l’extension qui lance l’opération, puis reproduisez avec un export plus petit. Si l’erreur disparaît, comparez la requête produite et sa durée. Un timeout ne doit pas être traité en augmentant toutes les limites sans mesure, car cela peut masquer une boucle ou une requête sans index.

# Mesurer la durée de chaque lot depuis le shell
/usr/bin/time -f 'duree=%E mem=%MKB'   wp db import lot-01.sql --allow-root

# Vérifier les limites PHP utiles
php -i | grep -E 'memory_limit|max_execution_time|upload_max_filesize' 

Écarter la mémoire, le disque et le redémarrage MySQL

MySQL peut fermer des connexions parce que le serveur manque de mémoire ou d’espace disque. Contrôlez la mémoire disponible, le swap, l’espace de la partition qui contient les fichiers temporaires et les inodes. Une base saine ne compense pas un serveur qui tue le processus MariaDB sous pression.

Examinez le journal système pour repérer un message OOM killer, un crash InnoDB ou une restauration automatique. Si MySQL redémarre, le problème est prioritaire par rapport à la valeur de max_allowed_packet. Prenez une sauvegarde vérifiée avant toute réparation de tables, surtout sur une base de production.

Sur un mutualisé, transmettez au support l’heure, le message complet et l’URL concernée. Demandez les métriques de mémoire et les redémarrages, plutôt que de demander seulement une augmentation de limite. Le support peut confirmer une limite de compte invisible depuis WordPress.

df -h
free -m
# Linux, journaux récents du noyau et de MariaDB
journalctl -k --since '30 minutes ago' | grep -i -E 'oom|killed|out of memory'
journalctl -u mariadb --since '30 minutes ago' --no-pager

Réparer une table corrompue sans aggraver la situation

Une table corrompue peut provoquer des requêtes qui échouent ou consomment assez de ressources pour faire tomber la connexion. Vérifiez d’abord la présence d’une sauvegarde restaurable. Ensuite, utilisez un contrôle ciblé sur les tables signalées, sans lancer une réparation globale non documentée.

Les tables InnoDB ne se réparent pas comme les anciennes tables MyISAM. Une commande REPAIR TABLE inadaptée peut être inutile, voire dangereuse. Pour InnoDB, la priorité est le journal d’erreurs, la sauvegarde, l’intégrité du stockage et l’avis de l’hébergeur. Les outils WordPress ne doivent pas improviser une réparation sur une base active.

Après restauration ou correction, testez la connexion, la lecture d’un article, l’écriture d’un brouillon et une opération d’administration. Si l’erreur ne survient que dans une fonctionnalité, désactivez l’extension responsable et cherchez une version corrigée.

# Identifier le moteur et contrôler sans modifier
mysql -u wp_user -p -e "SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='wp_database';"
mysqlcheck -u wp_user -p --check wp_database
# Sauvegarder avant toute opération corrective
wp db export backup-avant-diagnostic.sql

Diagnostic côté WordPress, WP CLI et extensions

Le plus court chemin consiste à reproduire l’erreur avec WP CLI, hors navigateur. Une commande d’export, d’import ou de lecture permet de distinguer un problème HTTP d’un problème SQL. Si WP CLI échoue de la même manière, le thème et le navigateur deviennent moins suspects.

Désactivez les extensions non essentielles dans un environnement de maintenance, une par une si possible. Les extensions de statistiques, de recherche, de sauvegarde et d’import peuvent construire des requêtes très lourdes. Vérifiez aussi les tâches cron qui exécutent plusieurs opérations simultanément.

Si votre site affiche déjà une erreur 500, consultez notre guide sur le diagnostic complet d’une erreur 500 WordPress. Si le symptôme est une limite mémoire PHP, le guide fatal error allowed memory size exhausted détaille un autre chemin de résolution.

# Reproduire sans le navigateur
wp db check
wp db size --tables
wp cron event list --fields=hook,next_run_gmt,recurrence | head -30
# Tester la connexion WordPress
wp db query 'SELECT ID, post_title FROM wp_posts ORDER BY ID DESC LIMIT 3;' 

Plan de correction sécurisé et prévention

Appliquez les changements dans cet ordre : sauvegarde, collecte des logs, reproduction sur une petite opération, correction d’un seul paramètre, nouveau test, puis surveillance. Cette séquence permet de revenir en arrière et évite d’attribuer à MySQL une amélioration causée par un simple redémarrage.

Pour prévenir le problème, automatisez des sauvegardes testées, surveillez la taille de la base et les durées SQL, et gardez les extensions à jour. Limitez les tâches cron simultanées. Une sauvegarde jamais restaurée n’est pas une stratégie de reprise, c’est seulement un fichier qui existe.

Enfin, documentez les valeurs avant et après, la requête responsable et la réponse du serveur. Les réglages optimaux d’un petit blog ne sont pas ceux d’un catalogue WooCommerce. Le but est une connexion stable avec une charge prévisible, pas la plus grande limite possible. Pour un autre problème de communication REST, consultez aussi notre guide sur WordPress curl error 28 et curl error 7.

# Contrôle final HTTP et base
curl -I https://exemple.fr/
wp db check
wp db export backup-post-correction.sql
# Surveiller les erreurs pendant le test
 tail -f /var/log/mysql/error.log

FAQ sur WordPress database error mysql server has gone away

Que veut dire mysql server has gone away dans WordPress ?

Ce message signifie que WordPress a perdu la connexion avec MySQL pendant une requête ou qu’un paquet n’a pas pu être transmis. Les causes courantes sont un paquet trop gros, un timeout, un redémarrage de MySQL, un manque de mémoire ou une requête défaillante.

Comment corriger max_allowed_packet pour WordPress ?

Contrôlez sa valeur avec SHOW VARIABLES LIKE 'max_allowed_packet', puis augmentez-la progressivement si vous administrez le serveur. Sur un hébergement mutualisé, demandez la limite au support ou fractionnez l’import au lieu de forcer une valeur inaccessible.

Cette erreur signifie-t-elle que la base WordPress est perdue ?

Non. Elle indique d’abord une connexion interrompue. Vérifiez les journaux, l’état du serveur et l’intégrité des tables, puis restaurez une sauvegarde seulement si les données sont réellement endommagées ou si le serveur ne peut plus les lire.

Pourquoi l’erreur arrive-t-elle pendant une sauvegarde ?

Une sauvegarde peut lire une grande quantité de données et dépasser la taille de paquet, la mémoire ou le temps d’exécution autorisé. Utilisez des lots, une commande CLI et une destination disposant de suffisamment d’espace disque.

Que faire si je suis sur un hébergement mutualisé ?

Reproduisez l’erreur, notez l’heure et envoyez au support le message complet ainsi que la taille de l’opération. En parallèle, réduisez les lots, désactivez l’extension responsable et vérifiez les tâches cron concurrentes. Le support peut confirmer les limites MySQL invisibles à votre compte.

Sources utiles : documentation MySQL sur les connexions perdues, documentation MySQL sur max_allowed_packet, documentation WP CLI DB, documentation WordPress sur le débogage, variables serveur MariaDB, guide WordPress de dépannage.