故障分析 | 一次因为超过最大连接数的登陆限制

在测试某功能时，将 mysql 的最大连接数设置为 120，使用 sysbench 并发 200 插入数据，

上述错误是预期内的结果，因为 sysbench 的 200 个并发超过了 mysql 实例最大连接数；

随后，修改 sysbench 并发数为 100（小于最大连接数），再次插入数据，失败报错，并发数已经小于最大连接数了，为什么还报错，报错信息如下：

使用用户 test 单独登录实例，和上面报一样的错误：

之前正常的可以登录的用户 test，现在无法登录了。

起初，并不了解是什么原因造成的登录失败。查询官网文档了解到，是用户的错误的连接数超过了设置的最大值，这个最大值参数是 max_connect_errors。

解决方法很简单：执行 flush hosts

对于这个参数 max_connect_errors 之前并不了解，查阅网上文档提到，使用错误密码多次登录并不能模拟失败连接。尝试将此参数修改为 2，然后使用错误密码登录 2 次，后续再登录依然成功。看来使用错误密码确实不能模拟失败连接。

查阅官网文档了解到，在 Performance Schema 库表 host_cache 里会保存客户端的连接信息，其中字段 SUM_CONNECT_ERRORS 就是记录连接的错误次数，一旦 SUM_CONNECT_ERRORS 的值达到 max_connect_errors 设定的值，来自此客户端的连接就会被阻止。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).

可以看到这里指的是协议握手错误的次数。

下面使用 telnet 来模拟协议的握手错误次数：

配置最大错误连接错误数为 2，查看库表 Performance Schema.host_cache 的 SUM_CONNECT_ERRORS

这里 SUM_CONNECT_ERRORS 初始值为 0；

注：另一个参数 count_authentication_errors 是尝试错误密码登录的次数（这里的 2 就是之前尝试错误密码登录的次数）。

在客户端主机上使用 telnet 尝试 2 次端口探测，

再次查看该主机的 SUM_CONNECT_ERRORS 变成了 2。

此时问题复现，客户端登录实例被拒绝，因为错误连接次数达到了最大值 2。

回到本文最开始的问题，sysbench 并发 200 超过最大连接数 max_connections=120 时，

由于 max_connect_errors 的缺省值是 100，sysbench 并发 200 造成了 109 个错误连接，这就超过了错误连接的最大值，所以后续连接就报错了。

另外，为什么错误连接数 SUM_CONNECT_ERRORS 是 109，是因为此环境实例已经存在来自其他客户端的 11 个正常连接（通过 show processlist 可见），那么只剩下 120-11=109 个可用连接，sysbench 的 200 个并发，只接受了 109 个然后就协议握手失败，所以造成了 109 个错误连接。

官网提到错误连接指的是协议的握手失败次数，并未明确说明是哪个协议，是 TCP/IP 还是应用层的 MySQL 协议?

对于 TCP/IP 通信，首先是 TCP 协议的三次握手，因为客户端已经成功收到了服务端返回的报错：error 1040: Too many connections，TCP 握手已经成功完成了，所以这里的协议应该指的是 MySQL 的握手协议。

这里可以通过抓包来验证：

上述前三个包是完整的 TCP 握手协议包，已经完成了 TCP 的握手协议，后面 MySQL 协议服务端发送完 HandShake 信息之后双方就关闭了连接，客户端并未继续发送登录认证包，造成 MySQL 的协议握手失败。所以这里指的是 MySQL 的协议握手失败次数。

针对上面利用 telnet 来模拟协议握手失败的例子，由于 telnet 只是发送了 TCP 的握手包，并不会发送 MySQL 登录认证包，服务器端等待 10 秒（mysql 的 connect_timeout=10）就关闭了连接，所以才造成 MySQL 的握手失败。

主从复制理论上支持无穷大的从库个数，实际情况下，受服务器带宽和读写能力的影响

请参考mysql官方手册的建议：

理论上，通过使用单个主服务器/多从服务器设置，可以通过添加更多的从服务器来扩充系统，直到用完网络带宽，或者你的更新负载已经增长到主服务器不能处理的点。

在获得的收益开始吃平之前，为了确定可以有多少从服务器，以及可以将你的站点的性能提高多少，需要知道查询模式，并且要通过基准测试并根据经验确定一个典型的主服务器和从服务器中的读取（每秒钟读取量，或者max_reads）吞吐量和写（max_writes）吞吐量的关系。通过一个假设的带有复制的系统，本例给出了一个非常简单的计算结果。

假设系统负载包括10%的写和90%的读取，并且我们通过基准测试确定max_reads是1200 –2 × max_writes。换句话说，如果没有写 *** 作，系统每秒可以进行1,200次读取 *** 作，平均写 *** 作是平均读 *** 作所用时间的两倍，并且关系是线性的。我们假定主服务器和每个从服务器具有相同的性能，并且我们有一个主服务器和N个从服务器。那么，对于每个服务器（主服务器或从服务器），我们有：

reads = 1200 – 2 × writes

reads = 9 × writes / (N + 1) (读取是分离的, 但是写入所有服务器)

9 × writes / (N + 1) + 2 × writes = 1200

writes = 1200 / (2 + 9/(N+1))

最后的等式表明了N个从服务器的最大写 *** 作数，假设最大可能的读取速率是每分钟1,200次，读 *** 作与写 *** 作的比率是9。

如上分析可以得到下面的结论：

· 如果N = 0（这表明没有复制），系统每秒可以处理大约1200/11 = 109个写 *** 作。

· 如果N = 1，每秒得到184个写 *** 作。

· 如果N = 8，每秒得到400个写 *** 作。

· 如果N = 17，每秒得到480个写 *** 作。

用mysql 客户端能连上吗？1、ping服务器2、用mysql命令行连接“mysql -u 用户名 -p -h 服务器地址”。比如 "mysql -u root -p -h 192.168.1.12"注意mysql 8是比较新的客户端，不一定兼容php。建议用centos 或ubuntu预装的LAMP （linux+apache+mysql+php），那样配置工作量是最小的。还有一种情况，就是 php和mysql不在同一个服务器上，这时候要修改mysql配置/etc/my.cnf，将地址绑定到0.0.0.0，而不是127.0.0.1，同时用 "grant" SQL 命令允许外网访问。比如 ` grant all on test.* to root@'%' identified by 'mypassword' `， 这样root用户就可以从别的主机访问mysql

---