被我误解的max_connect_errors

2017-08-06 12655

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

RDS MySQL Serverless 基础系列，0.5-2RCU 50GB

云数据库 RDS MySQL，集群系列 2核4GB

云数据库 RDS PostgreSQL，集群系列 2核4GB

简介： 实为吾之愚见,望诸君酌之!闻过则喜，与君共勉

实为吾之愚见,望诸君酌之!闻过则喜，与君共勉

第一节什么是 `max_connect_errors`

一开始接触这个参数的时候，感觉他和max_connections的含义差不多，字面意思简单明了，这个参数的含义是最大连接错误数，翻翻mysql的文档中的解释是If more than this many successive connection requests from a host are interrupted without a successful connection, the server blocks that host from further connections,大意是：如果mysql服务器连续接收到了来自于同一个主机的请求，且这些连续的请求全部都没有成功的建立连接就被断开了，当这些连续的请求的累计值大于 max_connect_errors的设定值时，mysql服务器就会阻止这台主机后续的所有请求。”without a successful connection”那太好办了，故意输错密码不就行了，并且网上搜索了下该参数的说明，大量的文章充斥着” 防止暴力破解密码”的内容，于是兴高采烈的去做了测试。以下测试基于自建的mysql（非rds for mysql），由于rds for mysql无法直接设置set global，设置时需要在"rds控制台-参数这里"里进行设置：https://help.aliyun.com/document_detail/26179.html?spm=5176.11065259.1996646101.searchclickresult.44156de7pLffcV

第二节测试`max_connect_errors`

1,创建账号：

b984add34b00bee3d562d96d25fa07ccb8145a7a

2,设置max_connect_errors为3：

4776ffe81ccffb4de40ab1daacd8220f5be822d2

3，故意输错密码3次，第四次使用正确密码登录进行验证：

f376ff16b8b381fcf71f4b79893db1fd11246e51

4,结论是第四次依然可以登录，即密码不对（认证失败）不属于” ”without a successful connection””的范畴，网上的” 防止暴力破解密码”也不成立了。

6cd06be24be4b24af171a2710d5f5e790f977cb3

第三节继续分析 `max_connect_errors`

再继续看文档，发现还有以下说明：

You can unblock blocked hosts by flushing the host cache. To do so, issue a FLUSH HOSTS statement or execute a mysqladmin flush-hosts command.

大意是：

当你遇到主机被阻止的时候，你可以清空host cache来解决，具体的清空方法是执行flush hosts或者在mysql服务器的shell里执行 mysqladmin flush-hosts操作

既然清空host cache可以解决主机被阻止访问的问题，那应该与host cache有些关系，看看host cache的介绍可能会有些眉目，关于host cache，文档解释如下：

The MySQL server maintains a host cache in memory that contains information about clients: IP address, host name, and error information. The server uses this cache for nonlocal TCP connections. It does not use the cache for TCP connections established using a loopback interface address (127.0.0.1 or ::1), or for connections established using a Unix socket file, named pipe, or shared memory.

大意是：

Mysql服务器会在内存里管理一个host cache，host cache里保存了一些客户端的ip地址，主机名，以及这个客户端在与server建立连接时遇到的一些错误信息，host cache对不是本地的TCP连接才有效，所以host cache对127.0.0.1 或者::1是无效的，并且对于Unix socket file、named pipe以及 shared memory方式建立的连接也是无效的。并且通过了解，host cache的内容可以通过performance_schema.host_cache来查看，通过performance_schema.host_cache表里的几个列的描述信息，对之前的测试不成立的原因有些了解了，部分相关列如下：

· IP

The IP address of the client that connected to the server, expressed as a string.

连接到mysql server的主机的连接地址

· HOST

The resolved DNS host name for that client IP, or NULL if the name is unknown.

通过dns解析IP地址获取到的该IP地址对应的mysql client的主机名

· SUM_CONNECT_ERRORS

The number of connection errors that are deemed “blocking” (assessed against the max_connect_errors system variable). Only protocol handshake errors are counted, and only for hosts that passed validation (HOST_VALIDATED = YES).

· COUNT_HANDSHAKE_ERRORS

The number of errors detected at the wire protocol level.

通过SUM_CONNECT_ERRORS(连接错误计数)描述，重点是红色部分：只计算协议握手过程的错误(Only protocol handshake errors are counted),也就是说max_connect_errors 可能记录的是协议(不确定是tcp协议还是应用协议，通过抓包以及COUNT_HANDSHAKE_ERRORS的” the wire protocol level”说明可能是指应用协议)的握手过程中出现的错误，也就是可以说网络不好(无法顺利握手)会导致该问题。