一个由MySQL安全插件引发的生产问题
本文最后更新于 2024-07-07,文章内容可能已经过时。
一、背景
生产环境下遇到一个问题,有数据库节点的连接数略高,触发了连接数告警。登录上查看后,发现实际业务压力不大。查看processlist发现有大量状态为“Waiting in connection_control plugin”的等待连接。
mysql> select ID,HOST,DB,COMMAND,TIME,STATE,INFO from information_schema.PROCESSLIST where STATE='Waiting in connection_control plugin';
该状态的连接总数达到338个
mysql> select COUNT(*) from information_schema.PROCESSLIST where STATE='Waiting in connection_control plugin';
应该是Connection-Control Plugins起作用了,先在测试环境模拟一下。
二、模拟测试
2.1、安装
该 Connection-Control Plugins
插件默认未启用,需要自行安装
mysql> INSTALL PLUGIN CONNECTION_CONTROL SONAME 'connection_control.so';
Query OK, 0 rows affected (0.40 sec)
mysql> INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME 'connection_control.so';
Query OK, 0 rows affected (0.01 sec)
确认下SQL插件是否安装
mysql> select PLUGIN_NAME, PLUGIN_STATUS from INFORMATION_SCHEMA.PLUGINS where PLUGIN_NAME like 'connection%';
+------------------------------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+------------------------------------------+---------------+
| CONNECTION_CONTROL | ACTIVE |
| CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS | ACTIVE |
+------------------------------------------+---------------+
2 rows in set (0.00 sec)
2.2、参数释疑
mysql> show variables like "connection_control%";
+-------------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------------+------------+
| connection_control_failed_connections_threshold | 3 |
| connection_control_max_connection_delay | 2147483647 |
| connection_control_min_connection_delay | 1000 |
+-------------------------------------------------+------------+
3 rows in set (0.00 sec)
参数含义:
- connection_control_failed_connections_threshold:单个用户登录失败(由于密码错误引起)次数上限,默认3次
- connection_control_max_connection_delay:失败上限之后再次尝试登录前最大等待时间,单位ms
- connection_control_min_connection_delay:失败上限之后再次尝试登录前最小等待时间,单位ms
上述3个参数均可以利用 set global 的方式在线修改。
2.3、实验
尝试3次错误输入密码后,在第4次登录时会delay 1秒(由connection_control_min_connection_delay指定),同时Connection_control_delay_generated计数+1(若登录密码继续输入错误,则delay秒数与计数器继续增加。直到成功登录为止之后,此时delay清零
查看到登录失败的次数
mysql> show global status like "%conn%control%";
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| Connection_control_delay_generated | 1 |
+------------------------------------+-------+
1 row in set (0.00 sec)
开启多个连接,继续试错下去,此时可以看到进程中
mysql> select * from information_schema.PROCESSLIST where USER='root';
+----+-------------+-----------+------+---------+------+--------------------------------------+------+---------+-----------+---------------+
| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO | TIME_MS | ROWS_SENT | ROWS_EXAMINED |
+----+-------------+-----------+------+---------+------+--------------------------------------+------+---------+-----------+---------------+
| 54 | root | localhost | NULL | Connect | 2 | Waiting in connection_control plugin | NULL | 2485 | 0 | 0 |
| 52 | root | localhost | NULL | Connect | 7 | Waiting in connection_control plugin | NULL | 7038 | 0 | 0 |
| 53 | root | localhost | NULL | Connect | 4 | Waiting in connection_control plugin | NULL | 4591 | 0 | 0 |
+----+-------------+-----------+------+---------+------+--------------------------------------+------+---------+-----------+---------------+
3 rows in set (0.00 sec)
这时,我们就回到了一开始提出的生产环境下遇到的问题。
三、解决生产问题
由于问题连接过多,逐个 kill
掉显然不太现实
因此,我采用拼接SQL 的方式,批量 kill
根据STATE状态为Waiting in connection_control plugin' 从information_schema.PROCESSLIST表中检索出 ID
,再本地文本中拼接出SQL ,再批量 kill
mysql> select ID from information_schema.PROCESSLIST where Command='Connect' and STATE='Waiting in connection_control plugin';
检索结果如下
再在文件编辑器中,利用查找替换功能,
将 “ |” 替换为 ";"
再将 “|” 替换为 “kill”
拼接的SQL 效果如下:
执行SQL 文件, 连接数告警 消失,问题暂时解决
四、事后分析
后续排查确认是zabbix agent 的一个监控脚本 ,数据库地址 配置的问题,导致存在这样的现象,Waiting in connection_control plugin
补充:
- 卸载MySQL安全插件:Connection-Control Plugins
- 注意查看my.cnf 中 是否也定义了此参数
mysql> UNINSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS;
mysql> UNINSTALL PLUGIN CONNECTION_CONTROL;
- 感谢你赐予我前进的力量