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

来源:互联网 发布:软件测试规范标准 编辑:程序博客网 时间:2024/06/05 14:17

4down voteaccepted

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 tothe MySQL server.

  2. The client (some application on a Windows platform) gave a vaguedescription likeConnection unexpectedly terminated.

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

    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 sayingALL: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


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:

貌似有效的设置方法

1. mysql> SET GLOBAL connect_timeout = 30;
2.
在文件my.ini  或者my.cnf中添加或更改一个参数:connect_timeout=30

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 itthrough 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.



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.




0 0