mysql open_files_limit值更改无效
数据库出现问题显示too many files，导致数据库无法访问。出现这个问题，肯定是文件描述符打开过大了。查下数据库的结果为：show variables like "%file%"; open_files_limit | 1024 查看系统ulimit的值：
# ulimit -n
65535
系统的值是正确的。然后修改/etc/my.cnf配置文件，添加
open_files_limit=65535 然后重启mysql
systemctl restart mysql 再次查看mysql的值：
show variables like "%file%"; open_files_limit | 1024 还是这样，不生效。什么问题。郁闷了。经过不断的尝试，突然发现不使用系统自带的命令重启的话
# 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"
使用
# tailf /tmp/1.txt 重启mysql,观看文件的数据变化.
1024
1024
尽然一直是1024，使用命令设置过也没有生效。
这到底怎么回事。
自己写个简单的测试脚本测试ulimit -n的值显示的就是系统设定的，为什么在mysql的启动里面就无法调用系统的呢。
经过查找资料。有说如果是守护进程启动的shell的话用ulimit -n设置的话就不会生效。也不知道对不对。我就暂且认为这个mysql的启动是一个守护进程调用的这个脚本文件。那我该怎么办呢。
无意中看到了redis的启动文件的设定。
# 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
LimitNOFILE=10240
这个就是设定limit_files数的，就依葫芦画瓢，在mysql启动配置文件加入了。
# cat -n /etc/systemd/system/mysql.service
26
27User=mysql
28Group=mysql
29# Execute pre and post scripts as root
30
31LimitNOFILE=65535 #新加入的内容
然后继续
# tailf /tmp/1.txt 重启mysql,观看文件变化
65535
65535
尽然生效了。进入msyql，查询结果：
mysql> show variables like "%file%";
| open_files_limit | 65535
成功生效。
说明这个参数起了作用，在脚本的的ulimit -n设定其实是没有用处的。
总结：个人感觉系统自带的启动程序的方式确实方便，但是会让用户不知道真正调用的启动文件的工作方式。遇到问题的话最好就是找源码启动文件进行调试，会找到很多自己意想不到的东西。还有官方写的shell脚本看着真他妈的复杂。
页:
[1]