ERROR 2013 (HY000): Lost connection to MySQL serve

问题:

I am getting the following error

ERROR 2013 (HY000): Lost connection to MySQL server at 
'reading authorization packet', system error: 0

when trying to connect to my MySQL server.

What I am doing:

• I have Master - Slave replication in MySQL that is working and just added load balance capabilities using F5.
• I have configured the F5 according to their site.

But when I am trying to connect to my MySQL server using the IP that the F5 was configured with I get

ERROR 2013 (HY000): Lost connection to MySQL server at 
'reading authorization packet', system error: 0 

Any ideas?

---

Update on my progress : ZERO
- i am getting the same error I get no entries in the /var/log/secure as if somebody would try to authenticate coming form the ip where i had created my load balance server.
No enties in the mysql error log.
The command - returns nothing

mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connections';
Empty set (0.00 sec)

I've already altered my my.cnf file and add the

[mysqld]
skip-name-resolve

Alterd the connect_timeout to 10.
So it seems i get no response for the server i have created on my F5
I finally convinced the F5 admin to pass me the log for the F5 server and i have exctraced all i need form it.
Here is the output :

  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)

I've replaced the ip for security sake !

just as an extra - and i think is here the problem - my mysql version is 5.1.69-log Thx All

回答1:

From documentation:

More rarely, it can happen when the client is attempting the initial connection to the server. In this case, if your connect_timeout value is set to only a few seconds, you may be able to resolve the problem by increasing it to ten seconds, perhaps more if you have a very long distance or slow connection. You can determine whether you are experiencing this more uncommon cause by using SHOW STATUS LIKE 'aborted_connections'. It will increase by one for each initial connection attempt that the server aborts. You may see “reading authorization packet” as part of the error message; if so, that also suggests that this is the solution that you need.

Try increasing connect_timeout in your my.cnf file

Another style:

MySQL: Lost connection to MySQL server at 'reading initial communication packet'

1. At some point, it was impossible for remote clients to connect to the MySQL server.

2. The client (some application on a Windows platform) gave a vague description like Connection unexpectedly terminated.

3. When remotely logging in with the MySQL client the following error appeared:

   ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0

On FreeBSD this happens because there was no match found in /etc/hosts.allow. Adding the following line before the line saying ALL:ALL fixes this:

mysqld: ALL: allow

On non-FreeBSD Unix systems, it is worth to check the files /etc/hosts.allow and /etc/hosts.deny. If you are restricting connections, make sure this line is in /etc/hosts.allow:

mysqld: ALL

or check if the host is listed in /etc/hosts.deny.

In Arch Linux, a similar line can be added to /etc/hosts.allow:

mysqld: ALL

回答2:

This is usually caused by an aborted connect. You can verify this by checking the status:

mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connects';

If this counter keeps increasing as you get the lost connections, that's a sign you're having a problem during connect.

One remedy that seems to work in many cases is to increase the timeout. A suggested value is 10 seconds:

mysql> SET GLOBAL connect_timeout = 10;

Another common cause of connect timeouts is the reverse-DNS lookup that is necessary when authenticating clients. It is recommended to run MySQL with the config variable in my.cnf:

[mysqld]
skip-name-resolve

This means that your GRANT statements need to be based on IP address rather than hostname.

---

I also found this report from 2012 at the f5.com site (now protected by login, but I got it through Google cache)

It is likely the proxy will not work unless you are running BIG-IP 11.1 and MySQL 5.1, which were the versions I tested against. The MySQL protocol has a habit of changing.

I suggest you contact F5 Support and confirm that you are using a supported combination of versions.

回答3:

My case was that the server didn't accept the connection from this IP. The server is a SQL server from Google Apps Engine, and you have to configure allowed remote hosts that can connect to the server.

Adding the (new) host to the GAE admin page solved the issue.

回答4:

I've struggled a lot with this error. Tried every single answer I found on the internet.

In the end, I've connected my computer to my cell phone's hotspot and everything worked. I turned out that my company's internet was blocking the connection with MySQL.

This is not a complete solution, but maybe someone faces the same problem. It worths to check the connection.

回答5:

I use several mysql connections (connecting to different sets of databases) in localhost.

This happened to me after I shut my computer down and mysql was not properly shutdown. After starting my machine I was able to successfully connect to multiple db connections except one (I used this a lot before my machine shutdown). As per the instructions in this posts I doubled connect_timeout but I was not able to connect to that one database connection.

I restarted my machine and i can successfully connect now. This will help you unblock yourself but it'd be great if it can be fixed without restarting the machine.

Another concern is: connection_timeout seemed to me delay related problem but I was getting the error immediately in localhost when there is no network in the equation.

回答6:

I solved this by stopping mysql several times.

$ 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

All good from here. I suspect mysql had been started more than once.

回答7:

Another possibility can be connection reset from the TCP wrappers (/etc/hosts.deny and /etc/hosts.allow). Just check what is coming in from the telnet to port 3306 - if it is nothing, then there is something is in the middle preventing communication from happening.

回答8:

I have a mac but would assume all linux are the same for this part...

In my case I got this:

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

I ran this:

sudo killall mysqld

And then started the mysql again through mysqlworkbench although in your case it might be like this:

mysql.server start

*sidenote: I tried running mysql.server stop and got this Shutting down MySQL .... SUCCESS! but after running ps aux | grep mysql I saw that it hasn't really shut down...

回答9:

In my case, it happened when there were a lot of connection to the MySQL server (15,000 connections) and the free memory was about 120M . After I added more memory to the server, the error was gone.

回答10:

If you get this when using DevDesktop - just restart DevDesktop!

回答11:

I got both errors: mostly reading initial communication packet and reading authorization packet one time. It seems random, but sometimes I was able to establish a connection after reboots, but after some time the error creeped back.

Avoiding the 5GHz WiFi in the client seems to have fixed the issue. That's what worked for me (server was always connected to 2.4GHz).

I tried everything from server versions, odbc connector versions, firewall settings, installing some windows update (and then uninstalling them), some of the answers posted here, etc... lost my entire sleep time for today. Super tired day awaits me.