记一次故障处理----主机异常关闭后mongodb二进制文件损坏
2016-12-12 00:01
295 查看
今天,在某个演示环境中,我们的产品经历过整个机房断电后,出现了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文件系统很稳定,经历过这次事之后,发现原来之前的都是误解,稳定只是一个相对的概念.
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文件系统很稳定,经历过这次事之后,发现原来之前的都是误解,稳定只是一个相对的概念.
相关文章推荐
- 当前在线日志损坏,无所有数据文件备份。异常关闭(实验系列)
- redo文件损坏,异常问题处理二则
- Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- QTP打开文件、保存文件时提示异常出错强制关闭程序处理办法
- Oracle - Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- 记录一次mac+idea+springmvc开发的applicationContext.xml读取文件找不到异常处理
- 关于UDP消息服务抛出“远程主机强迫关闭了一个现有的连接”的异常说明及处理方法
- 关于UDP消息服务抛出“远程主机强迫关闭了一个现有的连接”的异常说明及处理方法
- Oracle表空间文件损坏导致的数据库异常关闭并启动失败问题的解决方法
- Oracle系统紧急故障处理(数据文件、日志文件以及表空间损坏的处理)
- 记一次从库主机断电重启后同步故障处理
- 一次RAC共享磁盘映射问题导致RAC异常重启的故障处理过程
- oracle数据文件被误删或损坏故障处理
- !!!易控INSPEC组态软件开发小结——-一次工程文件损坏和处理经过
- 控制文件resetlogs方式创建,有活动在线日志,当前在线日志损坏,并异常关闭(实验系列)
- Linux:记一次异常断电导致的系统无法正常启动(文件系统故障)
- C++中的文件输入/输出(5):二进制文件的处理
- mysqlbinlog:用于处理二进制日志文件的实用工具
- 注册表整理系统技巧和故障处理修改文件右键菜单