诡异现象

近期在k8s环境部署MySQL数据库从库，发现只要是从库连接主节点的实例，主节点一两分钟内就会crash一次。如果从库不连接主库则不会故障。

排查思路

1. pod 的内存和MySQL的内存是否冲突
2. MySQL最大连接数是否设置合理
3. MySQL版本bug
4. 对比其他没有问题的库，查找不一样参数

柳暗花明

经过排查，发现有人遇到类似的情况，是由于MySQL的域名解析导致的实例崩溃。原因是链接MySQL实例的pod 的名称过长，同时MySQL开启了DNS lookup，在连接时由于dns 解析导致的MySQLcrash。按照网上方法，修改skip_name_resolve 之后，问题解决。
链接：https://www.digitalocean.com/community/questions/mysql-crashes-when-my-pods-connects

内容延申

MySQL的name resolve（DNS lookup）

MySQL的域名解析时连接认证中的一环，开启的时候（skip_name_resolve=off）当客户端连接mysql 的时候，mysql 会对客户端的IP进行dns 解析，然后判断是否在grant table 指定的域名域中，由于mysql的授权既能针对域名，又能针对ip，所以此功能略显鸡肋。

注意:
如果禁用此功能需要保证在授权表中，包含所有可访问MySQL的ip，因为域名授权会被skip参数忽略。
MySQL日志中如下所示：

2020-03-01T07:10:43.710214Z 0 [Warning] 'user' entry 'root@worker-node1' ignored in --skip-name-resolve mode.
2020-03-01T07:10:43.710237Z 0 [Warning] 'user' entry 'root@worker-node2' ignored in --skip-name-resolve mode.
2020-03-01T07:10:43.710248Z 0 [Warning] 'user' entry 'root@worker-node3' ignored in --skip-name-resolve mode. ```

skip_name_resolve的优势

1. 解决延迟问题
2. 连接数大的时候开启DNS lookup会造成连接时间过长，造成不必要的时间消费

为何会造成实例重启

搜索发现为MySQL 5.7 的bug ，在5.7.27 以上版本已修复。