ERROR 2013 (HY000): Connexion perdue avec le serveur MySQL lors de la lecture du paquet d'autorisation, erreur système:
Je reçois l'erreur suivante
ERROR 2013 (HY000): Lost connection to MySQL server at
'reading authorization packet', system error: 0
en essayant de me connecter à mon serveur MySQL.
Que suis-je en train de faire:
- J'ai une réplication maître-esclave dans MySQL qui fonctionne et vient d'ajouter des capacités d'équilibrage de charge avec F5.
- J'ai configuré le F5 en fonction de leur site.
Mais lorsque j'essaie de me connecter à mon serveur MySQL en utilisant l'adresse IP avec laquelle le F5 a été configuré, je reçois
ERROR 2013 (HY000): Lost connection to MySQL server at
'reading authorization packet', system error: 0
Des idées?
Le point sur mes progrès:ZÉRO
- Je reçois la même erreur Je ne reçois aucune entrée dans/var/log/secure comme si quelqu'un essayait de s'authentifier à partir de l'adresse IP où j'avais créé mon serveur d'équilibrage de charge.
Aucune entrée dans le journal des erreurs mysql.
La commande - ne renvoie rien
mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connections';
Empty set (0.00 sec)
J'ai déjà modifié mon fichier my.cnf et ajouté le
[mysqld]
skip-name-resolve
Modifiez le connect_timeout à 10.
Donc, il semble que je n’obtienne aucune réponse pour le serveur que j’ai créé sur mon F5
J'ai finalement convaincu l’administrateur F5 de me transmettre le journal du serveur F5 et j’ai passé tout ce que j’avais besoin de le former.
Voici la sortie:
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside initial connection
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside responding with server WELCOME packet
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- clientside authenticated flag not set
Jan 28 15:46:39 tmm err tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- mysql client: attempting to do something before authentication
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <LB_SELECTED>: BIG-IP MySQL Proxy -- serverside selected pool /Common/foss-mysql-slave_pool node SLAVE-IP
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_CLOSED>: BIG-IP MySQL Proxy -- clientside connection closed from MASTER-IP(XXXXXXX)
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <SERVER_CLOSED>: BIG-IP MySQL Proxy -- serverside connection closed from node SLAVE-IP(XXXXXXXX)
J'ai remplacé l'ip pour des raisons de sécurité!
Juste comme un extra - et je pense que c'est là le problème - ma version de mysql est 5.1.69-log Thx All
Cela est généralement dû à une connexion interrompue. Vous pouvez le vérifier en vérifiant le statut:
mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connects';
Si ce compteur ne cesse d'augmenter au fur et à mesure que vous obtenez les connexions perdues, c'est que vous rencontrez un problème lors de la connexion.
Un remède qui semble fonctionner dans de nombreux cas consiste à augmenter le délai d'attente. Une valeur suggérée est 10 secondes:
mysql> SET GLOBAL connect_timeout = 10;
Une autre cause fréquente des délais d'attente de connexion est la recherche DNS inversée nécessaire lors de l'authentification des clients. Il est recommandé d’exécuter MySQL avec la variable config dans my.cnf:
[mysqld]
skip-name-resolve
Cela signifie que vos instructions GRANT doivent être basées sur une adresse IP plutôt que sur un nom d'hôte.
J'ai également trouvé ce rapport de 2012 sur le site f5.com (maintenant protégé par un login, mais je l'ai eu via Google cache )
Il est probable que le proxy ne fonctionnera pas si vous n’exécutez pas BIG-IP 11.1 et MySQL 5.1, versions sur lesquelles j’ai testé. Le protocole MySQL a l'habitude de changer.
Je vous suggère de contacter Support F5 et de confirmer que vous utilisez une combinaison de versions prise en charge.
Mon cas était que le serveur n'a pas accepté la connexion de cette adresse IP. Le serveur est un serveur SQL issu du moteur Google Apps et vous devez configurer des hôtes distants autorisés pouvant se connecter au serveur.
L'ajout du (nouvel) hôte à la page d'administration GAE a résolu le problème.
J'ai beaucoup lutté avec cette erreur. J'ai essayé chaque réponse que j'ai trouvée sur Internet.
En fin de compte, j'ai connecté mon ordinateur au point d'accès sans fil de mon téléphone portable et tout a fonctionné. Je me suis avéré que l'Internet de mon entreprise bloquait la connexion avec MySQL.
Ce n'est pas une solution complète, mais peut-être que quelqu'un fait face au même problème. Cela vaut la peine de vérifier la connexion.
J'utilise plusieurs connexions mysql (connexion à différents ensembles de bases de données) dans localhost.
Cela m’est arrivé après que j’ai éteint mon ordinateur et que mysql ne s’est pas arrêté correctement. Après avoir démarré ma machine, j’ai réussi à me connecter à plusieurs connexions de base de données, à l’exception d’une (j’utilisais cela beaucoup avant l’arrêt de la machine) . Conformément aux instructions de ce message, j’ai doublé connect_timeout mais je n’ai pas pu me connecter à cette connexion. une connexion de base de données.
J'ai redémarré ma machine et je peux maintenant me connecter avec succès. Cela vous aidera à vous débloquer, mais ce serait bien de pouvoir le réparer sans avoir à redémarrer la machine.
Une autre préoccupation est la suivante: connexion_timeout me semblait un problème lié au retard, mais je recevais immédiatement l'erreur dans localhost quand il n'y avait pas de réseau dans l'équation.
J'ai résolu ce problème en arrêtant plusieurs fois MySQL.
$ mysql.server stop
Shutting down MySQL
.. ERROR! The server quit without updating PID file (/usr/local/var/mysql/xxx.local.pid).
$ mysql.server stop
Shutting down MySQL
.. SUCCESS!
$ mysql.server stop
ERROR! MySQL server PID file could not be found! (note: this is good)
$ mysql.server start
Tout va bien d'ici. Je soupçonne que MySQL a été démarré plus d'une fois.
Une autre possibilité est la réinitialisation de la connexion depuis les wrappers TCP (/etc/hosts.deny et /etc/hosts.allow). Vérifiez simplement ce qui entre de telnet sur le port 3306 - si ce n’est rien, alors il ya quelque chose au milieu qui empêche la communication de se produire.
J'ai un mac mais je suppose que tous les linux sont les mêmes pour cette partie ...
Dans mon cas, j'ai eu ceci:
2018-12-03 11:13:27 - Start server:
2018-12-03 11:13:27 - Server start done.
2018-12-03 11:13:27 - Checking server status...
2018-12-03 11:13:27 - Trying to connect to MySQL...
2018-12-03 11:13:27 - Lost connection to MySQL server at 'reading authorization packet', system error: 0 (2013)
2018-12-03 11:13:27 - Assuming server is not running
J'ai couru ceci:
Sudo killall mysqld
Et puis, a recommencé le mysql via mysqlworkbench bien que dans votre cas cela ressemble à ceci:
mysql.server start
* Remarque: j'ai essayé d'exécuter mysql.server stop et j'ai obtenu ce Shutting down MySQL
.... SUCCESS! mais après avoir exécuté ps aux | grep mysql, j'ai constaté qu'il ne s'était pas vraiment arrêté.
Dans mon cas, cela s’est produit lorsqu’il y avait beaucoup de connexions au serveur MySQL (15 000 connexions) et que la mémoire disponible était d’environ 120Mo. Après avoir ajouté plus de mémoire au serveur, l'erreur avait disparu.