Question

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

出于测试目的，我编写了一个脚本，使用GridFS将我的数据库填充到大约1.5亿行照片。我的照片约为15KB。（对于小文件使用gridfs应该不会有问题吗？！）

几个小时后，大约有五千万行，但我在日志中收到了此消息：

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台服务器“DOWN”，我应该如何进行修复（比删除数据更好，重新同步哪些需要多长时间，但是会有效）？

特别是： 这是因为脚本过于暴力吗？这意味着它几乎从未在生产中发生过？

Answer 1

您无需修复，只需执行完全重新同步即可。

在中学，你可以：

停止失败的mongod
删除dbpath中的所有数据（包括子目录）
重启它，它会自动重新同步

按照说明here。

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

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

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

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

例如，对于1KB的文档，每秒2000个文档，这将使您每分钟120MB，并且您的5GB oplog将持续约40分钟。这意味着如果辅助服务器在40分钟内离线或落后的时间超过40分钟，那么您就会过时并且必须进行完全重新同步。

我建议您阅读副本集内部文档here。您的副本集中有4个成员，不建议这样做。您应该为voting election (of primary) process设置一个奇数，因此您需要添加仲裁者，另一个辅助人员或删除其中一个辅助人员。

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

ReplicaSet上的RS102 MongoDB

1 个答案: