Erreur de lecture des paquets de communication MySQL
Dans les journaux d'erreurs 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)
Je n'ai pas remarqué de perte de données en soi, donc je me demande ce que cet avertissement signifie, ou ce qui le provoque, et si l'on pourrait résoudre le problème à l'origine de ces derniers. C'est sur RHEL 6.1 et MySQL Enterprise 5.5.
L'un des tueurs silencieux de MySQL Connections est le paquet MySQL.
Tout d'abord, découvrons ce qu'est un paquet MySQL.
Selon le page 99 de "Understanding MySQL Internals" (ISBN 0-596-00957-7) , voici les paragraphes 1-3 expliquant les paquets MySQL:
Le code de communication réseau MySQL a été écrit en supposant que les requêtes sont toujours raisonnablement courtes, et peuvent donc être envoyées et traitées par le serveur en un seul bloc, qui est appelé paquet dans la terminologie MySQL. Le serveur alloue la mémoire à un tampon temporaire pour stocker le paquet et il en demande suffisamment pour l'adapter entièrement. Cette architecture nécessite une précaution pour éviter que le serveur manque de mémoire --- un plafond sur la taille du paquet, ce que cette option accomplit.
Le code d'intérêt par rapport à cette option se trouve dans sql/net_serv.cc . Jetez un œil à my_net_read () , puis suivez l'appel à my_real_read () et portez une attention particulière à net_realloc () .
Cette variable limite également la longueur d'un résultat de nombreux fonctons de chaîne. Voir sql/field.cc et sql/intem_strfunc.cc pour plus de détails .
En sachant cela sur les paquets MySQL, un développeur/DBA peut les dimensionner pour accueillir plusieurs BLOB à l'intérieur d'un même paquet, même s'ils sont odieusement volumineux. Certainement, un paquet trop petit causera 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 s'est mal passé avec le client et ferme la connexion. Si vous avez besoin de grandes requêtes (par exemple, si vous travaillez avec de grandes colonnes BLOB), vous pouvez augmenter la limite de requêtes en définissant la variable max_allowed_packet du serveur, qui a une valeur par défaut de 1 Mo. Vous devrez peut-être également augmenter la taille maximale des paquets côté client. Pour plus d'informations sur la définition de la taille de paquet, reportez-vous à Section C.5.2.10, "Paquet trop volumineux".
Une instruction INSERT ou REPLACE qui insère un grand nombre de lignes peut également provoquer ce type d'erreurs. L'une ou l'autre de ces instructions envoie une seule demande 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'augmenter 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 ensemble de données actuel.
Pour définir le max_allowed_packet à 256 Mo, vous pouvez l'ajouter à /etc/my.cnf ou my.ini
[mysqld]
max_allowed_packet=256M
pour couvrir les redémarrages futurs 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 par défaut, max_connections sera égal à 100. Essayez d'augmenter le paramètre de configuration
max_connections = 400, après avoir défini dans my.cnf, redémarrez le serveur ou définissez-le dynamiquement:
set @@global.max_connections = 400;
Essayez simplement la recommandation ci-dessus pour éviter ces messages d'avertissement et assurez-vous également que votre réseau n'a pas de pertes de paquets.
J'ai rencontré ce problème récemment après être passé de MySQL Enterprise 5.1.x à 5.7.x, sans aucune modification significative du code de l'application 'note 'a commencé à apparaître.
Dans mon cas, la cause principale de l'apparition de 'note' était le programme sortant avec des connexions toujours ouvertes. La circonstance pour les connexions non fermées était un peu plus impliquée et non liée à MySQL mais ACE, les threads et TSS.
Non mentionné ici, donc j'inclus une autre cause de ce problème. Dans mon cas, lors de l'utilisation du client de ligne de commande mysql, l'erreur a été provoquée par une faible valeur de 30 secondes de interactive_timeout:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Cela persistera à travers les sessions mais pas au redémarrage du serveur.
SET GLOBAL interactive_timeout=6000;