MongoDB secondary节点出现recovering状态

MongoDB做了replica sets之后,secondary节点出现recovering状态

在一次mongo集群挂掉后，重启，发现有一台服务器的mongo节点一直处于recovering状态，不能变为secondary或者primary。

查询官方文档后，找到解决方案，在此记录。

出现原因

备份节点的工作原理过程可以大致描述为，备份节点定期轮询主节点上的数据操作，然后对自己的数据副本进行这些操作，从而保证跟主节点的数据同步。
至于主节点上的所有数据库状态改变的操作，都会存放在一张特定的系统表中。备份节点则是根据这些数据进行自己的数据更新。

上面提到的数据库状态改变的操作，称为oplog（operation log，主节点操作记录）。oplog存储在local数据库的"oplog.rs"表中。副本集中备份节点异步的从主节点同步oplog，然后重新执行它记录的操作，以此达到了数据同步的作用。
关于oplog有几个注意的地方：

• oplog只记录改变数据库状态的操作
• 存储在oplog中的操作并不是和主节点执行的操作完全一样，例如"$inc"操作就会转化为"$set"操作
• oplog存储在固定集合中(capped collection)，当oplog的数量超过oplogSize，新的操作就会覆盖旧的操作

数据同步

在副本集中，有两种数据同步方式：

• initial sync（初始化）：这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复，或者向副本集中添加新的成员的时候，默认的，副本集中的节点会从离它最近的节点复制oplog来同步数据，这个最近的节点可以是primary也可以是拥有最新oplog副本的secondary节点。
• 该操作一般会重新初始化备份节点，开销较大
• replication（复制）：在初始化后这个操作会一直持续的进行着,以保持各个secondary节点之间的数据同步。

initial sync

当遇到上面例子中无法同步的问题时，只能使用以下两种方式进行initial sync了

• 第一种方式就是停止该节点，然后删除目录中的文件，重新启动该节点。这样，这个节点就会执行initial sync
  注意：通过这种方式，sync的时间是根据数据量大小的，如果数据量过大，sync时间就会很长
  同时会有很多网络传输，可能会影响其他节点的工作
• 第二种方式，停止该节点，然后删除目录中的文件，找一个比较新的节点，然后把该节点目录中的文件拷贝到要sync的节点目录中