3

我们使用 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
}

库马兰

4

2 回答 2

6

看起来辅助服务器关闭了很长时间，现在它无法与主服务器同步。此同步要求 oplog 包含在辅助节点停机期间发送到主节点的所有写入。如果辅助节点已关闭太久，则记录可能已从 oplog 中推出，因为它是“上限”集合。您需要进行完整的 resyc：

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

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

于 2012-07-27T06:44:37.870 回答
2

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

只是在调整 oplog 大小时要注意一些事项，以免 RS102 再次出现。

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

操作日志

oplog 是一个有上限的集合，它存储所有修改存储在 MongoDB 中的数据的操作。副本集的所有成员都有允许他们维护数据库当前状态的操作日志。除非您使用 oplogSize 选项修改 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 的空间。

正如我上面提到的，没有公式，但是，如果您执行大量写入（插入/删除/更新），那么您可能需要更大的 oplog（超过 5%），而如果主要是读取，您可能会不到 5% 就逃脱了，这真的取决于你的应用程序。

这是另一个关于调整 oplog 大小的介绍性链接，它可能有助于解释更多内容，我还建议阅读Replication Fundamentals 文档。

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

于 2012-07-27T09:52:35.557 回答