mysql Aborted connects值很大且增长很快,采用tcpdump+wireshark分析

     说明下我们机器情况,两台mycat下边挂载四台mysql,同时mycat的监控工具mycat eye与一台mycat部署在同一台机器上监控两个mycat的运行情况。
最近线上生产环境出现某一台mysql的Aborted connects过高的情况,但是mysql和mycat中错误日志中并没有任何错误出现,参考官方文档以及大神博客
      查询Aborted connects过高的原因:



      这里说的是集中常见情况会导致Aborted connects值上升,但是都是会有错误日志输出的,如果有错误日志此类问题句好分析了很多,日志中都会有哪类错误的详细信息,比如连接数满了,密码不对等等,这里虽然不可能但我还是逐一去分析了,

    1、首先就是用户不对,这里我们应用是能正常连接的且错误在mysql error中输出验证失败消息,但是就是不清楚为什么会有莫名的请求,还没拒绝,所以排除了密码不对,

    2、最大连接数满了也不对,

        show global status like 'Max_used_connections';

        查看下最大并发才一百多,最大连接数我们给的三千,/

    3、最后就是网络问题或者连接池问题,如果是此类问题会有业务连接失败的错误细爆出来,也没有,并且都是内部网络,一般出问题可能性相对较小


     但是都分析过了也都不可能,那要怎么办呢?这里我的做法:

    1、先把警告日志打开

    [mysqld]
    log-warnings=2

     重启mysql,观察Aborted connects正常后,查看mysql的error日志,发现果然有很多warning,


   2017-09-19 15:05:44 21516 [Warning] Aborted connection 2224044 to db: 'test254' user: 'testuser' host: '19.15.45.25' (Got an error reading communication packets)

    2、第一次想法就是google  Got an error reading communication packets  

     错误原因,但是很不幸,文章说的五花八门,说是max_allowed_packet太小,或者是超时导致,但是显然都不是这样的,因为我们使用了mycat中间件,下边挂载四台mysql
,如果是超时啊或者是
max_allowed_packet太小导致会四台机器都增高,而不是某一台增加。

     3、这里就到了关键时候,看mycat和mysql日志也没有进展并且Aborted connection 还在持续增大,只能通过抓包来查看网络包了,查看到底是从哪来的请求,请求的是什么内容别拒绝了,再生产机器上使用tcpdump抓包,这里说下使用的情况,因为Aborted connection持续增高说明请求一直在发,我们去dump几分钟网络包下来分析就行,如果您的不是一直发生您就要分析出现的规律子抓包,否则有可能抓不到错误包。

   [root@localhost ~]# tcpdump -i any  port 3306  -w snap.log
   tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
   ^C204 packets captured
   284 packets received by filter
   0 packets dropped by kernel

      由于linux上没有什么可以好的分析tcpdump结果的图形工具,这时候想到了win上的wireshark来分析结果,这里也是参考了几位前辈的文章 点击打开链接 点击打开链接  点击打开链接 

直接将抓取的snap.log文件用wireshark打开,并且ctrl+F搜索 Error 



     这里由于是生产的原因数据图我就不上了原始的了,希望理解,我找个被人在阿里云的测试机抓取下作为演示


    这里我们看到src和dst src就是从哪发出来的请求,dst就是发到哪个地址去,这里就看出来我们这个错误请求是从哪来的,确定后就好办了,接着看错误信息


  再看客户端给服务端发送的登录验证信息:


    这里大家看到的信息非常清晰用户什么,密码什么,请求的哪个库(正式包会有我这是测试),然后很清楚看出是要做什么。

     原来是找不到对用的数据库,这里也和前边没有报错对应起来了,如果是密码错误会直接报错但是这个是找不到对应的库,所以这是警告,突然想起来我们的mycat监控中也监控了数据库性能,所以会直接请求数据库,而其中数据库名称配错了导致的,所以问题查出来修改下就好了。

    总结;这里问题肯定是五花八门,每个都不一样,但是学会tcpdump和使用wireshark分析dump结果很重要,还可以有其他的分析工具例如percona的percona-tools,但是不是图形界面,习惯不看图形的也可以看,不过我觉得percona-tools最好的是用来分析dump出来的sql情况最佳。



猜你喜欢

转载自blog.csdn.net/u014180504/article/details/78060726