WordPress : corriger une écriture refusée par max_allowed_packet

Reconnaître un paquet SQL refusé pendant une écriture

Une sauvegarde de réglages, une régénération ou un traitement échoue avec « Got a packet bigger than max_allowed_packet ». Le moteur ou le client SQL a rencontré un paquet trop volumineux et peut fermer la connexion. Une instruction envoyée ou une ligne reçue peut être concernée ; le poids total de la base n’explique pas directement ce refus. Le seul message « MySQL server has gone away » ne suffit pas à attribuer une panne à ce plafond.

Le résultat recherché est une écriture complète dont le volume reste maîtrisé, puis une relecture correcte des données. La première approche réduit ce que le composant rassemble dans une seule opération. La seconde adapte la limite SQL lorsque le besoin est légitime et mesuré. Les deux décisions demandent d’identifier la requête qui échoue, pas seulement l’écran sur lequel l’erreur apparaît.

Ce guide vise une écriture effectuée par WordPress ou un composant. Un import SQL complet qui dépasse un délai ou une limite de fichier demande un autre parcours. Sur un hébergement géré, le réglage du moteur appartient au prestataire. En multisite, vérifiez quelle table et quel sous-site sont concernés avant d’intervenir sur une donnée ou un service partagé.

Suspendre les relances et préserver les données concernées

Arrêtez les relances répétées dès que le message est identifié. Un traitement de plusieurs éléments peut avoir réussi en partie avant le refus final. Notez les éléments terminés et ceux encore incertains depuis l’interface, sans supposer qu’une erreur 500 signifie une absence totale d’écriture. Conservez l’heure et le premier message SQL utile.

Préparez une sauvegarde adaptée de la donnée ou de la base et une copie de l’installation pour les essais. Si le composant propose un export de ses réglages, gardez-le séparément. Un export de contenu WordPress ne couvre pas nécessairement une option interne ou un état de traitement. Neutralisez les envois et les opérations commerciales de la copie.

Choisissez une écriture réversible et limitée sur la copie pour reproduire l’action fautive, avec un résultat attendu facile à relire. Une simple lecture de réglages ne reproduit pas nécessairement une erreur d’enregistrement. Gardez une sauvegarde de la valeur témoin. Ne supprimez pas une grosse ligne dans la table des options : son rôle et la possibilité de la reconstruire doivent d’abord être établis avec son propriétaire.

Séparer paquet SQL, mémoire PHP et taille du formulaire

max_allowed_packet concerne les communications entre un client SQL et le serveur, ainsi que certains traitements de grandes chaînes. Il ne correspond ni à la taille maximale d’un fichier téléversé ni au nombre de champs qu’un formulaire transmet à PHP. Une hausse de post_max_size, de la mémoire WordPress ou de max_input_vars ne relève pas automatiquement cette limite.

Le client et le serveur peuvent avoir leurs propres contraintes. Une valeur changée dans le programme de ligne de commande mysql ne modifie pas à elle seule le pilote utilisé par PHP. À l’inverse, une configuration serveur relevée peut laisser une autre limite sur le trajet applicatif. La documentation et le contexte exact du moteur sont nécessaires pour choisir le bon réglage.

Gardez le nom de l’instruction et de la table qui apparaissent dans le journal, en masquant les valeurs privées. Une option stockée dans un seul champ peut devenir très volumineuse ; une base entière beaucoup plus grande peut néanmoins fonctionner avec des requêtes plus petites. Ce qui compte est le volume de l’opération qui échoue, pas un quota global supposé d’articles ou de médias.

Relever la limite effective du serveur et de la session

Avec un accès SQL autorisé, ouvrez phpMyAdmin depuis le panneau de l’hébergement, sélectionnez la base à gauche puis SQL. La lecture ci-dessous affiche la version, la base courante et les limites globale et de session. Elle ne modifie rien. Conservez l’identité du point de connexion et l’heure, surtout si l’installation utilise un proxy ou plusieurs nœuds.

La session du gestionnaire SQL n’est pas nécessairement celle de WordPress. Une application déjà connectée ou un autre point de connexion peut encore utiliser un contexte différent. Demandez au responsable de rapprocher cette lecture de la connexion réellement utilisée par PHP. Un nombre affiché dans un panneau sans ce contexte ne valide pas la correction.

Sur WordPress.com, l’accès phpMyAdmin documenté est réservé aux offres Business et Commerce : Hosting Dashboard, site, Settings, Server, Database, Open phpMyAdmin. Cet accès ne confère pas l’administration du service SQL. Sur une offre mutualisée ou gérée, demandez la valeur appliquée à la connexion du site et les possibilités réelles de changement. L’option n’a pas de case universelle dans WordPress ; une extension ne peut pas se donner les droits du serveur.

1. Confirmez le serveur, la base et votre droit de lecture.
2. Exécutez la requête et conservez les valeurs en octets.
3. Notez leur éventuelle différence et le contexte de connexion de WordPress.
4. Si la lecture est refusée, conservez le refus pour le responsable sans élargir les droits du compte applicatif.

SELECT VERSION() AS version_serveur,
       DATABASE() AS base_courante,
       @@GLOBAL.max_allowed_packet AS limite_globale,
       @@SESSION.max_allowed_packet AS limite_session;

Mesurer une option déjà stockée sans afficher son contenu

Si le journal identifie précisément une option, mesurez sa valeur existante avec une lecture ciblée. Remplacez prefixe_options par le nom réel de la table et option_confirmee par le nom confirmé. Dans un multisite, les options d’un sous-site et les options réseau ne partagent pas nécessairement le même schéma : la requête ci-dessous vise uniquement une table d’options de site. Faites adapter la lecture si la donnée se trouve dans une table réseau ou propre à une extension.

OCTET_LENGTH mesure des octets, pas des caractères. La requête n’affiche pas le contenu privé de l’option. Cette taille stockée n’est pas celle du paquet envoyé : l’instruction SQL, son échappement et les autres valeurs ajoutent du volume ; la nouvelle donnée refusée peut aussi être plus grande. Le résultat sert à comprendre la croissance, sans dimensionner exactement le plafond à ce seul nombre.

Si aucune ligne n’apparaît, ne créez pas l’option pour tester. Vérifiez le nom et le propriétaire. Si la donnée est dans une table spécifique à une extension, adaptez l’observation avec son responsable. Ne lancez pas un classement de toutes les valeurs sensibles en affichant leur contenu complet pour gagner du temps.

SELECT option_name, OCTET_LENGTH(option_value) AS octets
FROM prefixe_options
WHERE option_name = 'option_confirmee';

Identifier le composant avec Query Monitor si la réponse reste disponible

Le journal PHP ou SQL existant reste la première piste sans nouvelle extension. Sur la copie, Query Monitor, gratuit et développé par John Blackbourn, peut relier une requête à son appelant quand la réponse reste inspectable. La fiche vérifiée indique la version 4.1.1, WordPress 6.3 et PHP 7.4 minimum, avec compatibilité déclarée jusqu’à WordPress 7.1.4. Ces minima ne sont pas une recommandation de conserver une ancienne version PHP.

Query Monitor affiche les requêtes du chargement courant, pas l’historique de toutes les requêtes du site. Après une redirection, le panneau de la page d’arrivée ne prouve pas ce qui s’est passé pendant l’enregistrement précédent. Une tâche de fond ou une réponse interrompue peut aussi échapper à ce parcours. Ne concluez pas à l’absence d’erreur si son panneau reste vide ; conservez le journal associé à l’action. Les valeurs SQL affichées peuvent être privées.

1. Sur la copie compatible, ouvrez Extensions > Ajouter une extension, cherchez Query Monitor et vérifiez John Blackbourn, puis Installer maintenant et Activer. En multisite, faites intervenir l’administrateur réseau si l’installation ou l’accès au diagnostic est réservé.
2. Reproduisez une seule fois l’écriture témoin autorisée ; ouvrez le menu chiffré de Query Monitor dans la barre d’administration si cette réponse le permet.
3. Consultez Database Queries puis Query Errors, visible lorsqu’une erreur SQL a été collectée. Relevez l’appelant et le composant sans diffuser les valeurs de la requête.
4. Rapprochez ces informations du journal et de l’heure exacte. Si l’erreur appartient à une autre requête ou reste invisible, revenez au journal et au développeur du composant.
5. Après le diagnostic, ouvrez Extensions > Extensions installées et désactivez Query Monitor au niveau où il a été activé.

Réduire un lot lorsque le composant le prévoit

La première approche convient si l’outil documente une taille de lot, une pagination de traitement ou un enregistrement par élément. Depuis son écran de réglages sur la copie, conservez la valeur initiale puis choisissez un lot réduit. Utilisez le mécanisme prévu ; fermer un panneau visuel ou sélectionner moins de lignes ne garantit pas que la requête SQL sera plus petite.

Reprenez le même témoin et vérifiez les données après réouverture. Si le petit lot fonctionne, comparez le journal et le volume traité avant de poursuivre. Gardez un relevé des éléments terminés pour éviter une reprise en double. Le résultat attendu est une série d’écritures bornées, chacune complète, et une couverture finale cohérente.

1. Relevez la taille de lot initiale et l’état du traitement.
2. Réduisez-la par l’option documentée du composant sur la copie.
3. Exécutez un seul lot témoin et relisez son résultat.
4. Vérifiez si l’opération continue malgré tout à réécrire une option cumulée de plus en plus grosse.
5. Si la réduction n’agit pas sur le paquet, restaurez le réglage et passez au propriétaire de la donnée ou au dimensionnement SQL.

Corriger une donnée qui grossit à chaque opération

Un lot réduit peut échouer après quelques passages si l’outil rassemble tous les résultats dans une même option. Dans ce cas, augmenter la limite ne maîtrise pas la croissance. Faites identifier le rôle de la donnée : historique, cache reconstructible, état de traitement ou information métier. Son nom et sa taille seuls ne permettent pas de décider qu’elle peut être supprimée.

Cherchez dans la documentation du composant une rétention, un nettoyage ciblé ou un correctif officiel. Sur la copie, exportez ou sauvegardez la donnée puis appliquez seulement ce mécanisme documenté. Contrôlez ce qui est conservé et ce qui doit être reconstruit. Un nettoyage qui efface l’état d’avancement peut nécessiter une reprise spécifique, sans répéter les actions déjà terminées.

Ne tronquez pas une valeur sérialisée au milieu et ne remplacez pas son contenu par une chaîne vide pour réduire les octets. Ne désactivez pas simplement son autoload en pensant réduire la prochaine écriture : ce réglage porte sur son chargement, pas nécessairement sur son volume d’enregistrement. Si la structure de stockage est en cause, le développeur doit corriger le mécanisme avant une reprise à grande échelle.

Adapter la limite SQL pour un besoin légitime et mesuré

La seconde approche appartient au responsable SQL autorisé. Elle convient à un besoin borné qui dépasse la limite effective. Sur MySQL 8.4, SET GLOBAL demande SYSTEM_VARIABLES_ADMIN, ou l’ancien privilège SUPER désormais déconseillé ; ce droit ne doit pas être ajouté au compte WordPress. Le changement porte sur le service SQL, potentiellement partagé par plusieurs installations, pas sur la seule base sélectionnée dans phpMyAdmin.

L’exemple ci-dessous fixe temporairement 64 Mio, soit 67 108 864 octets. C’est déjà la valeur par défaut documentée de MySQL 8.4 ; la documentation MariaDB indique 16 Mio côté serveur. Ce sont des repères, pas les valeurs garanties de votre offre. N’exécutez pas l’exemple si votre plafond est déjà égal ou supérieur. La valeur choisie doit répondre au besoin mesuré et aux ressources disponibles.

Dans la session SQL administrative du service identifié, conservez d’abord la valeur initiale, exécutez la modification autorisée, puis sa relecture. Le résultat de l’exemple doit être 67108864. Un refus de droits arrête ce parcours ; il ne justifie pas de modifier le compte applicatif. SET GLOBAL seul ne persiste pas après redémarrage. Pour une correction durable, le responsable emploie le paramétrage du service ou sa configuration ; MySQL et MariaDB n’offrent pas tous les mêmes mécanismes.

1. Comparez le besoin et les limites réellement atteintes, côté serveur et client.
2. Conservez la valeur initiale et la portée sur les autres consommateurs.
3. Appliquez une valeur proportionnée par la gestion autorisée du service.
4. Ouvrez de nouvelles connexions de test et relisez leur valeur avant l’essai WordPress.
5. Pour annuler, réutilisez SET GLOBAL avec le nombre initial relevé, pas DEFAULT qui pourrait être différent. Rétablissez aussi le réglage persistant si vous l’avez changé, puis vérifiez de nouvelles connexions.

SET GLOBAL max_allowed_packet = 67108864;
SELECT @@GLOBAL.max_allowed_packet AS nouvelle_limite;

Vérifier les nouvelles connexions et le client PHP

Une connexion déjà ouverte peut garder son ancien contexte après un changement global. Fermez puis rouvrez la session de test, et relancez la lecture globale et de session de la section « Relever la limite effective du serveur et de la session ». Faites ensuite vérifier la connexion réellement utilisée par PHP : rouvrir phpMyAdmin ne renouvelle pas celle de l’application. MySQL documente la valeur de session en lecture seule ; MariaDB la décrit également non modifiable dynamiquement. N’injectez donc pas SET SESSION dans WordPress.

Si le serveur annonce une limite suffisante mais que l’écriture échoue encore, examinez le client et le trajet. Un test réussi avec le programme mysql ne valide pas automatiquement le pilote PHP. Un proxy SQL, une connexion persistante ou un point de connexion différent peut demander son propre contrôle. Faites relever le contexte exact plutôt que de redémarrer tous les services au hasard.

Ne changez pas les délais de connexion, les journaux InnoDB et plusieurs plafonds mémoire en même temps simplement parce qu’un forum les propose. Chaque modification doit répondre à une preuve. Le résultat attendu est une connexion applicative qui utilise la limite prévue, sans modifier les droits d’accès aux données. Si cette preuve manque, gardez le cas réduit et faites poursuivre le diagnostic de connexion avant une nouvelle opération volumineuse.

Valider l’écriture puis le volume habituel

Sur la copie, reprenez le témoin qui échouait avec la même donnée et la configuration corrigée. Vérifiez le journal de cette heure et rouvrez l’écran pour relire la valeur réellement enregistrée. Une notification de réussite ne suffit pas si le traitement poursuit des écritures en arrière-plan. Contrôlez le point où l’opération précédente s’arrêtait.

Passez ensuite à un volume représentatif, avec les effets externes neutralisés et un suivi des éléments terminés. Vérifiez les données du début et de la fin, ainsi que celles qui ne devaient pas changer. Si la solution repose sur des lots, leur ensemble doit couvrir le besoin sans laisser une option cumulative grossir à nouveau jusqu’à la limite.

Observez aussi la charge et les erreurs de connexion. Une hausse de plafond ne garantit pas que le serveur possède les ressources adaptées à toutes les écritures simultanées. Conservez le dimensionnement validé et retirez les réglages de diagnostic inutiles. Une réparation du paquet est achevée lorsque les écritures attendues sont complètes et relisibles, pas seulement lorsque l’ancien message disparaît sur une petite opération.

Récupérer les résultats partiels avec le propriétaire des données

Si les essais précédents ont laissé des résultats incomplets, séparez leur récupération de la correction de limite. Relevez l’état actuel et les éléments déjà terminés. Certains composants savent reprendre une file ; d’autres reconstruisent leur historique ou réécrivent un ensemble entier. Utilisez leur mécanisme documenté au lieu de rejouer toutes les actions depuis le début.

Pour des valeurs importantes écrasées, préparez une récupération ciblée depuis la sauvegarde. Une restauration globale de la base pourrait supprimer des articles, comptes ou commandes plus récents. La simple remise de l’ancien plafond SQL n’annule pas les écritures effectuées avec la nouvelle valeur. Le retour de configuration et le retour de données doivent avoir chacun leur périmètre.

Si une opération de nettoyage a été essayée sur la copie, conservez son export et son résultat avant de la reproduire ailleurs. Ne transférez pas une table entière de préproduction vers la production sans connaître les identifiants, dépendances et changements survenus depuis. Le propriétaire du composant doit pouvoir expliquer ce qui sera conservé, reconstruit ou perdu lors de la reprise.

Garder une taille bornée plutôt qu’une hausse permanente sans mesure

Documentez la requête concernée, le composant propriétaire, la donnée mesurée et la limite utilisée par la connexion du site. Conservez la valeur initiale et la méthode persistante si un changement serveur a été décidé. Lorsqu’un composant ajoute un historique ou rassemble de nouveaux résultats, vérifiez à nouveau sa croissance sur la copie.

Une rétention adaptée ou une écriture en lots peut éviter de concentrer toujours plus d’informations dans un seul paquet. Ces changements appartiennent au mécanisme de stockage du composant ; ils ne doivent pas être improvisés en éditant directement ses valeurs sérialisées. Une donnée reconstructible doit être identifiée comme telle avant d’utiliser son nettoyage.

Pour demander un correctif, transmettez l’heure, le message SQL expurgé, la table, le nom de donnée confirmé et les volumes utiles. Ajoutez la différence entre petit lot et volume habituel, les valeurs de connexion et les effets de la correction essayée. Ne partagez pas la requête complète si elle contient le contenu du site. Ce dossier permet de choisir entre une optimisation applicative et un dimensionnement SQL justifié, sans transformer la réparation en série de hausses aveugles.