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

アーフリーンの答えは正しく、彼のアドバイスは良いです。

RS102が再発しないように、oplogのサイズを設定するときにいくつかの点に注意してください。

oplogのサイズは、変更するデータの量と頻度によって異なります。これはアプリケーションに大きく依存します（通常の書き込みパターンについて考えてください）。基本的に、障害またはメンテナンスウィンドウで回復するのに最大の時間であるoplogが必要です。

Oplog

oplogは、MongoDBに格納されているデータを変更するすべての操作を格納する上限付きコレクションです。レプリカセットのすべてのメンバーには、データベースの現在の状態を維持できるようにするoplogがあります。oplogSizeオプションを使用してoplogのサイズを変更しない限り、oplogのデフォルトサイズは次のようになります。

  • 64ビットのLinux、Solaris、およびFreeBSDシステムの場合、MongoDBは使用可能な空きディスク容量の5％をoplogに割り当てます。

    この量がギガバイトよりも小さい場合、MongoDBは1ギガバイトのスペースを割り当てます。

  • 64ビットOSXシステムの場合、MongoDBは183メガバイトのスペースをoplogに割り当てます。

    32ビットシステムの場合、MongoDBは約48メガバイトのスペースをoplogに割り当てます。

上で述べたように、言うまでもなく式はありませんが、多くの書き込み（挿入/削除/更新）を実行している場合は、より大きなoplog（5％よりも大きい）が必要になる場合がありますが、ほとんどが読み取りである場合は、 5％未満で逃げてください、それは本当にあなたのアプリに依存します。

これは、oplogのサイズ設定への別の紹介リンクです。これは、もう少し説明するのに役立つ可能性があります。また、レプリケーションの基礎に関するドキュメントを読むことをお勧めします。

プライマリのoplogが最も重要であり、（レプリカセット内の）すべてのoplogが同じサイズであることが推奨されます。

于 2012-07-27T09:52:35.557 に答える