生产环境MySQL ERROR 2013 (HY000)错误分析

生产环境MySQL ERROR 2013 (HY000)错误分析最近生产环境日志同步过程中 应用程序最近遇到一个 MySQL 连接的问题 远程连接 proxy 时遇到 ERROR 2013 HY000 Lost connection to MySQL server at reading auth

大家好,欢迎来到IT知识分享网。

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

生产环境MySQL ERROR 2013 (HY000)错误分析

查看了Mysql源代码:

生产环境MySQL ERROR 2013 (HY000)错误分析

生产环境mysql参数配置:

生产环境MySQL ERROR 2013 (HY000)错误分析

一、traceroute 部署

生产环境MySQL ERROR 2013 (HY000)错误分析

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

生产环境MySQL ERROR 2013 (HY000)错误分析

二、测试环境复现问题

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

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

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

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

应用程序端:

生产环境MySQL ERROR 2013 (HY000)错误分析

数据库服务端:

生产环境MySQL ERROR 2013 (HY000)错误分析

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

生产异常连接包:

生产环境MySQL ERROR 2013 (HY000)错误分析

报错时点异常包:

生产环境MySQL ERROR 2013 (HY000)错误分析

正常连接包:

生产环境MySQL ERROR 2013 (HY000)错误分析

数据库异常连接查询:show status like ‘aborted%’

生产环境MySQL ERROR 2013 (HY000)错误分析

网上给的招:

生产环境MySQL ERROR 2013 (HY000)错误分析

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

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

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

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

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

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

生产环境MySQL ERROR 2013 (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 ERROR 2013 (HY000)错误分析

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

生产环境MySQL ERROR 2013 (HY000)错误分析

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

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

生产环境MySQL ERROR 2013 (HY000)错误分析

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

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

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

生产环境MySQL ERROR 2013 (HY000)错误分析

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

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

生产环境MySQL ERROR 2013 (HY000)错误分析

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阻塞机制,导致回调阻塞,改成定时事件,问题解决。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/168650.html

(0)
上一篇 2025-01-26 10:26
下一篇 2025-01-26 11:00

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信