Que faire des “[Warning] Aborted connection” avec MySQL ?

Un petit post sur cet avertissement que l’on rencontre bien souvent chez nos clients MySQL.
Ceux qui utilisent MySQL ont sans doute déjà croisé ce type de warning et découverts que les informations fournies par MySQL sur le sujet sont limitées (ainsi que les infos que l’on peut glaner sur le net)

Je veux parler ici d’erreurs récurrentes, qui se produisent de façon aléatoire plusieurs fois par jour, pas d’une erreur liée à un mauvais mot de passe ou à des privilèges insuffisants qui peuvent également générer ce type d’erreur.

Ce qu’en dit MySQL :

La page de documentation concernant ce problème est la suivante :

• http://dev.mysql.com/doc/refman/5.1/en/communication-errors.html

En fait, il y a deux raisons essentielles pour lesquelles MySQL est susceptible de renvoyer cette erreur : Des problèmes liés au réseau ou des problèmes liés au mode de sortie de session dans le code applicatif.
Pour ce dernier cas, attention à bien utiliser la fonction mysql_close() dans votre code applicatif.

Dans la pratique, que faire de cet avertissement ?

La première question à se poser est de savoir si ce problème affecte, d’une façon ou d’une autre, votre production.
Pour le savoir, plusieurs sources sont à votre disposition : Les utilisateurs qui peuvent vous remonter des erreurs, les logs applicatifs ou vos outils de monitoring qui clignotent trop régulièrement…

Si l’impact de cette erreur sur votre production est nulle, je vous recommande simplement de désactiver la remontée d’info la concernant via le paramètre log-warnings :

• set global log_warnings = 1;

Attention toutefois, la manipulation de ce paramètre peut entraîner la désactivation complète de tous les warnings. Rapprochez vous de la documentation de ce paramètre pour plus d’infos :

• http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_log-warnings

Sinon, je vous invite à suivre le mode opératoire suivant :

• Demander aux admins réseau de vérifier les différents composants réseau de votre architecture afin d’identifier d’éventuels problèmes
• Vérifier votre code applicatif et la bonne utilisation de la fonction mysql_close()
• Vérifier que vos clients MySQL ne dépassent pas le timeout de connexion défini par la variable connect_timeout
• Augmenter la valeur du paramètre max_allowed_packet (cette dernière méthode semble d’ailleurs porter ses fruits chez un grand nombre d’utilisateurs)

Si ces différentes opérations ne permettent pas d’identifier ou de régler votre problème, essayez d’appliquer chaque point préconisé dans la documentation mentionnée en début d’article et croisez les doigts !

N’hésitez pas à me faire un retour d’expérience sur ce point à travers les commentaires. Merci.

Bonne fin de semaine
Cédric.

Continuez votre lecture sur le blog :

• Attention aux requêtes en double avec Windev et MySQL ! (Benjamin VESAN) [MySQL]
• MySQL et les tables temporaires internes (Benjamin VESAN) [MySQL]
• Nouveautés MySQL 8.0 : Les indexes invisibles (Capdata team) [MySQL]
• Verrous sur INSERT IGNORE en mode d’isolation par défaut (David Baffaleuf) [MySQL]
• [ERROR] Error reading packet from server: Lost connection to MySQL server during query (David Baffaleuf) [Codes erreurMySQL]