RS102 MongoDB on ReplicaSet

Question

我用4台服务器建立了一个副本集。

为了测试目的，我用GridFS编写了一个脚本来填充我的数据库，多达1.5亿行照片。我的照片在15 My左右。(对于小文件使用gridfs不应该是个问题吗?!)

几个小时后，大约有5000万行，但是I在日志中得到了这条消息：

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

，下面是replSet状态:

 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

该集仍然接受数据，但由于我有我的3台服务器“停机”，我应该如何继续进行修复(好于删除数据和重新同步将需要很长时间，但会工作)？

，特别是:，这是因为脚本太暴力了吗？意味着在生产中几乎从来没有发生过这种事？

Answer 1

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

在中学阶段，你可以：

1. 阻止失败的蒙神
2. 删除dbpath中的所有数据(包括子目录)
3. 重新启动它，它将自动重新同步它自己。

按照指示here。

在你的例子中所发生的是，你的第二阶段已经变得陈旧，也就是说，在它们的oplog中没有共同的点，而在主舞台上的oplog没有共同点。看看这个document，它详细介绍了各种状态。对主成员的写入必须复制到次要文件中，直到它们最终失效，您的次要文件才能跟上。您需要考虑调整oplog的大小。

关于oplog大小，这取决于您在一段时间内插入/更新了多少数据。我会选择一个尺寸，可以让你许多小时甚至几天的oplog。

另外，我不知道你在运行哪个O/S。然而，对于64位Linux、Solaris和FreeBSD系统，MongoDB将把5%的可用磁盘空间分配给oplog。如果这个数量小于一个千兆字节，那么MongoDB将分配1G的空间。对于64位OS系统，MongoDB将183兆字节的空间分配给oplog，对于32位系统，MongoDB为oplog分配大约48兆字节的空间。

唱片有多大?你想要多少？这取决于这个数据插入是典型的还是不正常的，而您只是在测试。

例如，对于1KB的文档，每秒有2000个文档，这将使您每分钟净赚120 1KB，而5GB的oplog将持续大约40分钟。这意味着，如果第二次离线40分钟或落后超过这一点，那么你是过时的，必须做一个完整的重新整合。

我建议阅读副本集内部文档here。复制集中有4个成员，这是不建议的。对于voting election (of primary) process，您应该有一个奇数，所以您要么需要添加仲裁器，要么需要添加另一个辅助程序，或者删除一个次要代码。

最后，这里有一个关于RS administration的详细文档。