MySQL连接控制插件相关了解

引言

MySQL 从 5.7.17 版本开始，提供连接控制插件 Connection Control Plugins^[1]。该插件可以在用户连续尝试失败后，增加服务器响应延迟，有效防止暴力破解攻击。‌

若使用不当，可能会导致以下问题：

• 连接数积压。例如，当监控系统使用不存在的用户频繁访问数据库时，失败连接尝试会占用连接资源。
• 数据库挂起。由于插件延迟机制的存在，无效连接无法快速释放，最终可能导致触发 too many connections 错误。

1. 问题背景及原因

1.1 场景描述

客户环境数据库在启用连接控制插件的情况下，监控系统使用了 igcam 不存在的用户进行数据库访问，该行为会导致 Connect 状态的连接大量积压，很快达到 max_connections
 上限，最终引起 too many connections 报错。

1.2 问题原因

当 Connection Control Plugins 启用时，插件会记录失败的连接尝试次数。在达到 connection_control_failed_connections_threshold
（默认为 3）后，插件会延迟创建新的连接。即使用户被删除，插件仍会记录失败尝试并延迟响应，进一步占用连接资源。

2. 复现场景及测试方法

2.1 安装连接控制插件

需要安装的插件分为 2 个部分：

• Connection_control：负责检查连接次数并增加响应延时。
• Connection_control_failed_login_attempts：记录失败登录尝试的详细信息。

执行下列命令安装连接控制插件：

INSTALL PLUGIN CONNECTION_CONTROL SONAME 'connection_control.so';
INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME 'connection_control.so';

通过 INFORMATION_SCHEMA.PLUGINS
 检查插件是否安装成功，PLUGIN_STATUS
 为 ACTIVE 表示插件安装成功。

SELECT PLUGIN_NAME, PLUGIN_STATUS from INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'connection%';

2.2 参数配置

插件的关键参数包括：

• connection_control_failed_connections_threshold：定义允许的连续失败连接次数。超过该阈值后，后续连接尝试将被延迟。默认值为3，表示当连接失败3次后启用连接控制，0 表示不开启。
• connection_control_min_connection_delay：最小响应延迟时间，单位是毫秒。默认 1000 毫秒，即 1 秒。
• connection_control_max_connection_delay：最大响应延迟时间，单位是毫秒。默认 2147483647 毫秒，约 24 天。

示例配置：

SET GLOBAL connection_control_failed_connections_threshold = 3;
SET GLOBAL connection_control_min_connection_delay = 1000;

-- 设置为 1 小时
SET GLOBAL connection_control_max_connection_delay = 3600000;  

2.3 效果测试

创建测试用户 monitor 并删除。

-- 1.新建测试用户
CREATEUSER monitor@'127.0.0.1'IDENTIFIEDBY'monitor';
GRANT PROCESS,REPLICATIONCLIENT,SELECTON *.* TO'monitor'@'127.0.0.1';

-- 2.使用测试用户连接数据库，确认可以正常访问
SELECTcurrent_user();

-- 3.删除用户
DROPUSER monitor@'127.0.0.1';

调整 max_connections
 为 5，以模拟连接数满的场景。

SET GLOBAL max_connections=5;

并发连接测试。使用多个客户端同时尝试以 monitor 用户连接数据库，观察连接延迟现象。

while true
do
 time mysql -umonitor -p'monitor' -h127.0.0.1 -P3306 2>/dev/null
done

验证测试结果。在使用正常账号访问数据库时，返回结果显示已达到最大连接数限制。

从 show processlist
 结果中可以看到 monitor 无效用户占用着连接，且 monitor 用户身份验证处于 waiting in connection_control plugin 的连接延迟状态。

2.4 延迟机制分析

通过以上测试发现，使用错误的账号访问数据库时，前三次连接失败后立即断开，第四次及后续连接开始出现延迟，且每次登录失败延迟会增加 1 秒钟时间。

以下信息如果为非零值，表示有某个客户端触发了延迟控制：

• 查看 connection_control_delay_generated
   状态变量信息，该变量记录了连接失败尝试增加响应延迟的次数。

• 查看 information_schema.connection_control_failed_login_attempts
  ，该表提供了每个帐号当前连续失败的连接尝试次数的信息。

2.5 插件中定义的延迟计算公式

delay_time = min_delay * (current_count + 1 - threshold)

其中：

• min_delayb：最小延迟时间，默认为 1000 毫秒。
• current_count：当前失败连接次数。
• threshold：失败连接次数阈值，默认为 3。

当前失败次数 current_count
 超过阈值 threshold
，或计数器异常（current_count < 0
），则触发延迟，且延迟时间随失败次数增加而递增。

2.6 计数器更新逻辑

在成功连接数据库后，计数器会重置为 0。此前因失败触发的延迟机制将不再影响此客户端，但失败连接尝试的延迟机制仍然生效，直到其再次达到阈值。

3. 总结及处理方法

3.1 问题总结

开启连接控制插件后，失败连接尝试会触发延迟机制，可能导致以下问题：

• 连接数积压，达到 max_connections
   上限。
• 数据库性能下降，影响正常用户连接。
• 默认配置下，失败连接尝试从第 4 次开始，每次延迟增加 1 秒。

3.2 异常处理

• 限制最大延迟时间，将 connection_control_max_connection_delay
   设置为较小值（如 1 小时），避免无效连接长期占用资源。

• 对于监控类的信息采集，限制并发连接数，把监控用户的连接资源做控制。例如：

CREATE USER 'monitor'@'127.0.0.1' WITH  MAX_USER_CONNECTIONS 10;

• 及时干预异常用户，发现密码被修改的用户或连接异常的用户，及时采取措施。

• 紧急情况，例如，会话连接数达到最大连接数限制，可以通过以下命令重置计数器并释放连接。

SET GLOBAL connection_control_failed_connections_threshold=0;