mysql open_files_limit值更改无效
数据库出现问题显示too many files，导致数据库无法访问。出现这个问题，肯定是文件描述符打开过大了。查下数据库的结果为：
show variables like "%file%";
open_files_limit | 1024
查看系统ulimit的值：
[root@localhost ~]# ulimit -n 65535
系统的值是正确的。然后修改/etc/my.cnf配置文件，添加
open_files_limit=65535
然后重启mysql
systemctl restart mysql
再次查看mysql的值：
show variables like "%file%";
open_files_limit | 1024
还是这样，不生效。什么问题。郁闷了。经过不断的尝试，突然发现不使用系统自带的命令重启的话
[root@localhost system]# mysqld_safe --defaults-file=/etc/my.cnf &
这样启动的话，设置的值生效了。莫非脚本里面ulimit值不认为是65535.
找了个办法进行验证操作。
因为mysql启动肯定会调用mysqld_safe脚本文件，就在这个文件里面进行验证。
759 echo `ulimit -n `>> /tmp/1.txt #新加的调试内容 760 ulimit -n 65535 #新加的调试内容 761 echo `ulimit -n `>> /tmp/1.txt #新加的调试内容 762 763 cmd="`mysqld_ld_preload_text`$NOHUP_NICENESS" 764 765 for i in "$ledir/$MYSQLD" "--basedir=$MY_BASEDIR_VERSION" 766 "--datadir=$DATADIR" "--plugin-dir=$plugin_dir" "$USER_OPTION"
使用
[root@localhost ~]# tailf /tmp/1.txt
重启mysql,观看文件的数据变化.
1024 1024
尽然一直是1024，使用命令设置过也没有生效。
这到底怎么回事。
自己写个简单的测试脚本测试ulimit -n的值显示的就是系统设定的，为什么在mysql的启动里面就无法调用系统的呢。
经过查找资料。有说如果是守护进程启动的shell的话用ulimit -n设置的话就不会生效。也不知道对不对。我就暂且认为这个mysql的启动是一个守护进程调用的这个脚本文件。那我该怎么办呢。
无意中看到了redis的启动文件的设定。
[root@mysql redis.service.d]# cat /etc/systemd/system/redis.service.d/limit.conf # If you need to change max open file limit # for example, when you change maxclient in configuration # you can change the LimitNOFILE value below # see "man systemd.exec" for information [Service] LimitNOFILE=10240
这个就是设定limit_files数的，就依葫芦画瓢，在mysql启动配置文件加入了。
[root@localhost system]# cat -n /etc/systemd/system/mysql.service 26[Service] 27User=mysql 28Group=mysql 29# Execute pre and post scripts as root 30 31LimitNOFILE=65535 #新加入的内容
然后继续
[root@localhost ~]# tailf /tmp/1.txt
重启mysql,观看文件变化
65535 65535
尽然生效了。进入msyql，查询结果：
mysql> show variables like "%file%"; | open_files_limit | 65535
成功生效。
说明这个参数起了作用，在脚本的的ulimit -n设定其实是没有用处的。
总结：个人感觉系统自带的启动程序的方式确实方便，但是会让用户不知道真正调用的启动文件的工作方式。遇到问题的话最好就是找源码启动文件进行调试，会找到很多自己意想不到的东西。还有官方写的shell脚本看着真他妈的复杂。
本文出自 “你猜我是谁” 博客，请务必保留此出处http://whhhj.blog.51cto.com/9289395/1787028