Erreur MySQL lors de la lecture des paquets de communication

Dans les journaux d'erreur MySQL, je vois ces quelques avertissements comme ceux-ci:

120611 16:12:30 [Warning] Aborted connection 2619503 to db: 'db_name' user: 'user_name' host: 'webapp_hostname' (Got an error reading communication packets)

N'ayant pas remarqué de perte de données en tant que telle, je me demande donc ce que signifie cet avertissement, ou quelle en est la cause, et si l'on peut trouver une solution au problème qui en est la cause. Cela concerne RHEL 6.1 et MySQL Enterprise 5.5.

L'un des tueurs silencieux de MySQL Connections est le paquet MySQL.

Premièrement, voyons ce qu'est un paquet MySQL.

Selon la page 99 de "Comprendre les composants internes de MySQL" (ISBN 0-596-00957-7) , voici les paragraphes 1 à 3 qui expliquent les paquets MySQL:

Le code de communication réseau MySQL a été écrit en partant du principe que les requêtes sont toujours raisonnablement courtes et peuvent donc être envoyées au serveur et traitées par celui-ci en un seul bloc, appelé paquet dans la terminologie MySQL. Le serveur alloue de la mémoire à un tampon temporaire pour stocker le paquet et en demande suffisamment pour l'adapter complètement. Cette architecture nécessite une précaution afin d’éviter que le serveur ne manque de mémoire --- une limitation de la taille du paquet, ce que cette option permet de réaliser.

Le code d’intérêt associé à cette option se trouve dans sql / net_serv.cc . Jetez un coup d'œil à my_net_read () , puis suivez l'appel de my_real_read () et portez une attention particulière à net_realloc () .

Cette variable limite également la longueur d'un résultat de plusieurs fonctions de chaîne. Voir sql / field.cc et sql / intem_strfunc.cc pour plus de détails.

Sachant cela à propos des paquets MySQL, un développeur / administrateur de base de données peut les dimensionner pour prendre en charge plusieurs objets BLOB dans un même paquet, même s'ils sont excessivement volumineux. En définitive, un paquet trop petit posera des problèmes pour les connexions ouvertes à cet égard.

Selon la documentation MySQL

• Vous pouvez également obtenir ces erreurs si vous envoyez au serveur une requête incorrecte ou trop volumineuse. Si mysqld reçoit un paquet trop volumineux ou en panne, il suppose que quelque chose ne va pas avec le client et ferme la connexion. Si vous avez besoin de requêtes volumineuses (par exemple, si vous utilisez des colonnes BLOB volumineuses), vous pouvez augmenter la limite de requêtes en définissant la variable max_allowed_packet du serveur, dont la valeur par défaut est 1 Mo. Vous devrez peut-être également augmenter la taille de paquet maximale du côté client. Pour plus d'informations sur la définition de la taille de paquet , reportez-vous à la Section C.5.2.10, «Paquet trop volumineux».

• Une instruction INSERT ou REPLACE insérant un grand nombre de lignes peut également provoquer ce type d'erreur. L'une ou l'autre de ces déclarations envoie une seule requête au serveur, quel que soit le nombre de lignes à insérer. ainsi, vous pouvez souvent éviter l'erreur en réduisant le nombre de lignes envoyées par INSERT ou REPLACE.

RECOMMANDATION

Essayez d'élever le max_allowed_packet à un nombre beaucoup plus grand, car la valeur par défaut est 1M. Je suggérerais environ 10 fois le plus grand champ TEXT ou BLOB que vous avez dans votre jeu de données actuel.

Pour définir max_allowed_packet sur 256 Mo, vous pouvez l'ajouter à /etc/my.cnf ou my.ini.

[mysqld]
max_allowed_packet=256M

pour couvrir les futurs redémarrages de mysqld. Pour installer la valeur maintenant sur le serveur, veuillez exécuter ceci:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;

Essaie !!!

La plupart du temps, max_connections sera par défaut égal à 100. Essayez d'augmenter le paramètre config.

max_connections = 400, après avoir défini dans my.cnf, redémarrez le serveur ou définissez-le de manière dynamique:

    set @@global.max_connections = 400;

Essayez juste la recommandation ci-dessus pour éviter ces messages d’avertissement et assurez-vous également que votre réseau n’a pas de perte de paquets.

J'ai rencontré ce problème récemment après le passage de MySQL Enterprise 5.1.x à la version 5.7.x. Sans modification importante du code de l'application, la " note " a commencé à apparaître.

Dans mon cas, la cause principale de l'apparition de la " note " était la fermeture du programme alors que les connexions étaient encore ouvertes. Les circonstances pour lesquelles les connexions ne sont pas fermées étaient un peu plus complexes et ne concernaient pas MySQL mais ACE, les threads et TSS.

Cette ligne my.ini a résolu mon problème:

log_error_verbosity=1

Référence ce lien