[Azure] Azure负载均衡后的MySQL服务的一次TroubleShooting

工作中遇到的一个具体案例，拿出来简单分析一下，帮助大家了解一下MySQL相关的机制以及Azure平台负载均衡探测的原理。

客户环境是在Azure环境中搭建了一个内部负载均衡，后端有2台MySQL服务器做了主从。

从后端MySQL服务器上使用show processlist查看发现有一个168.63.129.16的IP进行MySQL的连接：

168.63.129.16这个IP实际上是平台对负载均衡探测的一个源IP，关于这个IP的作用可以参考：

https://blogs.msdn.microsoft.com/mast/2015/05/18/what-is-the-ip-address-168-63-129-16/

这里，比较奇怪的是，为什么这个负责探测的IP会与MySQL有交互呢？从原理上讲，负载均衡探测其实只需要确定TCP层面上端口联通就可以了。为了复现这个问题，我使用psping工具针对自己环境中的MySQL进行了端口测试，发现测试过程中并未生成unauthenticated user的process记录。

这就有点矛盾了，难道平台的IP真的和MySQL进程进行了应用层面的通信？进一步查看show processlist的命令说明了解到，这个命令可以查看当前MySQL那些线程正在运行（处理客户端的连接）。注意，这里是当前“正在运行”的process，如果一个process已经结束掉，那么就不应该显示在这里。

我们抓取平台168.63.129.16这个IP的探测过程，看到如下交互过程：

可以看到探测过程中，TCP三次握手完成后，后续168.63.129.16这个IP并没有发FIN来关闭连接。MySQL回复了"Server Greeting"消息之后，就在等待客户端进行认证了。

这就解释了为什么在show processlist中看到一个user为unauthenticated user的process了，MySQL收到一个客户端连接后，会起一个process来进行处理，当完成TCP连接后，这个process会给客户端发一个"Server Greeting"的消息等待客户端认证，由于平台探测的IP探测成功后后续不会发任何报文，所以这个MySQL的process会一直等待直到超时。

我们在抓包过程中还发现，达到一定次数后， MySQL process回复的消息是"Server Greeting Error 1129"：

进一步研究发现，这个与MySQL的自我防护机制有关（可以参考https://dev.mysql.com/doc/refman/5.5/en/blocked-host.html），MySQL定义了一个max_connect_errors的参数，当来自某个主机的连接出现意外终止的情况，就会累计connect error，当次数达到max_connect_errors定义的值（默认是10），MySQL就会block掉后续来自这个主机的请求。直到手动在MySQL中执行flush host。

那为什么psping没有办法复现问题呢？通过抓包看到，原因是psping探测是进行了完整的TCP 3次握手以及4次关闭连接的交互，因此MySQL对应的process收到TCP连接关闭的FIN后，就会结束，所以就不会显示在show processlist的结果当中了。

为了验证这个说法，我们写了一段简单的测试代码，代码中我们模拟进行1000次对MySQL端口的TCP连接，但是不调用Close方法关闭连接：

这时我们使用show processlist就能看到对应的process了：

因此，从上面实验结果可以看出，show processlist中出现168.63.129.16的IP并显示出unauthenticateduser的状态是由于探测的机制导致的。

额外说明一点，虽然MySQL的保护机制会block掉主机的SQL请求，但是这个block操作实际上是应用层面的。探测仅检测TCP层面的连通性，所以MySQL层面的block并不会影响探测本身成功与否。