|
her the error is permanent or transient. For permanent failures, the host name remains NULL and the validation flag is set to true. For transient failures, the host name and validation flag remain unchanged. (In this case, another DNS resolution attempt occurs the next time a client connects from this IP.)
MySQL Server检测HOST_VALIDATED的值，如果为FALSE，它会试图进行DNS解析，如果解析成功，它将更新HOST的值为主机名，并将HOST_VALIDATED值设为TRUE。如果没有解析成功，判断失败的原因是永久的还是临时的，如果是永久的，则HOST的值依旧为NULL，且将HOST_VALIDATED的值设置为TRUE，后续连接不再进行解析，如果该原因是临时的，则HOST_VALIDATED依旧为FALSE，后续连接会再次进行DNS解析。
-
If an error occurs while processing an incoming client connection from a given IP address, the server updates the corresponding error counters in the entry for that IP. For a description of the errors recorded, see Section 26.12.17.1, “The host_cache Table”.
如果在处理来自给定IP地址的传入客户端连接时发生错误，则服务器会更新该IP条目中的相应错误计数器。 有关记录的错误的说明，请参见第26.12.17.1节“host_cache表”。
这个案例里面，因为MySQL位于阿里云Kubernetes(K8s)中Docker容器里面，对公司内部的IP地址进行DNS解析确实会出现问题。我们在配置文件设置skip_name_resolve后，确实解决了这个问题。然后本来以为找到了原因的我，在本地两台机器上测试时发现（一台MySQL版本为5.6.41， 一台MySQL版本为5.6.23），即使两台服务器相互不能做DNS解析，如下截图所示，但是从192.168.27.180连接DB-Server时，并不会报这个错误。Why？ 即使我将connect_timeout调整为2，依然不会出现这个错误。看来MySQL的连接不像我们表面看的那样简单。还是相当复杂。只是目前的技术水平，还做不到进一步分析！
另外，在这个案例的测试过程中，发现skip_name_resolve为OFF的情况下，将connect_timeout设大，也不会出现这个错误
mysql> show variables like '%connect_timeout%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| connect_timeout | 10 |
+-----------------+-------+
1 row in set (0.01 sec)
mysql> set global connect_timeout=30;
Query OK, 0 rows affected (0.00 sec)
mysql>
然后从客户端连接MySQL数据库就成功了，如下所示，只是IP地址并不是客户端的IP地址，而是Port IP。
当然这种情况下Kubernetes(K8s)中Docker下MySQL并没有挂掉，反而当系统变量connect_timeout=10的情况下，如果没有开启系统变量skip_name_resolve，每次远程连接MySQL就会出现Kubernetes(K8s)中Docker下MySQL挂掉，重启的过程，所以极度怀疑是疑因为在连接过程，Docker下MySQL挂掉重启才出现这个错误。但是对K8s了解不多，涉及太广，没法进一步分析具体原因了。
|