最近生产环境日志同步过程中，应用程序最近遇到一个MySQL连接的问题，远程连接proxy时遇到“ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet', system error: 0”错误，如下所示：

查看了Mysql源代码：

生产环境mysql参数配置:

一、traceroute 部署

怀疑跟网络有关系，写个脚本挂着，看看异常场景的时候，测试网络情况：

二、测试环境复现问题

简单的测试，先gdb夯住mysql 然后你的程序去连接mysql 如果很快报read initial packet啥的错误 也是11或者115错误 多半就是客户端的问题。

gdb上去 端口还是listen的 完成tcp建链是tcp协议栈完成的 mysqld夯住不受影响

应用程序是先连接上db后，再gdb mysqld，还是反回来。

目前我是先gdb mysqld，应用程序再连接db，出现如上图场景，客户端也挂住了5分钟。

应用程序端：

数据库服务端：

我抓的网络报文，最后以mysql端发RST包结束，然后持续的重连，我怀疑是迁移机-F5-proxy这块网络上有问题，路由寻址F5时间太长（一般情况下都要992毫秒），数据库的connect_timeout设置是10秒， 是不是网络转发有延时，客户端收心跳包超时，报了reading authorization packet的错，正在部署监控看看异常的时候的寻址时间。

生产异常连接包：

报错时点异常包：

正常连接包：

数据库异常连接查询：show status like 'aborted%'

网上给的招：

这个里面提到两点∶一是增大connect_timeout，二是添加skip-name-resolve

上一张图片可以看出Aborted_clients的值比较大

是不是可以尝试增大 max_allowed_packet 的值?

先别往数据库上分析。proxy和mysql建链错误往前端返的错误是统一的都是

Can't connect to MySQL server.错误号 13205 sqlstate HY000

最终以这个异常包作为分析入口项：

客户端超时退出断链。

这条链路有可能是kill query，proxy日志。

这5秒内很奇怪，解释不通。

这张图应该是建链后proxy给你发了挑战码 正常你应该拿这个挑战码加密你的用户名和口令再发给proxy 但5秒也没有发送 从你的第一个红箭头看 你收到了 到没有处理。

这个是有可能的，这个连接在建立的时候，其他连接正在执行SQL重试，重试一次休眠1秒。我们连接之间是异步事件驱动的。

另外一个奇怪的地方是 倒数第三行看起来是你10秒后又上送proxy鉴权信息包 看起来是你阻塞在读取上 fin包唤醒了你的程序 5秒后处理数据。

你的轮循是5秒 超时是5秒 这里两次包的间隔也是5秒 是不是有什么逻辑在里面？

这个确实不是initial packet的事情 挑战码已经发了 挑战码就是你提到的initial packet这应该是read aurhorizarion的问题。

数据库发fin是因为程序控制了建链必须5秒内完成用户鉴权 防止客户端恶意连接 因此 5秒后的fin就是因为你没有给鉴权信息包。

所以你要解决的是：收到proxy给你的第一个包后 5秒内必须发出鉴权信息。

如果5秒内不给发鉴权信息，就不能建链成功，那么理论上会彻底断掉才是吧。

而且报这种异常的sql，重试100次都失败。

我怀疑重试也是5秒没发鉴权包。你们可以再分析下其他的包。

这个包和日志都能对应上的 分析没问题的。

但是这条链路 kill query了 是为何，还得看看？

通过代码分析，它是这样的：

正常迁移程序初始化的时候与F5会建立200个连接（连接编号定义为1到200）并且设置自动重连标志，

程序逻辑（基于libevent事件库）

1.1 建立socket连接，三次握手（应用程序调api）

1.2 发送登陆包（应用程序调api）

1.3 连接db成功

1.4 发包

1.5 收包

正常情况下是没有问题的。但在发包过程中，间隔几小时就出现批量kill query获取Kill 用户会话等事件（假设把连接50～100都kill掉了），客户端马上就捕捉到了，

1. mysql底层会将50号连接重连（建立socket连接，三次握手）

2. 应用程序发现50号连接，sql执行结果异常，报了lost connection to mysql server during query类似的错（非readding authorization packet），将该sql标识重做。

3. 程序休眠一秒

4.将第50号连接绑定的sql将会重新执行（异步事件）

这时候50号连接任务暂时结束，其他连接重复上述逻辑运转。

当“第50号连接绑定的sql将会重新执行”的异步事件隔了一段时间（期间被其他连接抢占，用时超过5秒）有响应后，再去发登录包（这时mysql 服务端已经发了fin包），然后收包，这时候就报 readding authorization packet。

这个50号连接就进入死循环，所以出现重复100次都失败。 能重复几次成功的取决于SQL重做异步事件的响应。

当应用程序进入idle状态时，会重新对每个连接设定检查事件，异常的连接就会重连，并发送登录包，恢复正常200个连接状态。

我们应用程序首次连接时，登录包都是去调api的，见代码：

但是我们设置了重连机制，

异常断链应该是客户端主动连接才对，这时候应该是Mysql客户端主动送的登陆包吧？

答案：不是，支持内部判断链路断了，重新发起流程。和正常非重连过程一样的。

问题来源是先有了lost connection to mysql server during query，然后SQL重试，就出现了readding authorization packet。

困惑是：重连是谁做的~，怎么做的，我们对异常lost connect这种场景没有做重连的逻辑处理

这个简单：执行语句之前，MYSQL*对象中，如果已经断链，你的mysql_query() 内部会自动重新登录一次。

是这个api里面，我理解“内部会自动重新登录”，应该会串行建立socket连接和发送登陆包吧，但为啥会有间隔时间，这个间隔时间和我们应该逻辑有挂钩~

取决于你什么时候调用了它。

1、黑1:出现了lost connection to mysql server during query的日志

2、黑2是程序判断要重做的日志

3、黑3是调用mysql_query()重新执行

以上三处时间范围在2秒以内

4、黑4是间隔38秒后，再去收包，就报了readding authorization packet

我理解是，在黑3调用的时候，就应该重新连接（建立socket连接和发送登陆包），重新执行SQL了，黑4就不应该报错了，您看法呢？

再分析：

不对，应该是黑3调用 执行，内部走重连，但并没有完成建链，5秒后链路被proxy终止，再过33秒也就是38秒时，你程序报错了。这么推测才是合理的。昨天的包也显示：5秒后你收到了fin，然后你又发了包（异常1），显然会得到rst包，你再次读取鉴权结果（异常2）。其实你在异常1这个点，就应该EPIPE了，搞不清楚你的程序为啥还继续往下走。在异常2，你就会得到readding authorization packet。

应用逻辑往下走是符合的，部分SQL异常失败是要一致重试的，对connect异常我们依赖内部重连，所以没有做EPIPE处理。

作为一般的错误提示，断链你可以看到多种：

1，lost connection to mysql server

2，lost connecttion to mysql server during query

3，read initial package

4，read authorization packet

1，是你空闲时候，在执行语句前，如果没有自动重连就是这样的

2，是发出语句，等待结果时断链

3，是连接mysql server时，proxy给你的第一个包没有读到tcp断链

4，是连接mysql server时，读取proxy的鉴权响应失败

如果你用jdbc，还有两种：

1，the last packet successfully sent xxx millseconds ago

2，Transaction unresolution 啥的

其中1对应了上一个“2，是发出语句，等待结果时断链”

2是commit或者rollback之前断链，这个是特有的提示。

这里的自动登陆还需要给发鉴权信息么？

会的，否则你就可以设置自动重连。proxy根本就不知道你是不是重连的。重连也是换了链路的。

退一步说，即便proxy知道，如果重连可以省去鉴权步骤，这是一个安全缺陷。意味着只要你的客户端不重启，后续server端改密对你无效。

我的改动点：

1、出现了lost connection to mysql server during query场景时

2、添加一个异步超时事件（超时一秒）

3、等超时结束后，调用回调含函数，再次mysql_query()，就执行成功了。

我很好奇，都异步事件驱动了，为啥要sleep呢？

以前是：

1、出现了lost connection to mysql server during query场景时

2、sleep一秒

3、再次mysql_query()，报reading autherorization packet

4、再sleep一秒

依次循环。

mysql_query也是异步事件api。

最终结论：数据库没问题、网络没问题、是客户端程序有问题，由于sleep堵塞了鉴权包的发送，导致reading autherorization packet 报错。

异步api中不应该含有sleep阻塞机制，导致回调阻塞，改成定时事件，问题解决。