Mysql: MySQL 5.7 Aborted Connection - Vous avez une erreur lors de la lecture des paquets de communication

Testé avec la version go go1.7.3 darwin / amd64

Échoue toujours.

Qu'est-ce que le "journal des erreurs"? Est-ce le journal des erreurs du serveur MySQL?
Si tel est le cas, essayez-vous d'augmenter la verbosité du journal et de coller les journaux avant la ligne?
Que montre log.Printf("%s\n", err) ?

[Note] Aborted connection 13086 to db: '<redacted>' user: '<redacted>' host: '<redacted but not localhost, outside network connection>' (Got an error reading communication packets)

Est de /var/log/mysql/error.log
Je vais essayer avec une sortie plus verbeuse.

La chose curieuse est que log.Printf("%s\n", err) ne signale aucune erreur.

En fait, sql.Open() ne crée aucune connexion.
sql.Exec("SELECT 1+1") peut créer une connexion (et faire une erreur).

J'ai essayé d'augmenter la verbosité des journaux MySQL en utilisant

SET GLOBAL log_warnings=3;

et ont également essayé d'imprimer les erreurs de la requête SQL directement en utilisant

stmt, queryErr := db.Query(sqlQuery.String())
log.Printf("error: %s\n", queryErr.Error())
log.Printf("stmt error: %s\n", stmt.Err())

Mais pas encore de chance. L'exécution de la requête SQL (que je ne peux malheureusement pas partager ici) dans le client mysql cli, fonctionne à 100%.

Des idées? Cela a totalement cassé nos binaires. Ils ne peuvent pas se connecter à une base de données MySQL, qu'elle soit locale ou distante.

J'ai essayé différentes versions de MySQL et différentes versions de golang (1.7.3 et plus).

J'ai également construit ceci sur une machine Linux avec une nouvelle copie installée de github.com/go-sql-driver/mysql sans résultat positif.

Tous les conseils que vous pourriez avoir pour résoudre ce problème sont très appréciés.

Got an error reading communication packets suggère que quelque chose s'est mal passé pendant que MySQL attendait un paquet. Vous pouvez utiliser Wireshark ou tcpdump pour inspecter plus en détail ce qui se passe exactement, par exemple après quel paquet il abandonne

Que signifie «mais pas encore de verrou»?
Le serveur MySQL n'enregistre rien en cas d'augmentation du niveau de journalisation?

Le niveau de journal de commutation

@julienschmidt Je vais essayer ça maintenant et voir si je peux aller quelque part avec ça.

J'ai essayé différentes versions de MySQL et différentes versions de golang (1.7.3 et plus).

Voulez-vous dire que le même problème s'est produit sur MySQL 5.6 également?

Votre rapport ne contient pas d'informations détaillées sur «ce que vous avez essayé et ce que vous avez obtenu».

De nombreux utilisateurs l'utilisent avec MySQL 5.7. Vous êtes la seule personne à signaler un problème.
Ce problème est très probablement causé par votre environnement. Veuillez rapporter des informations plus complètes.

@methane fera l'affaire.

Problème résolu.

Je ne sais pas trop comment. Recompilé le code plusieurs fois avec certaines sections commentées. Ensuite, j'ai poussé des versions avec des lignes spécifiques sans commentaire jusqu'à ce que je trouve le coupable. Malheureusement, j'ai tout décommenté un par un et cela a fonctionné. Aucune modification du code.

Vraiment énervant. Merci les gars pour votre contribution et votre aide. @julienschmidt votre idée de surveiller tcpdumps a été incroyablement utile, merci.

Je sais que c'est un problème ancien, mais lorsque je recherche ce problème, ce problème apparaît dans les résultats de la recherche
Dans mon cas, le problème apparaît parce que j'ai oublié de fermer la connexion .

alors n'oubliez pas de fermer votre connexion db.Close()

J'ai eu exactement le même problème. Le code fonctionne avec mysql 5.6 et échoue avec 5.7.
Encore plus curieusement, dans msyql5.7, un select x,y from points limit 10 fonctionne. mais avec des limites plus grandes, il échoue avec le Got an error reading communication packets .
J'ai essayé de changer le paramètre de configuration mysqld max_allowed_packet car je m'attendais à ce que cela soit lié mais sans succès.

Je n'ai aucun problème avec MySQL 5.7.
Comment se reproduire? code? configuration mysql?

Je ne sais pas s'il s'agissait de la mise à jour du système d'exploitation ( macOS 10.13 ) ou de la mise à niveau de MariaDB ( 10.2.9-MariaDB Homebrew ), mais je peux reproduire ce bogue maintenant.

La cause semble être notre mode strict bien-aimé.
Si je le désactive, tout fonctionne bien.

Je résous ce problème en commentant les valeurs de wait_timeout, interactive_timeout, connect_timeout sur mon mysql.sock. Mon message d'avertissement est arrêté après avoir commenté ces lignes.
Par défaut, wait_time et interactive_timeout seront 28800, lors de l'installation de MySQL 5.7 sur mon serveur de production, MySQL a ajouté ces lignes, après avoir commenté ces 3 lignes, cela a fonctionné sans afficher de message d'avertissement:
"
[Note] Connexion abandonnée à la base de données: '-----' utilisateur: '----' hôte: 'localhost' (Délai d'expiration de la lecture des paquets de communication) "

Même erreur avec une connexion java d'Eclipse à MySql 5.7 sous Windows 10.
J'ai trouvé le service mysql57 en panne et je dois le redémarrer manuellement
Après 2 heures de travail, il s'arrête à nouveau
2018-09-06T12:22:59.135348Z 62 [Note] Aborted connection 62 to db: 'compute_pin_teh' user: 'compute_pin_teh' host: 'localhost' (Got an error reading communication packets) 2018-09-06T12:22:59.145322Z 63 [Note] Aborted connection 63 to db: 'compute_pin_teh' user: 'compute_pin_teh' host: 'localhost' (Got an error reading communication packets) 2018-09-06T12:23:18.526921Z 65 [ERROR] InnoDB: Operating system error number 21 in a file operation. 2018-09-06T12:23:18.527918Z 65 [Note] InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html 2018-09-06T12:23:18.527918Z 65 [ERROR] InnoDB: File f:\mysql\tables\compute_pin_teh\photo_resell.ibd: 'Windows aio' returned OS error 121. Cannot continue operation 2018-09-06T12:23:18.528914Z 65 [ERROR] InnoDB: Cannot continue operation. 2018-09-06T12:23:20.924476Z 0 [Note] InnoDB: FTS optimize thread exiting. 2018-09-06T12:24:59.184704Z 65 [Warning] InnoDB: 13 threads created by InnoDB had not exited at shutdown!