导读
某个环境的mysql做shutdown的时候,一直刷日志
代码语言：txt复制waiting for page_cleaner to finish flushing of buffer pool刷了几个小时了, 虽然cpu有使用(50%单线程), 但没得实际IO产生, 怀疑是假死了.
因为执行了shutdown命令, 所以也没办法登录数据库查看了.
注: 环境不方便截图和拍照,故使用文字描述, 文中出现的截图均为本地模拟的, 方便展示
处理过程
这种案例网上还是很多的, 有说是时区问题的, 但数据库时区和操作系统是一致的, 且未在启动之后修改过时间和时区. 理论上不是时区问题. 但我们还是死马当活马医. 试一下.
代码语言：shell复制# 查看当前时区
timedatectl status
# 返回显示为 -4:00 (纽约的...)
# 故修改时区为东八区
timedatectl set-timezone Asia/Shanghai
# mysql.error日志还是刷一样的日志, 但日志的时区未发生变化(还是-4:00)
# 于是又将时间往后推了2小时
date -s "`date --date ' 2 hours' ' %Y%m%d %H:%M:%S'`"
# 还是一直刷waiting for page_cleaner to finish flushing of buffer pool
# 所以确实不是时区问题. 记得将时区和时间修改回去哈既然排除了时区问题, 又在网上看到说是RTC问题,
故尝试关闭RTC (真实环境那台是已经关闭了的, 但我还是又跑了一遍)
代码语言：shell复制timedatectl set-local-rtc 0
当然没有效果啦.
只能祭出最后的武器了: 相信 mysql的recover能力.
于是kill -9干掉mysql (好孩子不要模仿)
kill -9 $(ps -o ppid= -p `pidof mysqld`)
kill -9 `pidof mysqld`然后重新启动Mysqld进程, 查看mysql.error
实际环境的Doing recovery是非常多的, 后面应用日志还有进度.
看来是成功恢复了呢. 登录数据库验证也是正常的.
总结
虽然处理了问题, 但原因还没分析. 因为不好复现,所以就不好分析. 出现问题的时候, 又没得那么多时间去分析, 只能先处理问题. 所以平时打好基础是非常重要的.
如果实在不行, 还可以根据之前解析的ibd,redo,undo,binlog来自己做恢复
