Le serveur MySQL est parti
WordPress avait une connexion de base de données de travail et l'a perdu en milieu de demande. La requête est rarement en faute ; la connexion est.
WordPress database error MySQL server has gone away for query …
Trois choses laissent tomber une connexion en direct : une requête plus grande que max_allowed_packet, une période de repos plus longue que wait_timeout, ou MySQL redémarrer. Vérifiez si le serveur a été mis en place plus longtemps que le site, car un temps de disponibilité faible répond immédiatement à la question et les deux autres n'ont pas besoin de test.
Les causes les plus probables d’abord.
Parcourez la liste dans l’ordre. Vérifiez chaque cause avant de modifier quoi que ce soit : les correctifs diffèrent et une supposition coûte plus cher qu’une commande.
| Cause | Comment vérifier | Correctif |
|---|---|---|
| Une requête plus grande que max_allowed_packet | L'échec suit une importation importante, un poste avec une très grande valeur méta sérielle, ou une restauration de sauvegarde — et il échoue à la même étape à chaque fois plutôt qu'au hasard. | Levez max_allowed_packet sur le serveur pour dépasser confortablement la plus grande instruction. Il s'agit d'un plafond côté serveur, donc un réglage côté client ne le déplace pas. |
| La connexion a ralenti wait_timeout | Les opérations d'administration longues échouent près de la fin alors que les charges de page ordinaires ne le font jamais. L'écart entre deux requêtes a dépassé le timeout et MySQL a fermé la socket. | Levez wait_timeout , ou cassez le travail en lots plus courts, donc aucune connexion unique ne reste au ralenti si longtemps. |
| MySQL a redémarré ou a été tué | Le temps de disponibilité du serveur est plus court que celui du site, ou le journal des erreurs enregistre un arrêt. Les morts hors mémoire sont la raison habituelle sur les petites machines. | Une base de données qui a été tuée une fois pour mémoire sera tuée sous la même charge. |
| La base de données refuse de nouveaux travaux | Erreurs sous charge et effacer lorsque le trafic tombe, et la liste des processus est proche de max_connections. | Réduire ce qui tient des connexions plutôt que d'augmenter la limite. Les requêtes à long terme occupant des créneaux sont la cause; un plafond plus élevé ne retarde que la même défaillance. |
Corriger l’erreur, étape par étape.
Les commandes supposent un accès à WP-CLI et au terminal. Si vous n’en disposez pas, chaque étape explique comment procéder depuis le tableau de bord ou via SFTP.
Demandez combien de temps le serveur a été lancé
Une mise à jour plus courte que la dernière fois que le site a fonctionné signifie que la base de données a redémarré, et rien d'autre sur cette liste n'a besoin de vérifier.
mysqladmin status mysql -e "SHOW GLOBAL STATUS LIKE 'Uptime';"
Lisez les deux limites qui comptent
La taille du paquet et le temps de repos représentent la plupart de ce qui reste une fois qu'un redémarrage est exclu.
mysql -e "SHOW VARIABLES WHERE Variable_name IN ('max_allowed_packet','wait_timeout','interactive_timeout');"Relever le plafond du paquet si une importation échoue
Définissez-le dans la configuration du serveur plutôt que dans la session, donc une restauration exécutée par n'importe quel outil hérite de celui-ci.
[mysqld] max_allowed_packet = 256M wait_timeout = 300
Vérifiez si elle a été tuée pour mémoire
Le log du noyau nomme le processus qu'il a choisi. C'est la cause la plus courante sur un petit serveur qui exécute MySQL à côté de PHP.
dmesg -T | grep -i -E 'out of memory|killed process' | tail -n 20
Réessayer l'opération en petits morceaux
Si le travail est une importation, le lotage maintient chaque déclaration bien sous le plafond et chaque connexion occupée.
wp db import dump.sql wp db check
Ce que la plateforme prend en charge.
La base de données fonctionne dans son propre conteneur avec une réserve mémoire qui lui appartient seule, de sorte qu'un processus PHP qui pointe ne peut pas faire tuer MySQL par le noyau — le mode de défaillance derrière la plupart de ces erreurs sur une seule machine partagée. Les valeurs de paquet et de timeout sont dimensionnées contre cette réserve plutôt que laissées à la distribution par défaut qu'une grande restauration dépasse immédiatement.
Questions fréquentes.
Mes données sont-elles endommagées ?
Pourquoi seulement pendant les importations et les sauvegardes?
Devrais-je simplement mettre wait_timeout très haut ?
En quoi est-ce différent de -error établissant une connexion à une base de données -?
Si le problème vient d’ailleurs.
Ces erreurs peuvent se présenter de façon similaire dans le navigateur.