MongoDB 集群节点 RECOVERYING 状态解决办法

问题描述

公司项目搭建的mongodb集群，前几天发现有好几次访问异常。
一个分片的primary节点服务总是down掉，后来经过仔细排查，发现原来是该集群内的副本节点状态一直是”RECOVERYING”的。

日志如下：

原因分析

主要信息：
We are too stale to use 10.171.30.102:27021 as a sync source. Blacklisting this sync source because our last fetched timestamp: 59cffaca:4df is before their earliest timestamp: 59f4f4fd:ae for 1min until: 2017-11-09T21:11:18.330+0800

大意是本节点的最后时间戳比同步目标最早的时间戳还要早一分钟，我们这个节点太”陈旧”了；也就是由于一些原因太久没有进行同步数据操作，而导致其他节点的数据操作日志已经覆盖，所以本节点被认为是太陈旧了，无法从其他节点同步数据。

---

Our newest OpTime : { ts: Timestamp 1506802378000|1247, t: 11 }
Earliest OpTime available is { ts: Timestamp 1509225725000|174, t: 12 }
我们最新的操作日志时间：{ ts: Timestamp 1506802378000|1247, t: 11 }，于我们有效的最早的操作日志的时间是： { ts: Timestamp 1509225725000|174, t: 12 }

解决方案

See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember

---

通过阅读上面给出的链接文章内容，发现解决方案也不难：
主要一点记住，同步数据时候一定选在系统访问量最低的时间段进行。这样防止数据大量更新滞后，另一方面由于同步数据比较耗费资源的，降低系统down的风险。

第一种：自动同步(推荐)

1.停掉”stale”节点mongo服务。
2.清空该节点下的数据文件夹下的数据文件。
3.启动mongo服务。

第二种：从其他成员同步数据

将其他节点的数据文件拷贝到”stale”节点数据文件夹下。