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情况最佳。