mongodb副本集中其中一个节点宕机无法重启的问题

2-8日我还在家中的时候，被告知mongodb副本集中其中一个从节点因未知原因宕机，然后暂时负责代管的同事无论如何就是启动不起来。

当时mongodb的日志信息是这样的：

实际上这里这么长一串最重要的信息应该是在后边几行：

据我的理解，这里大概的意思是指明了副本集节点最后的正常时间，说现在启动这个节点需要回滚，但是回滚的时候存在矛盾冲突，然后无法正常启动。

当时我正有事忙着，电脑又不在手边上，仅凭这几行提示我也无法确定究竟是什么原因，又想到一台从节点暂时宕机对整个系统没有太大影响，于是就让他先看了一下机器内存，结果发现内存实在低的不像话，才三四十兆。

但是这台机只有一个程序在运行，就是mongodb数据库，数据库没运行的情况下内存这样低绝对有问题。

于是我初步推断大概是内存的问题导致数据缺失，而后同步出现矛盾冲突，便提出了重启机器的要求，由于是生产环境要走一系列流程，因此直到昨晚机器才完成重启。

机器重启后，内存果然恢复正常，但是重启数据库的时候还是一样的问题。

既如此，那就只能翻出2-8当天出问题时的日志再看看了，于是发现之前的日志上方还有有这样一些内容：

一番查询后，有说是副本集选举问题的，有说是网络防火墙问题的，但并没有找到解决办法，于是只好自己想了一个解决办法，强制把宕机节点删除掉再新建一个全新的数据库作为节点加进来。

在这个过程中我有所犹豫，因为我并不确定在加入了用户验证和使用了keyfile文件的时候能否成功解决我的问题，不知道是否会出现用户验证不通过而导致无法加入节点的问题。

不过好在，实在想不出更好办法的情况下，我用rs.remove删除宕机节点，再用rs.add添加新节点后，一切数据都正常同步了，包括之前的用户名密码和系统所需的主要数据。

而且原本以为一千多万的数据可能需要耗费很久时间同步，结果并没有用多久这个节点就从startup2变成了secondary。

本以为会有一番周折，结果有些出乎意料的解决了，但是并没有找到问题出现的根本原因，因此详细记录这一过程，以便其他人查看的同时，也算是记录下一个问题，寻求能想到相关原因的朋友给予解答。