代码之家 › 专栏 › 技术社区 › Kumaran

MongoDB Sharding生产错误

sharding mongoose mongodb node.js php

3

Kumaran · 技术社区 · 13 年前

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

古玛兰

2 回复 | 直到 13 年前

1

6

Aafreen Sheikh 13 年前

看起来中学停课了很长一段时间,现在它无法与小学同步。此同步要求操作日志包含在辅助系统停机期间进入主系统的所有写入。如果辅助日志关闭时间过长,则记录可能已从操作日志中转出,因为它是一个“有上限”的集合。您需要执行完整的resyc:

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

之后,考虑增加操作日志的大小,以避免将来出现类似的情况。

2

Mark Hillick 13 年前

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

在调整操作日志时只需注意几点,这样RS102就不会再次出现。

操作日志的大小将取决于您更改的数据量和频率。它在很大程度上依赖于应用程序(想想你的正常写入模式是什么)。您基本上想要一个oplog,它是您在故障或维护窗口恢复的最大时间的许多倍。

操作日志

oplog是一个有上限的集合,用于存储修改MongoDB中存储的数据的所有操作。副本集的所有成员都有操作日志,使他们能够维护数据库的当前状态。除非您使用oplogSize选项修改oplog的大小,否则oplog的默认大小如下:

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

如果这个数量小于1 GB,那么MongoDB将分配1 GB的空间。
对于64位OSX系统,MongoDB将183兆字节的空间分配给操作日志。

对于32位系统,MongoDB将大约48兆字节的空间分配给操作日志。

正如我上面提到的,没有任何公式,但是,如果你执行了大量写入(插入/删除/更新),那么你可能想要一个更大的oplog(超过5%),而如果它主要是读取,你可能只需要不到5%,这真的取决于你的应用程序。

这是另一个 introductory link 调整oplog的大小,这可能有助于解释更多的事情,我还建议阅读 Replication Fundamentals document 。

主操作日志上的操作日志是最重要的,建议(副本集中的)所有操作日志大小相同。