记一次服务器宕机恢复过程
Jan 12, 2017
1 minute read

服务器介绍

这是一台数据库服务器,运行MySQL和Mongodb。用于平台用户系统,统计系统的数据存储。

宕机重启

收到网页无法访问报警后,打开网页发现超时,排查后发现db服务器已经无法ssh登录。只能选择关机重启。控制台选择关机后失败,只能强制关机。强制关机成功后能ssh登录。

网页恢复,访问缓慢

重启后数据库运行正常,网页打开正常。但半数机会需等待20多秒才显示。服务器高Load,有很高的iowait。怀疑底层磁盘问题。这台服务器使用了500G的云磁盘挂载。联系美团云后回复磁盘没问题。查看mongodb日志发现慢操作写入等待时间有20多秒,导致读操作被阻塞。

iowait高问题成为事情的关键。

了解iowait(wa)

iowait 表示在一个采样周期内有百分之几的时间属于以下情况:CPU空闲、并且有仍未完成的I/O请求。IO特指文件IO,不包括网络IOSO解释。所以高iowait必然和磁盘有关。

查找高io进程

用vmstat命令看到的情况是,服务器在两种忙的状态下切换,一种是高sy,一种是高wa。于是用iotop查看实时写入速度。发现大部分时间都没有请求,只是突然有mysql和mongo的请求。

这时我以为IO写入不忙,但后来发现问题不是这样。用vmstat可以发现突发的请求bo数可以到达13000左右,换算成数据量是42MB。这种bo出现往往导致wa持续高几十秒。其实iotop的实时统计并不准确,可能采集数据是io写发起的数据量,而大的io鞋发起后磁盘真实的写入速度没有准确显示,所以造成我认为磁盘io不忙的错觉。

然后用iotop的a键查看累积写入,发现mysql写入非常高。原来异常重启后的mysql会检查所有表,导致了特别高的IO。于是重启mysql,中断了检查操作,问题解决。

最后

内存,IO,CPU是系统最重要的几大运维内容。这次事件一方面说明磁盘IO的排查首先应该查找高IO进程,另一方面也提醒了关键数据库要有主从备份的重要性。


Back to posts