今天,在某个演示环境中,我们的产品经历过整个机房断电后,出现了mongodb二进制文件损坏,以下是故障的分析记录过程:

1.在客户处支撑的同事发现整个机房断电再恢复后,3个mongodb复制集中,有1个主机上的mongodb服务状态报错

2.登录后台发现复制集中每个mongodb主机上,mongod进程都在

3.在服务状态好着的mongodb主机上,通过mongo登录数据库,查询复制集状态,发现复制集状态正常,1个primary+2个secondary,并且optimeDate时间一致.

这个时候我就很好奇了,按说mongodb复制集状态都正常着,不至于再出现其中1个节点上查询mongodb服务状态报错的情况了.

登录报错的主机上,通过mongo登录数据库,这时候,很诡异的事来了,终端上直接报错:"Bus error",很奇怪啊,我这还是第一次遇到mongo命令报这个错.感觉自己是不是遇到什么诡异事件了.然后执行mongo --version,一样的报错"Bus error".

这个时候,不知道怎么的,就忽然想起很久远时候的一个灵异事件了----最初做产品的兄弟遇到了这样一个问题:同一个mongodb rpm包,安装好之后,在某个主机上安装的mongod的二进制文件的md5和预期的不一样了.

然后就使用md5sum 去算这个提示"Bus error"的mongo,结果终端上直接报错"Input/Output error"了,但是使用md5sum去算同目录下另外几个mongodb相关的文件就没报错.

到这个时候,我意识到操作系统可能出了啥故障了.喊了操作系统组的同事看了下,----刚开始还以为是只有mongo这个二进制文件被人或者其他服务给修改了,但是,在我们准备把这个损坏的mongo二进制文件备份到另外一个目录的时候,终端上继续报错了"cp *** Input/Output error".

至此,操作系统组的同事确定:可能因为机房断电,主机操作系统中出现文件系统损坏了.

为了验证这个猜测,接下来,我们重启了服务器(好在这个时候还没上业务),然后重新启动过程中,提示信息中果然有根分区和另外一块分区的文件系统损坏的提示.按照提示信息进入了维护模式,使用fsck -y /dev/分区名 修复之后,再正常启动,操作系统就不再报错了.

最后,通过重装mongodb的rpm包,将mongodb的二进制文件报错处理掉了.至此,mongodb二进制文件损坏问题修复完成.

我之前一直以为linux文件系统很稳定,经历过这次事之后,发现原来之前的都是误解,稳定只是一个相对的概念.

记一次故障处理----主机异常关闭后mongodb二进制文件损坏