求助：MySQL每日自动重启后启动失败，无法找到指定init_file

最近我在处理一个挺棘手的MySQL问题，折腾好几天了，细节如下：

• 每晚MySQL都会自行重启（至今没找到触发原因），多数时候重启后直接启动失败中止，少数运气好的时候能正常恢复运行
• 每天UTC时间8到9点左右，它会自动重启两次，但第二次铁定失败，报错是找不到路径为/var/lib/mysql/.-.work.XNDQaWRXUvLyEEJx的init_file
• 目前只能靠写脚本每天早上手动重启MySQL顶一下

我整理的排查方向和建议 #

1. 先扒MySQL错误日志

首先得去看MySQL的错误日志，一般在/var/log/mysql/error.log或者/var/lib/mysql/[你的主机名].err这个位置，重点盯着UTC 8-9点前后的日志：

• 找找第一次自动重启的根因，比如是不是系统OOM（内存不足）杀了进程？还是配置出问题？磁盘满了？权限不对？
• 仔细看第二次启动时关于init_file的完整报错上下文，看看那个临时文件是不是第一次重启时生成了，但没被正常清理掉

2. 查系统层面的触发点

• OOM Killer排查：去系统日志/var/log/syslog或者/var/log/messages里搜mysql和out of memory，确认是不是内存不够，系统强制杀了MySQL进程，然后触发了自动重启
• 定时任务检查：看看系统的定时任务，比如执行crontab -l，还有查看/etc/cron.d/目录下的文件，有没有夜间跑的脚本或者任务会碰MySQL、改配置，或者动/var/lib/mysql目录里的东西
• 磁盘和权限检查：确认/var/lib/mysql的权限是mysql:mysql，磁盘空间够不够，有没有IO异常导致临时文件读不出来或者创建失败

3. 专门针对那个奇怪的临时文件排查

• 那个. -.work.*格式的文件看起来像是MySQL某些操作生成的临时工作文件，大概率是第一次重启时没清理干净，第二次启动时MySQL还想读它，结果文件没了或者访问不了
• 可以在夜间重启时段前，用inotifywait -m /var/lib/mysql命令监控这个目录的文件变化，追踪这个临时文件是怎么生成又怎么消失的
• 检查MySQL的配置文件（my.cnf或者my.ini）里有没有init_file相关的配置，会不会是配置写错了指向了这个临时路径

4. 临时优化现有脚本

在彻底找到原因之前，可以先把现有脚本改得靠谱点：

• 把脚本执行时间提前到UTC 8点之前，抢在MySQL第二次失败重启前手动启动
• 在脚本里加一步：先删掉/var/lib/mysql/.-.work.*这类临时文件，再重启MySQL，避免启动时找不到文件的错误

内容的提问来源于stack exchange，提问作者jndinh