大家好,欢迎来到IT知识分享网。
最近生产环境日志同步过程中,应用程序最近遇到一个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阻塞机制,导致回调阻塞,改成定时事件,问题解决。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/168650.html