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台服务器"DOWN"我应该如何进行修复(比删除数据更好并重新同步哪些需要很长时间,但是会有效)？

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

Answer 1

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

在辅助中,您可以:

1. 停止失败的mongod
2. 删除dbpath中的所有数据(包括子目录)
3. 重启它,它会自动重新同步

按照此处的说明操作.

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

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

另外,我不确定你在运行哪个O/S. 但是,对于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分钟,那么您就会过时并且必须进行完全重新同步.

我建议您在此处阅读Replica Set Internals文档.您的副本集中有4个成员,不建议这样做.投票选举(主要)过程应该有一个奇数,因此您需要添加仲裁者,另一个辅助人员或删除其中一个辅助人员.

最后,这是关于RS管理的详细文档.