我理解了一些mysql的默认变量配置,这些默认配置在高压力的生产环境中被证明是有问题的,这些默认配置在网络震荡或一些其他情况下会产生一些让人非常讨厌的问题。
max_connect_errors
如果客户端连接mysql的时候有错误发生,服务器将会放弃等待在(connect_timeout)秒之后,并且会增加错误连接主机的计数。然后直到这个值达到(max_connect_errors)https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_connect_errors,然后客户端的ip会被锁定禁止连接,直到你执行 FLUSH HOST命令。更糟糕的情况是,如果你的网络不稳定，并且你一直不重启mysql服务器，这个错误会随着时间积累 直至在某个深夜给你造成无限麻烦。
阅读Mysql官网的文章(Host 'host name' is blocked)https://dev.mysql.com/doc/refman/5.7/en/blocked-host.html。不幸的是他们没有办法全完彻底的避免这种情况。这是这个值为0也不能避免这种情况。比较现实的解决方案是设置一个比较大的值 (max_connect_errors=1844674407370954751),并且时不时的运行一下FLUSH HOSTS命令。
connect_timeout
这个值和上面的问题相关.在网络拥堵的情况下(包含客户端和服务器),有可能在几秒钟之后完成连接。但是这个参数的默认值是5秒,当你尝试忽略这个错误,上面的max_connect_errors 会给你造成麻烦。
为了避免这种情况,可以尝试设置connect_timeout的值在15到20 之间。也可以考虑设置thread_cache_size为一个非零值。如果服务器需要在很短的时间内新建大量连接,这样的配置会非常有帮助.
skip-name-resolve
默认情况下对进入服务器的连接mysql会进行反向查找.在这种情况下,不管你的基础服务有多好,对DNS服务总是会有干扰.mysql 的主机缓存是为了将这些查找降到最低.但是这种情况困扰了我8年了.当有错误发生的时候,我只能假设在主机缓存或者解析器之中存在bug.
我推荐在/etc/my.cnf增加skip-name-resolve完全跳过DNS查找。只使用ip地址或者被允许的ip段.这样从DNS得到应答将会十分缓慢,非常容易的达到connect_timeout值。我猜测有2到3个DNS服务配置,但是第一个DNS服务是不可用的.
slave_net_timeout
当主数据库和从数据库之间的网络连接出现故障,但是主从都没有检测到(比如防火墙或者路由的改变)。你一定希望从服务器在slave_net_timeout秒之后可以自己明白发生了某些错误.他会尝试再次连接主服务器,在丢失连接的地方重新上线.这样就太了不起。
然而,这个值很令人沮丧 3600秒 整整一个小时.
如果发生某些错误,难道会有人希望他的从服务器空转吗?我不认为有人希望这种情况发生.
我的建议是你,如果你在一个非常混乱的环境,你可以设置这个值为30秒。
文章翻译自mysql