Question

我们使用node + mongodb为聊天模块实现了mongodb分片概念。

MongoDB Sharding Configuration
===============================
Shard1 = PRIMARY + SECONDARY + ARBITER
Shard2  = PRIMARY + SECONDARY + ARBITER
Config
Mongos

我们今天早上得到了详细信息。但我们不知道如何解决这个问题。

请告诉我们如何解决此问题。

“errmsg”：“回滚2错误findcommonpoint等待一段时间才重新尝试”

“errmsg”：“错误RS102过于陈旧无法赶上”

data2:PRIMARY> rs.status()
{
    "set" : "data2",
    "date" : ISODate("2012-07-27T04:30:29Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "50.52.108.16:20001",
            "health" : 1,
            "state" : 9,
            "stateStr" : "ROLLBACK",
            "uptime" : 322,
            "optime" : {
                "t" : 1343361602000,
                "i" : 155
            },
            "optimeDate" : ISODate("2012-07-27T04:00:02Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:29Z"),
            **"errmsg" : "rollback 2 error findcommonpoint waiting a while before trying again"**
        },
        {
            "_id" : 1,
            "name" : "50.52.108.17:20002",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "optime" : {
                "t" : 1343363429000,
                "i" : 7
            },
            "optimeDate" : ISODate("2012-07-27T04:30:29Z"),
            "self" : true
        },
        {
            "_id" : 2,
            "name" : "50.52.108.17:20003",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
            "uptime" : 10880311,
            "optime" : {
                "t" : 0,
                "i" : 0
            },
            "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:28Z")
        }
    ],
    "ok" : 1
}

data1:PRIMARY> rs.status()
{
    "set" : "data1",
    "date" : ISODate("2012-07-27T04:30:17Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "50.52.108.17:10001",
            "health" : 1,
            "state" : 3,
            "stateStr" : "RECOVERING",
            "uptime" : 35,
            "optime" : {
                "t" : 1343320338000,
                "i" : 3
            },
            "optimeDate" : ISODate("2012-07-26T16:32:18Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:16Z"),
            "errmsg" : "error RS102 too stale to catch up"
        },
        {
            "_id" : 1,
            "name" : "50.52.108.16:10002",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "optime" : {
                "t" : 1343363417000,
                "i" : 30
            },
            "optimeDate" : ISODate("2012-07-27T04:30:17Z"),
            "self" : true
        },
        {
            "_id" : 2,
            "name" : "50.52.108.16:10003",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
            "uptime" : 10880162,
            "optime" : {
                "t" : 0,
                "i" : 0
            },
            "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:16Z")
        }
    ],
    "ok" : 1
}

库马兰

Answer 1

看起来辅助设备已经停机了很长一段时间，现在它无法与主设备同步。此同步要求oplog包含在次要停机期间进入主数据库的所有写入。如果辅助设备已经停机太长时间，那么记录可能已经从oplog中推出，因为它是一个“上限”集合。你需要做一个完整的resyc：

http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+Replica+Set+Member

此后，请考虑增加oplog大小以避免将来出现类似情况。

Answer 2

Aafreen的回答是正确的，他的建议很好。

在调整oplog大小时要注意一些事情，以免RS102重新出现。

oplog大小取决于您更改的数据量和频率。它非常依赖于应用程序（考虑一下您的正常写入模式）。您基本上需要一个oplog，这是您在故障或维护窗口恢复的最长时间。

<强> OPLOG

oplog是一个上限集合，它存储修改MongoDB中存储的数据的所有操作。副本集的所有成员都具有oplog，允许它们维护数据库的当前状态。除非使用oplogSize选项修改oplog的大小，否则oplog的默认大小将如下所示：

对于64位Linux，Solaris和FreeBSD系统，MongoDB将分配 oplog的可用磁盘空间的5％。

如果此数量小于千兆字节，那么MongoDB将分配1千兆字节的空间。
对于64位OS X系统，MongoDB会分配183 MB的空间 oplog。

对于32位系统，MongoDB分配大约48兆字节的空间 oplog。

正如我上面提到的，每个人都没有公式，但是，如果你执行大量的写操作（插入/删除/更新），那么你可能需要更大的oplog（超过5％），而如果它主要是读取，你可能会以低于5％的价格逃脱，这实际上取决于你的应用程序。

这是调整oplog的另一个introductory link，这可能有助于解释更多内容，我还建议您阅读Replication Fundamentals document。

主要的oplog是最重要的，建议所有oplog（在副本集中）都是相同的大小。

生产中的MongoDB Sharding错误

2 个答案: