mongodb - ReplicaSet 上的 RS102 MongoDB

Question

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

出于测试目的，我使用 GridFS 编写了一个脚本来填充我的数据库，最多约 1.5 亿行照片。我的照片大约 15KB。 (对于小文件使用 gridfs 应该不是问题吧？!)

几个小时后，大约有 5000 万行，但是我在日志中有这条消息:

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. 停止失败的mongod
2. 删除dbpath中的所有数据(包括子目录)
3. 重新启动它，它会自动重新同步

按照说明进行操作 here .

在您的情况下发生的事情是您的辅助节点已经过时，即它们的 oplog 和主节点上的 oplog 没有共同点。看这个document ，详细说明了各种状态。对主要成员的写入必须复制到辅助成员，并且您的辅助成员无法跟上，直到它们最终变得陈旧。您需要考虑调整 oplog 的大小.

关于 oplog 大小，这取决于您随时间插入/更新了多少数据。我会选择一个允许您使用数小时甚至数天的操作日志的大小。

此外，我不确定您运行的是哪个操作系统。但是，对于 64 位 Linux、Solaris 和 FreeBSD 系统，MongoDB 会将可用磁盘空间的 5% 分配给 oplog。如果此数量小于 1 GB，则 MongoDB 将分配 1 GB 的空间。对于 64 位 OS X 系统，MongoDB 为 oplog 分配了 183 MB 的空间，对于 32 位系统，MongoDB 为 oplog 分配了大约 48 MB 的空间。

记录有多大？您想要多少？这取决于此数据插入是典型的还是异常的，您只是在测试。

例如，对于 1KB 的文档，以每秒 2000 个文档的速度计算，这将为您每分钟净赚 120MB，而您的 5GB oplog 将持续约 40 分钟。这意味着，如果辅助节点离线 40 分钟或落后超过 40 分钟，那么您就过时了，必须进行完全重新同步。

我建议阅读 Replica Set Internals 文档 here .你的副本集中有 4 个成员，这是不推荐的。 voting election (of primary) process 应该是奇数，因此您需要添加一个仲裁器、另一个辅助设备或删除您的一个辅助设备。

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