这是前段时间本人经历的一次事情，数据库在晚上的2点多突然重启了，之后做了一次排查。
查看服务器的 messages 日志，那个时间段的记录也没有说明重启的原因，只记录了重启，排除服务器硬件问题。
之后查询mysql的日志mysqld.log，结果是在重启前的记录中出现报错
“too many open files” 提示打开文件过多，之后自动杀掉连接，重启服务。通过mysql的PID查看了mysql的最大打开文件数量： cat /proc/2173/limits
“Max open files 5000 5000 files”
通过命令查了目前的mysql打开文件打开数量
“lsof -p 2173 | wc -l”
4206
再想到晚上的2点有一个进行数据库备份的时间任务，问题可能就出现在这里，是不是这个限制导致了mysql重启，于是修改了mysql的最大打开文件数量，又涉及到另一个问题，发现在配置文件my.cnf中修改重启后，没有修改成功，遇事不决问百度，找到了问题，直接在mysql的启动脚本中进行修改
vim /usr/lib/systemd/system/mysqld.service
LimitNOFILE = 50000
重启后，成功修改了这个参数。
问题排除了。是否正确只能等待时间的验证，之后的2个星期无事发生，就在我认为应该没问题时，再次出现mysql重启。很心塞，只能再次重头查起。
这次出现了新的情况，mysql日志还是没有据体的重启原因记录，但是 messages 日志出现了这样的一段记录，
“Out of memory: Kill process 27978 (mysqld) score 636 or sacrifice child”
“Killed process 27978 (mysqld) total-vm:17000732kB, anon-rss:10331576kB, file-rss:0kB, shmem-rss:0kB”
“mysqld.service: main process exited, code=killed, status=9/KILL”
服务器内存不够，导致系统强制关闭了mysql，之后又自动重启，再对比上一次重启时间段的硬件监控记录，发现走向一模一样，不同的是，为何第一次 messages 日志没有报这个错，想不通，通宵加班，关闭所有涉及到的线上服务，把服务器的配置进行调整。至目前没有再出现mysql重启的情况。