Mysql
 sql >> Base de données >  >> RDS >> Mysql

L'erreur courante de MySQL :"Erreur lors de la lecture du paquet de communication"

MySQL est la deuxième base de données célèbre au monde selon le site Web DB Engine derrière Oracle. Ce qui rend MySQL célèbre, c'est probablement parce qu'il s'agit d'un système de gestion de base de données très rapide, fiable et flexible. MySQL est également l'une des bases de données prises en charge dans ClusterControl. Vous pouvez facilement déployer, mettre à l'échelle, surveiller et faire beaucoup de choses avec ClusterControl.

Aujourd'hui, nous n'allons pas en parler, mais nous allons discuter de l'une des erreurs courantes pour MySQL et des conseils de dépannage possibles. Lorsque nous travaillons avec des tickets, souvent lorsque nous vérifions les rapports d'erreurs ou les journaux, nous avons vu cette ligne "Une erreur s'est produite lors de la lecture du paquet de communication" assez fréquemment. Nous pensons qu'il serait avantageux que nous écrivions un blog lié à cette erreur non seulement pour nos clients mais aussi pour d'autres lecteurs. N'attendons plus, il est temps de plonger davantage !

Protocole Client/Serveur MySQL

Tout d'abord, nous devons comprendre la manière dont MySQL communique entre le client et le serveur. Le client et le serveur utilisent tous deux le protocole MySQL qui est implémenté par les connecteurs, le proxy MySQL ainsi que la communication entre les serveurs de réplication maître et esclave. Le protocole MySQL prend en charge les fonctionnalités telles que le cryptage transparent via SSL, la compression transparente, une phase de connexion ainsi qu'une phase de commande.

Les entiers et les chaînes sont les types de données de base utilisés dans le protocole MySQL. Chaque fois que le client et le serveur MySQL souhaitent communiquer entre eux ou envoyer des données, il divise les données en paquets d'une taille maximale de 16 Mo et ajoute également un en-tête de paquet à chaque morceau. À l'intérieur de chaque paquet, il y aura une charge utile où les types de données (entiers/chaînes) jouent leur rôle.

Étant donné que le CLIENT_PROTOCOL_41 est activé, pour presque chaque commande que le client envoie au serveur, le serveur répondra à l'un des paquets suivants :

OK_Packet

Ceci est le signal pour chaque commande réussie.

ERR_Paquet

Le signal indique une erreur pour le paquet.

EOF_Paquet

Ce paquet contient un avertissement ou un indicateur d'état.

Comment diagnostiquer les problèmes

Généralement, il existe deux types de problèmes de connexion, à savoir les erreurs de communication ou les connexions interrompues. Chaque fois que l'un de ces problèmes de connexion se produit, les sources d'informations suivantes constituent un bon point de départ pour le dépannage et l'analyse :

  • Le journal des erreurs

  • Le journal général des requêtes

  • Les variables d'état Aborted_xxx et Connection_errors_xxx

  • Le cache de l'hôte

Erreurs de connexion et raisons possibles

En cas d'erreurs de connexion et en fonction des erreurs, il incrémentera le compteur d'état pour Aborted_clients ou Aborted_connects dans les variables d'état. Comme tiré de la documentation MySQL, Aborted_clients signifie le nombre de connexions qui ont été abandonnées parce que le client est mort sans fermer correctement la connexion. Quant à Aborted_connects, cela signifie le nombre de tentatives infructueuses de connexion au serveur MySQL.

Si vous démarrez le serveur MySQL avec l'option --log-warnings, il y a de fortes chances que vous voyiez l'exemple du message suivant dans votre journal d'erreurs. Comme vous l'avez remarqué, le message indique clairement qu'il se rapporte à l'abandon de la connexion. Par conséquent, le compteur d'état Aborted_connects sera incrémenté dans la variable d'état :

[Avertissement] Connexion abandonnée 154669 à la base de données :'wordpress' utilisateur :'wpuser' hôte :'hostname' (une erreur s'est produite lors de la lecture des paquets de communication)

Normalement, des tentatives de connexion infructueuses peuvent se produire pour les raisons suivantes. Lorsque vous avez remarqué cela, cela indique peut-être qu'une personne non autorisée est sur le point de violer la base de données et vous voudrez peut-être l'examiner le plus tôt possible :

  • Un client n'a aucun privilège pour accéder à la base de données.

  • Un mauvais identifiant a été utilisé.

  • Un paquet de connexion contenant des informations incorrectes.

  • En raison de la limite atteinte pour connect_timeout pour se connecter.

La variable d'état pour Aborted_clients sera incrémentée par le serveur si un client parvient à se connecter mais se déconnecte ou se termine de manière inappropriée. En plus de cela, le serveur enregistrera également un message de connexion interrompue dans le journal des erreurs. Pour ce type d'erreur, cela peut généralement être dû à la raison suivante :

  • Le client ne ferme pas correctement la connexion avant de quitter (n'appelle pas mysql_close()).

  • Le client a dépassé wait_timeout ou interactive_timeout secondes.

  • Le programme client ou l'application s'est soudainement arrêté au milieu du transfert de données.

Outre les raisons précédentes, d'autres raisons probables pour les connexions interrompues et les problèmes de clients abandonnés peuvent être liées à l'un des éléments suivants :

  • Configuration TCP/IP foirée.

  • La valeur de la variable est trop petite pour max_allowed_packet.

  • Allocation de mémoire insuffisante pour les requêtes.

  • Matériel défectueux comme Ethernet, commutateurs, câbles, etc.

  • Problèmes avec la bibliothèque de threads.

  • Problème de syndrome duplex où le transfert passe en mode burst-pause-burst-pause (si vous utilisez le protocole Ethernet avec Linux, semi-duplex et duplex intégral).

Comment réparer les erreurs de communication MySQL

Maintenant que nous avons appris beaucoup de potentialités qui ont causé des erreurs de connexion MySQL. D'après notre expérience, la plupart du temps, ce problème est lié à des problèmes de pare-feu ou de réseau. Il est également juste de dire qu'il n'est pas facile de diagnostiquer ce genre de problème. Néanmoins, la solution suivante peut vous être utile pour résoudre cette erreur :

  • Si votre application s'appuie sur le délai d'attente pour fermer la connexion, cela vaut la peine de modifier la logique de l'application afin qu'elle soit correctement fermé à la fin de toute opération.

  • Assurez-vous que la valeur de max_allowed_packet est dans la plage acceptable afin que le client ne reçoive aucune erreur liée à le "paquet trop volumineux".

  • Pour les problèmes de délai de connexion qui pourraient être dus au DNS, il vaut la peine de vérifier si vous avez skip-name- résolution activée.

  • Si vous utilisez une application PHP ou toute autre programmation, le mieux est de vous assurer qu'elle n'abandonne pas les connexions qui sont généralement définies à max_execution_time.

  • Si vous avez remarqué beaucoup de notifications TIME_WAIT de netstat, cela vaut la peine de confirmer que les connexions sont bien gérées sur le fin de l'application.

  • Si vous utilisez Linux et pensez que le problème est dû au réseau, il est préférable de vérifier l'interface réseau en utilisant la commande ifconfig-a et examinez la sortie sur le serveur MySQL pour toute erreur.

  • Pour les utilisateurs de ClusterControl, vous pouvez activer le journal d'audit à partir de Cluster -> Sécurité -> Journal d'audit. En activant cette fonctionnalité, cela pourrait vous aider à affiner la recherche de la requête en cause.

  • Les outils de mise en réseau tels que tcpdump et Wireshark pourraient être utiles pour identifier les problèmes de réseau potentiels, les délais d'attente et les problèmes de ressources pour MySQL.

  • Vérifiez régulièrement le matériel en vous assurant qu'il n'y a pas de périphériques défectueux, en particulier pour les Ethernets, les hubs, les commutateurs, les câbles etc. Il vaut la peine de remplacer l'appareil défectueux pour s'assurer que la connexion est bonne tout le temps.

Conclusion

De nombreuses raisons peuvent entraîner des problèmes de paquets de connexion MySQL. Chaque fois que ce problème se produit, il affectera certainement l'entreprise et les opérations quotidiennes. Même si ce type de problème n'est pas facile à diagnostiquer et que la plupart du temps il est dû au réseau ou au pare-feu, il vaut la peine de prendre en considération toutes les étapes qui ont été suggérées précédemment afin de résoudre le problème. Nous espérons vraiment que cet article de blog pourra vous aider d'une manière ou d'une autre, en particulier lorsque vous rencontrez ce problème.