MYSQL  连接数被篡改到底为那般_java

说这个问题是在是惭愧, 到底为什么惭愧结尾说, 事情是MYSQL 8.011 的一些机器的max_connections 经常被改为214, 而明明我们的设置的是2000的最大连接数, 但过一段时间就会被改为214. 

这实际上问题来源于文件的open_files_limit , mysql 在读取数据的时候是需要打开文件的, 打开文件是需要获取LINUX 系统中的句柄的。

在LINUX 系统中单个进程打开的文件数是有限制的,而MYSQL 的MYSQLD 是通过一个工作进程进行工作的,单个进程的文件打开数就必须被进行扩大.

我们的系统出现的问题就是由于LINUX的单个进程打开文件限制没有打开,造成的这个问题.

在LINUX 中单个进程能够打开的最大文件句柄数量(socket连接也算在里面),系统默认值1024.通过 ulimit -n  可以看到当前的进程可以使用的最大打开的文件数.

MYSQL  连接数被篡改到底为那般_linux_02

实际上在 /etc/security/limits.conf 文件中需要添加如下的内容

MYSQL  连接数被篡改到底为那般_mysql_03

同时可以进入MYSQL 数据库中,查看open_files_limit  这个值应与 limits.conf 文件中的值一致.

MYSQL  连接数被篡改到底为那般_java_04

同时在修改后需要重启MYSQL的服务才能让修改后的参数生效.

另外如果这个值是错误是LINUX 默认的值,会产生 mysql的最大连接数无论你修改了 max_connections 后,还会变为 214这个值,影响整体系统的连接和运行.

MYSQL  连接数被篡改到底为那般_python_05

另外我们也说说打开一张表的过程, 例如select  一张表, 我们首先需要建立一个table_share 的对象,在里面包含了 table_definition_cache, 同时里面包含相关的表的定义, 同时我们还要创建表的对象,如果表的对象在 table_open_cache中就不需要在提取,直接使用.否则还要打开文件提取.
同时已经load dict table 对象, 如果dictionary cache 中存在dict_table 则可以直接引用, 否则还的需要读取系统表空间中关于innodb 表的定义. 最后会创建file_tablespace , fil_node 对象在打开 ibd 文件读取数据. 

以上都是需要打开文件的,打开文件就与我们上面的LINUX 的 打开文件的数量的限制有关.

MYSQL  连接数被篡改到底为那般_java_06

而max_connections 的值,与文件打开之间是有关系的所以设置的max_connections 会在系统启动的时候被改变,根据你LINUX 可以打开的文件数. 最后与你设置的值不同.

问题找到了,剩下的就是改,然后重启数据库,另外一定不能有经验的理论,我们的错误在于之前提供给我们的LINUX 系统一直这些值都是设置的,所有我们就习以为常的不检测这块的问题,导致系统上线后,发生这样的问题.

MYSQL  连接数被篡改到底为那般_数据库_07