mongodb--解决error RS102 too stale to catch up

在插入中，2 个 SECONDARY 全部状态为 Recovering，错误信息：”errmsg” : “error RS102 too stale to catch up”。并且在插入7000W左右文档时（并不表示在 7000W 数据后才发生），发现插入速度变的很不稳定：

 该如何处理？

幸运的是官方文档 Resyncing a Very Stale Replica Set Member 告诉了问题所在，OPLOG（operation log 的简称）。OPLOG 是用于 Replica Set的 PRIMARY 和 SECONDARY 之间同步数据的系统 COLLECTION。OPLOG 的数据大小是有峰值的，64 位机器默认为 ~19G（19616.9029296875MB），通过 db.printReplicationInfo() 可以查看到： （这里19G，和我测试的有出入，configured oplog size:   11230.146875MB）

我们的只有100M

shard1:PRIMARY>  db.printReplicationInfo()   
configured oplog size:   100MB
log length start to end: 1989secs (0.55hrs)
oplog first event time:  Tue Nov 15 2011 15:37:48 GMT+0800 (CST)
oplog last event time:   Tue Nov 15 2011 16:10:57 GMT+0800 (CST)
now:                     Tue Nov 15 2011 16:48:23 GMT+0800 (CST)

原因在启动脚本里加入了  -oplogSize 100

修改启动脚本重新启动就ok 。改成10000了

  由于 OPLOG 的大小是有限制的，所以 SECONDARY 的同步可能无法更上 PRIMARY 插入的速度。这时候当我们查看 rs.status() 状态的时候就会出现 “error RS102 too stale to catch up” 的错误。

If this occurs, the slave will start giving error messages about needing to be resynced. It can’t catch up to the master from the oplog anymore: it might miss operations between the last oplog entry it has and the master’s oldest oplog entry. It needs a full resync at this point.

解决办法：
Resyncing a Very Stale Replica Set Member 给出了当我们遇到 Error RS102 错误时，该做些什么事。还可以根据 Halted Replication 中的 Increasing the OpLog Size ，调整 OPLOG 的大小为适当的值。

This indicates that you’re adding data to the database at a rate of 524MB/hr. If an initial clone takes 10 hours, then the oplog should be at least 5240MB, so something closer to 8GB would make for a safe bet.

最后在数据继续插入的情况下，使用 rs.remove() 移除 2 个SECONDARY 后，插入又恢复了原来的速度。剩下就是插完后再重新同步 SECONDARY。

 一些解释

Replica Set status状态说明：

0 Starting up, phase 1
1 Primary
2 Secondary
3 Recovering
4 Fatal error
5 Starting up, phase 2
6 Unknown state
7 Arbiter
8 Down

health 健康度：

0 Server is down
1 Server is up