Mysql: packets.go:66 : EOF inattendu suivi de packets.go:412 : buffer occupé suivi de driver : mauvaise connexion suivi de connection.go:319 : connexion invalide

S'agit-il de requêtes de longue durée ou de nombreuses requêtes de courte durée ?
La raison la plus probable des erreurs EOF sont les délais d'attente et les connexions fermées brusquement.

Cependant, je n'ai jamais été en mesure d'expliquer ces erreurs de tampon occupé.

Ce serait génial si quelqu'un pouvait fournir un exemple de programme.
Je voudrais préciser ce qui se passe exactement ici.

Un début pourrait être d'utiliser un panic() explicite dans packets.go:412 afin que nous puissions obtenir une trace de la pile.

@julienschmidt Merci pour la réponse très rapide !
Je crois que ce sont toutes des requêtes de courte durée très simples. Cependant, je n'ai jamais mesuré le temps des requêtes ... Peut-être que certaines d'entre elles ne sont pas si éphémères car certaines tables peuvent avoir beaucoup de lignes et manquer les index appropriés. Malheureusement, je ne peux pas modifier ces tables, je ne peux pas ajouter d'index. J'essaie d'augmenter les délais d'attente dans my.cnf , je signale si j'ai réussi à le comprendre.

@julienschmidt Cette autre personne (voir le lien StackOverflow) a fourni son programme complet sur github, mais j'ai bien peur que sans une énorme base de données, vous ne puissiez pas reproduire le problème...

BTW, il commence toujours par un "packets.go:66: EOF inattendu" , c'est la première indication qu'il y a un problème. Puis immédiatement après cela suit le "packets.go:412: tampon occupé"

Avez-vous essayé DB.SetConnMaxLifetime() ?

db.SetConnMaxLifetime(time.Second * 10) convient à la plupart des configurations.

Remplacer packets.go:66 par ce qui suit devrait alors produire des informations utiles pour le débogage :

fmt.Println(mc.buf)
panic(err.Error())

@methane Merci pour la suggestion ! J'essaie ça dans un instant.

@julienschmidt Je modifie packets.go comme vous l'avez suggéré à la ligne 66, recompilez le programme et relancez-le.

S'il échoue toujours, nous aurons une panique dans environ une heure. Je vous recontacte bientôt les gars !

Jusqu'ici tout va bien. Le programme fonctionne maintenant sans erreur sur deux serveurs depuis plus d'une heure.

Il y a de fortes chances que l'ajout db.SetConnMaxLifetime(time.Second * 10) ait aidé.

Mais ce n'était pas obligatoire avant...

@julienschmidt j'ai eu un Panic in packets.go:66

Veuillez consulter ce Gist : https://gist.github.com/tssajo/2939a5ef8fe3909d41ab6ac094600453

Remarque : La première longue ligne est le résultat de fmt.Println(mc.buf)

Si tu veux, je peux déplacer ces lignes :

fmt.Println(mc.buf)
panic(err.Error())

à packets.go:412, puis redémarrez le programme. Ensuite, vous aurez une trace de ce qui s'est passé ensuite. Voulez-vous que je fasse cela ?

Je peux fournir plus d'informations maintenant.
Voici la requête que j'exécute sur une table avec beaucoup de lignes (probablement des centaines de milliers):

rows, err := db.Query("SELECT `ID`,`post_name`,`post_parent` FROM `wp_posts` WHERE `post_status`='publish' AND (`post_type`='page' OR `post_type`='post') ORDER BY `ID`")

Je crois qu'ici je ne reçois pas d'erreur, mais je vais ajouter du code de débogage pour m'en assurer.
Cependant, ce qui se passe ensuite est vraiment intéressant : pendant que je lis les lignes avec rows.Next() dans une boucle, je mets les données de chaque ligne dans un canal. Ce canal est mis en mémoire tampon mais la taille de la mémoire tampon n'est que de 100. Je ne pourrai donc peut-être pas parcourir toutes les lignes assez rapidement. Parce qu'une autre routine go consiste à extraire et à traiter les données de ce canal, mais ce traitement peut prendre beaucoup de temps ! En outre, ce traitement implique l'émission de nombreuses autres instructions SELECT sur la même table - je ne sais pas si cela est pertinent ou non.

Je crois qu'un délai d'attente se produit à un moment donné à l'intérieur de la boucle for rows.Next() { et à partir de ce moment, je ne peux plus lire de données à partir de cet ensemble de résultats MySQL (l'objet rows). Finalement, la boucle se termine de toute façon, puis j'appelle rows.Err() , puis rows.Close() est également appelé en raison d'une instruction de report précédente.

Donc, je crois que rows.Next() puis rows.Err() et enfin rows.Close() est appelé APRÈS qu'un délai d'attente s'est produit.

Cela peut-il être la cause des problèmes que j'ai?
Je devrai peut-être augmenter les wait_timeout et les interactive_timeout dans my.cnf
Je rapporterai ici si cela a aidé ou non.

@tssajo une autre trace de pile à partir des paquets : 412 serait formidable

Un délai d'attente est très probable, mais il doit être géré sans erreurs étranges par le pilote

@julienschmidt Malheureusement, augmenter à la fois le wait_timeout et le interactive_timeout dans my.cnf n'a pas aidé (bien sûr, j'ai redémarré le serveur MySQL après avoir changé les valeurs). J'ai encore paniqué. Voici la trace de la pile, mais elle provient toujours de packets.go:66 :

https://gist.github.com/tssajo/8acfederc789dc7282ff991bf5662cd4d6

Ensuite, j'en crée un à partir des paquets : 412. Je viens de faire ce changement dans packets.go :

func (mc *mysqlConn) writeCommandPacket(command byte) error {
        // Reset Packet Sequence
        mc.sequence = 0

        data := mc.buf.takeSmallBuffer(4 + 1)
        if data == nil {
                // can not take the buffer. Something must be wrong with the connection
                fmt.Println(mc.buf)
                panic("data is nil after data := mc.buf.takeSmallBuffer(4 + 1)")
                errLog.Print(ErrBusyBuffer)
                return driver.ErrBadConn
        }

        // Add command byte
        data[4] = command

        // Send CMD packet
        return mc.writePacket(data)
}

Je recompile maintenant.

BTW, mes valeurs wait_timeout et mes interactive_timeout sont 300 (= 5 minutes) dans my.cnf maintenant. Cela peut-il encore être trop bas ? Je peux le régler sur 1 heure et voir si cela aide.

@julienschmidt Voici la panique aux paquets:412

https://gist.github.com/tssajo/4da2568ea8421ff80c2e4aec300e203a

Malheureusement, cela s'est produit avec les paramètres suivants dans my.cnf :

wait_timeout             = 3600
interactive_timeout      = 3600

Cela signifie que même avec un délai d'attente d'une heure, cela se produit toujours ! Je peux vous assurer que cela ne s'est PAS produit l'automne dernier lorsque les paramètres de délai d'attente étaient :

wait_timeout             = 30
interactive_timeout      = 30

Je ne suis donc plus sûr que cela soit dû à un délai d'attente. Peut-être que ce n'est pas un problème lié au délai d'attente après tout.

Voici ce que je vais faire maintenant : je vais recompiler le programme avec la version du 2 août 2016 du pilote go-sql ( commit : 0b58b37b664c21f3010e836f1b931e1d0b0b0685 ) et essayer le programme avec celui-là. Si celui-ci "plante" toujours, je rétrograderai également vers Go 1.7.x et compilerai le programme avec cela. Je viens de savoir que tout fonctionnait l'automne dernier.

S'il vous plaît, comprenez que c'est un vrai bug époustouflant pour moi et que je dois trouver une solution à ce problème bientôt. Si j'ai besoin d'utiliser une ancienne version du pilote et/ou de Go, je dois le faire avec hésitation (mais sans autre option). Quoi qu'il en soit, merci d'avoir essayé d'aider !

Malheureusement, avec la version du 2 août 2016 du pilote go-sql ( commit 0b58b37b664c21f3010e836f1b931e1d0b0b0685 ), j'obtiens toujours le même type d'erreurs enregistrées, voir :

[mysql] 2017/05/04 13:20:31 packets.go:59: unexpected EOF
[mysql] 2017/05/04 13:20:31 packets.go:386: busy buffer
driver: bad connection
[mysql] 2017/05/04 16:25:10 packets.go:59: unexpected EOF
[mysql] 2017/05/04 16:25:10 packets.go:386: busy buffer
driver: bad connection
[mysql] 2017/05/04 17:59:54 packets.go:59: unexpected EOF
[mysql] 2017/05/04 17:59:54 packets.go:386: busy buffer
driver: bad connection

Le programme ne s'arrête pas car pour le moment je n'ai pas ajouté panic() à packets.go
Mais de nombreux enregistrements (lignes) sont ignorés dans la base de données à cause de ce bogue. Je peux le confirmer lorsque le programme a fini de fonctionner - probablement demain. Parce que je compte combien d'enregistrements ont été traités avec succès. Je soupçonne qu'à la fin j'aurai des milliers d'enregistrements non traités, à cause de cette erreur.
Ensuite, je vais compiler le programme avec Go 1.7.x, puis réessayer. Je vous rapporterai les résultats.

Utilisez une version encore plus ancienne de Go si possible, nous prenons en charge tout Go 1.2+

@julienschmidt Oui, si Go 1.7 échoue, je retourne une version de plus. Mais je crois que cela a fonctionné avec 1,7 l'année dernière vers septembre ou octobre.

BTW, j'ai déjà remarqué une différence! Lorsque j'utilise la dernière version du pilote mysql avec Go 1.8.1
Je reçois 4 lignes enregistrées à la suite du problème, voir:

[mysql] 2017/05/02 16:48:51 packets.go:66: unexpected EOF
[mysql] 2017/05/02 16:48:52 packets.go:412: busy buffer
driver: bad connection
[mysql] 2017/05/02 16:48:52 connection.go:319: invalid connection

Cependant, lorsque j'utilise la version du 2 août 2016 du pilote go-sql ( commit 0b58b37b664c21f3010e836f1b931e1d0b0b0685 ) avec également Go 1.8.1
Je n'ai que 3 lignes, voir:

[mysql] 2017/05/04 13:20:31 packets.go:59: unexpected EOF
[mysql] 2017/05/04 13:20:31 packets.go:386: busy buffer
driver: bad connection

Comme vous pouvez le voir ci-dessus, je ne reçois pas de message "connexion invalide" de connection.go lorsque j'utilise l'ancienne version du pilote.

Je vois la même erreur à la ligne 33 dans packets.go. Nous essayions de mettre à niveau certaines de nos dépendances, en particulier la bibliothèque de migration que nous utilisons. Le PR peut être trouvé ici https://github.com/docker/notary/pull/1151

Si vous avez installé docker, vous devriez pouvoir exécuter docker-compose build && docker-compose up pour voir l'erreur.

Je ne suis en mesure de reproduire cela que sur Windows de manière intéressante.

J'ai réussi à résoudre ce problème ! Cela n'avait rien à voir avec la version Go ou la version du pilote Go MySQL.

Il s'avère que c'était une combinaison de choses. Dans mon cas, le problème ressemblait beaucoup à ce problème : https://github.com/go-sql-driver/mysql/issues/281 J'ai donc ajouté ces lignes à my.cnf :

net_read_timeout         = 14400
net_write_timeout        = 14400

J'ai également modifié les paramètres de délai d'attente suivants pour leurs valeurs par défaut MySQL (auparavant, j'avais des valeurs beaucoup plus faibles pour ceux-ci) :

wait_timeout             = 28800
interactive_timeout      = 28800

De plus, ce qui a été suggéré par @methane était également requis :

db.SetConnMaxLifetime(time.Second * 20)

Je l'ai réglé sur 20 secondes au lieu des 10 suggérées, cela fonctionne parfaitement pour moi.

Depuis que j'ai apporté les modifications ci-dessus, j'ai cessé de voir l'erreur.

Quand j'ai dit, j'ai utilisé le même programme sur la même base de données l'année dernière et à ce moment-là je n'ai pas vu cette erreur, c'était également vrai. Cependant, mon programme génère des pages statiques à partir d'un site Web dynamique (basé sur WordPress) et depuis l'année dernière, le modèle WP est devenu plus complexe et nous avons également changé le site Web en SSL. Tous ces changements ont rendu le traitement de chaque page plus long. Pour cette raison, j'ai récemment commencé à rencontrer des délais d'attente MySQL dans cette longue boucle, tout comme il est décrit ici : https://github.com/go-sql-driver/mysql/issues/281
Dans mon cas, le traitement est devenu plus lent, j'ai donc commencé à voir des délais d'attente à des endroits où je n'avais jamais vu de délais d'attente auparavant.

Je suis désolé mais je dois rouvrir ce ticket. L'erreur s'est reproduite :

[mysql] 2017/05/09 18:56:37 packets.go:66: unexpected EOF
[mysql] 2017/05/09 18:56:37 packets.go:412: busy buffer
driver: bad connection

L'augmentation des délais d'expiration de MySQL a vraiment beaucoup aidé. Mais cela ne résout toujours pas complètement ce problème.

Voulez-vous dire qu'il est reproduit avec db.SetConnMaxLifetime(time.Second * 20) ?

@methane Oui, db.SetConnMaxLifetime(time.Second * 20) n'a pas complètement résolu le problème. Cela a certainement beaucoup aidé, cependant.

Dans mon cas, le délai d'attente se produit dans une boucle longue, cette boucle s'exécute pendant plusieurs jours ! La boucle est similaire à celle décrite ici : https://github.com/go-sql-driver/mysql/issues/281
Récemment, le timeout ne s'est produit que sur l'un de mes serveurs et seulement après plusieurs jours.

L'augmentation des valeurs de délai d'attente dans le fichier my.cnf a certainement beaucoup aidé. Avant d'augmenter les valeurs de délai d'attente, j'ai pu voir ce problème apparaître sur deux autres serveurs, et sur ce même serveur, il est apparu juste après quelques heures d'exécution du programme. À l'heure actuelle, le problème n'est apparu que sur un seul serveur et seulement après des jours de fonctionnement sans problème.

Je pense que peut-être un logrotate MySQL s'est produit ou quelque chose qui a fermé la connexion MySQL prématurément. Je vais étudier cette possibilité.

Dans mon cas, le délai d'attente se produit dans une boucle longue, cette boucle s'exécute pendant plusieurs jours ! La boucle est similaire à celle décrite ici : #281

Oh, voulez-vous dire que vous faites un gros travail dans la boucle rows.Next() ?
Vous devez récupérer toutes les lignes et appeler rows.Close() dès que possible, et faire votre travail avec les lignes récupérées.

@methane Oui, en dernier recours, j'envisageais déjà de faire ce changement. Obtenez rapidement toutes les lignes, enregistrez les données dans un fichier temporaire, puis effectuez le traitement en parcourant les lignes de ce fichier texte. La raison pour laquelle j'ai besoin d'enregistrer les données dans un fichier texte, car les données peuvent ne pas tenir en mémoire. Ce programme fonctionne avec des gouttelettes DigitalOcean à 5 $ par mois, celles-ci n'ont que 512 Mo de RAM ...

Merci pour la suggestion!

Je pense que ce n'est qu'un comportement du serveur MySQL et que le client (pilote) ne peut rien faire.
Pourquoi avez-vous rouvert ce problème ?

Je l'ai rouvert lorsque mon programme s'est terminé après plusieurs jours d'exécution de tous les enregistrements et à la fin, j'ai vu que de nombreuses lignes n'étaient pas traitées, ignorées. Je regarde la sortie enregistrée et j'ai vu la même erreur. J'ai donc rouvert.

Je peux le fermer mais ça continue.

Votre solution de contournement suggérée fonctionnera plus que probablement. Mais ce n'est qu'une solution de contournement.

Merci de votre aide!

Est-ce que quelqu'un a compris pourquoi c'est un problème et a une solution?

J'ai également remarqué que si je ne définissais aucun délai d'attente, la requête mourrait après quelques-unes de ces erreurs de tampon occupé avec une mauvaise erreur de connexion.

Je ne pense pas que cela devrait être fermé car ce n'est certainement pas un problème résolu.

@shuhaowu À mon avis, il peut être fermé maintenant, car nous avons déterminé qu'il s'agissait d'un problème MySQL. Dans mon cas, le programme Go a duré plus de 24 heures. Nous avons compris qu'un "ensemble de résultats" ne peut pas être conservé aussi longtemps, il s'agit plus que probablement d'un problème MySQL, pas d'un problème de pilote Go. J'ai donc modifié mon programme : je parcoure rapidement le jeu de résultats en boucle et stocke simplement les données dans une tranche. De cette façon, je n'obtiens jamais l'erreur de tampon occupé ou toute autre erreur. Une fois que j'ai les données stockées dans la tranche, je parcoure les éléments de cette tranche et fais le travail réel sur chaque élément. Mon programme a définitivement été corrigé de cette façon.
Cependant, je suis un peu préoccupé par l'utilisation de la mémoire de mon programme. Parce que maintenant, je dois conserver tous les résultats de la requête initiale dans une tranche. Cette requête a renvoyé des centaines de milliers de lignes ! Je pourrais donc manquer de mémoire. Heureusement, ce n'était pas mon cas. Mais si cela s'était produit, j'aurais alors stocké toutes ces lignes dans un fichier temporaire sur le disque, puis parcouru les lignes de ce fichier.
Dans l'ensemble, les solutions de contournement fonctionneront. Mais c'est clairement un problème MySQL, pas un problème de pilote Go, à mon avis.
C'est pour ça que j'ai fermé ça.

Si quelqu'un a une idée de la manière dont le pilote pourrait fournir un message d'erreur plus utile, veuillez nous en informer ou soumettre une demande d'extraction.
Les erreurs actuelles ne sont malheureusement pas utiles du tout.

Je suis confronté au même problème, mais j'ai résolu de mettre "DELIMITER $$" avant la procédure mysql ou de sélectionner et "END" à la fin du script. j'espère que ça aide

Je rencontre cela également. J'ai un programme de collecte de données qui fait des milliers et des milliers de petites requêtes. Après quelques heures, je finis toujours par recevoir

[mysql] 2018/01/10 07:43:08 packets.go:36: unexpected EOF
[mysql] 2018/01/10 07:43:08 packets.go:431: busy buffer
2018/01/10 07:43:08 invalid connection

@donatj Avez-vous lu ce fil?
Avez-vous essayé cela ?

Votre commentaire est très inutile. Il manque beaucoup d'informations.
Le journal n'est qu'un journal. Il vous informe que la connexion est interrompue. Le conducteur ne peut pas savoir pourquoi cela se produit.
Nous et le pilote ne pouvons pas vérifier votre configuration MySQL, les paramètres de votre système d'exploitation ou rechercher tcpdump.
Seul vous (ou votre infra membre) pouvez le faire.

Sans exemple complet et reproductible, ce n'est pas un rapport de problème. Juste un bruit.

@methane J'ai lu tout le fil, ligne par ligne, car c'est un obstacle majeur pour moi.

tssajo a noté que

À mon avis, il peut être fermé maintenant [...] le programme Go a duré plus de 24 heures. Nous avons compris qu'un "ensemble de résultats" ne peut pas être conservé aussi longtemps

Il dit que le problème ne s'est produit qu'avec des ensembles de résultats de longue durée - c'est pourquoi je notais que je le recevais avec des ensembles de résultats de courte durée. Je pensais que c'était une nouvelle information.

Pardon.

Ce n'est qu'une des nombreuses raisons pour lesquelles la connexion TCP est interrompue.
Je recommande à tout le monde d'utiliser db.SetConnMaxLifetime(time.Second * 10)
à moins qu'ils ne puissent résoudre leur problème par eux-mêmes.

Le problème ne peut pas être parfaitement résolu.
Si l'utilisateur a une table beaucoup plus grande que 1 To et que le réseau est très rapide,. encore plus rapide que le disque.
Récupérer les lignes dès que possible et les stocker sur un disque ne résoudra pas ce problème.