L'un des tueurs silencieux de MySQL Connections est le paquet MySQL. Même le thread d'E / S de la réplication MySQL peut en être victime.
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ête 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. Plus d'informations sur la définition de la taille des paquets sont fournies dans la 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.
À tout le moins, vous devez vous assurer que les tailles de paquet pour la machine à partir de laquelle vous mysqldumped et la machine que vous chargez sont identiques.
Vous pouvez adopter deux (2) approches:
APPROCHE # 1: Effectuez le mysqldump en utilisant --skip-extended-insert
Cela garantira que le paquet MySQL n'est pas inondé de plusieurs BLOBs, champs TEXT. De cette façon, les INSERT SQL sont effectués un à la fois. Les principaux inconvénients sont
- le mysqldump est beaucoup plus grand
- recharger un tel vidage prend beaucoup plus de temps.
APPROCHE # 2: Augmenter max_allowed_packet
Cela peut être l'approche préférée car l'implémentation n'est qu'un redémarrage de mysql. Comprendre ce qu'est le paquet MySQL peut clarifier cela.
Selon la page 99 de "Understanding MySQL Internals" (ISBN 0-596-00957-7) , voici les paragraphes 1-3 qui l'expliquent:
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 morceau, qui est appelé un 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.
Compte tenu de cette explication, faire des INSERT en vrac chargera / déchargera un paquet MySQL assez rapidement. Cela est particulièrement vrai lorsque max_allowed_packet est trop petit pour la charge donnée de données qui y arrive.
CONCLUSION
Dans la plupart des installations de MySQL, je la règle généralement sur 256M ou 512M. Vous devriez expérimenter avec des valeurs plus grandes lorsque le chargement des données produit des erreurs «MySQL a disparu».
max_allowed_packetà 900M et j'utilisais--skip-extended-insert(et vous avez raison - cela fait des db-dumps huuuge), mais cela échoue toujours. Je soupçonne une ligne particulière dans le dépotoir maintenant que je peux probablement contourner. Mais c'est toujours bizarre - le vidage peut être importé très bien sur mon serveur CentOS.