RS102 MongoDB on ReplicaSet

Question

我已经设置了一个包含4个服务器的副本集。

为了测试目的，我使用GridFS编写了一个脚本来填充我的数据库至约150百万行照片。我的照片大约在15KB左右。 （？！这不应该是使用GridFS的对小文件有问题）

后数小时后，有大约5000万行，但我在日志此消息：

replSet error RS102 too stale to catch up, at least from 192.168.0.1:27017 

这里是复制集状态：

rs.status(); 
{ 
"set" : "rsdb", 
"date" : ISODate("2012-07-18T09:00:48Z"), 
"myState" : 1, 
"members" : [ 
    { 
     "_id" : 0, 
     "name" : "192.168.0.1:27017", 
     "health" : 1, 
     "state" : 1, 
     "stateStr" : "PRIMARY", 
     "optime" : { 
      "t" : 1342601552000, 
      "i" : 245 
     }, 
     "optimeDate" : ISODate("2012-07-18T08:52:32Z"), 
     "self" : true 
    }, 
    { 
     "_id" : 1, 
     "name" : "192.168.0.2:27018", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 64770, 
     "optime" : { 
      "t" : 1342539026000, 
      "i" : 5188 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:30:26Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    }, 
    { 
     "_id" : 2, 
     "name" : "192.168.0.3:27019", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 64735, 
     "optime" : { 
      "t" : 1342539026000, 
      "i" : 5188 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:30:26Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    }, 
    { 
     "_id" : 3, 
     "name" : "192.168.0.4:27020", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 65075, 
     "optime" : { 
      "t" : 1342539085000, 
      "i" : 3838 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:31:25Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:46Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    } 
], 
"ok" : 1 

设定仍然接受DATAS，但我有我的3个服务器“DOWN”我应该如何着手修理（更好不是删除DATAS和重新同步WH呃会过时，但会起作用）？

特别是： 这是因为太剧烈的脚本？这意味着它在生产中几乎从未发生过？

Answer 1

您不需要修复，只需执行完整的重新同步。

在次级，您可以：

1. 停止失败的mongod
2. 删除DBPATH（包括子目录）
3. 重启的所有数据，它会自动重新同步自身

按照说明here。

你的情况发生了什么事情，你的辅助变得陈旧了，即他们的oplog和主要oplog没有共同点。看看这个document，它详细介绍了各种状态。对主要成员的写入必须被复制到辅助节点，并且你的辅助节点不能跟上，直到它们最终失效。你需要考虑调整你的oplog。

关于oplog大小，取决于您插入/更新的数据量。我会选择一个大小，允许你几个小时甚至几天的oplog。

此外，我不确定您正在运行哪个操作系统。但是，对于64位Linux，Solaris和FreeBSD系统，MongoDB会将5％的可用磁盘空间分配给oplog。如果这个数量小于千兆字节，那么MongoDB将分配1千兆字节的空间。对于64位OS X系统，MongoDB为oplog和32位系统分配183兆字节的空间，MongoDB为oplog分配大约48兆字节的空间。

记录有多大，你想要多少？这取决于数据插入是否是典型的或者仅仅是测试的异常。

例如，对于1KB的文档，每秒处理2000个文档，这会使您每分钟处理120MB，并且您的5GB oplog将持续大约40分钟。这意味着，如果次要服务器在40分钟内脱机或落后多于此时间，则表明您已经陈旧，必须进行完全重新同步。

我推荐阅读Replica Set Internals文件here。您的副本集中有4个成员，这是不推荐的。您应该为voting election (of primary) process设置一个奇数，所以您需要添加一个仲裁器，另一个辅助器或删除其中一个辅助器。

最后，这里是关于RS administration的详细文档。