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

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

以下是我们今天早上收到的详细信息。但是我们不知道如何解决这个问题。

请告诉我如何解决这个问题。

"errmsg": "rollback 2 error findcommonpoint waiting a while before try again"

“errmsg”:“错误 RS102 太陈旧无法 catch ”

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
}

库马兰

最佳答案

看起来辅助服务器已关闭很长时间，现在无法与主服务器同步。此同步要求 oplog 包含在辅助 Node 停机期间发送到主 Node 的所有写入。如果辅助 Node 停机时间过长，记录可能已从 oplog 中滚出，因为它是一个“上限”集合。您需要执行完整的重新同步:

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

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

关于php - 生产中的 MongoDB 分片错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11681817/