纸上得来终觉浅，绝知此事多宕机...记录一下自己很蠢的一次故障处理过程。
上周的时候，一个刚上线的系统又开始反映登不上了，因为最近这个系统也老是出现这个问题，开发也一直在找问题中，所以也没太在意。于是登上操作系统，mysql -uroot -p登录数据库，然后就一直没反应，登不上...
交代一下，mysql是装在mysql用户下的，装的时候虽然对数据库参数有进行调优，但是操作系统层面没做调整，所以mysql用户的最大文件打开数限制为默认的1024，用ulimit -n可以查询。然后我在用mysql的root账号登录数据库的时候也是在mysql这个系统用户下登录的，然后看了下当时服务器的负载，cpu和内存这些都很正常，但是存在大量应用到数据库的连接。
到这儿问题应该就很清楚了，系统用户mysql文件打开数可能达到了最大限制，当然不能打开更多的连接。
然而当时我并没有想到这一点，我想到的不是换个系统用户登录，不是停掉应用，而是重启数据库。。。而且这个数据库跑的不只这一个业务，虽然也都不是什么重要的业务。。。
于是我就准备重启数据库，仍然是在mysql用户下执行mysqladmin -uroot -p shutdown。毫无疑问，这肯定也是没有反应的，道理跟前面root账号连不上数据库是一样的，ctrl+C后有以下报错
|
1
2
|
^Cmysqladmin: connect to server at 'localhost' failederror: 'Lost connection to MySQL server at 'waiting for initial communication packet', system error: 4' |
然后我就做了个更蠢的操作，虽然想着可能会丢数据，杀掉了mysql进程。。。然后重启mysql，系统也就可用了。是真的很蠢，做完之后马上就想起有多种更好的处理方法，却选择了最蠢的一种。
今天再登上数据库看的时候，发现有几个参数跟我配置文件里写的不一样，比如max_connections、table_open_cache等，都是设置的默认值，看了下上次启动日志，确实也有告警
|
1
2
3
|
2019-03-15T08:14:03.038750Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 12010)2019-03-15T08:14:03.038911Z 0 [Warning] Changed limits: max_connections: 214 (requested 2000)2019-03-15T08:14:03.038916Z 0 [Warning] Changed limits: table_open_cache: 400 (requested 5000) |
很明显，mysql根据参数设置计算了实例需要打开的最大文件数超过了当前系统用户的最大限制，于是没有使用该参数而使用了默认值。当然启动起来数据库也是可用的，启起来后也可以手动把设置参数
|
1
2
|
set global max_connections=2000;set global table_open_cache=5000; |
只不过就很有可能出现我之前出现的问题了，也就是数据库连接数并没有达到max_connections的限制，用户仍然连接不上。需要说明的是，正常情况下就算连接数满了，mysql仍然会为root用户保留一个连接，也就是root用户是可以登录数据库查看问题的。
要解决也很简单，增大操作系统用户mysql的限制值就行了，在配置文件/etc/security/limits.conf后面加上新的限制值就行了。
|
1
2
|
mysql soft nofile 32768mysql hard nofile 65535 |
以上所述是小编给大家介绍的mysql 系统用户最大文件打开数限制详解整合，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对服务器之家网站的支持！
原文链接：https://www.cnblogs.com/yy-7777/p/10552701.html
