2

4台のサーバーでレプリカセットをセットアップしました。

テストの目的で、GridFSを使用してデータベースに最大1億5000万行の写真を入力するスクリプトを作成しました。私の写真は約15KBです。（これは、小さなファイルにgridfsを使用する場合に問題になることはありませんか？！）

数時間後、約5,000万行がありましたが、ログに次のメッセージがありました。

replSet error RS102 too stale to catch up, at least from 192.168.0.1:27017

そしてここにreplSetステータスがあります： 

 rs.status();
{
"set" : "rsdb",
"date" : ISODate("2012-07-18T09:00:48Z"),
"myState" : 1,
"members" : [
    {
        "_id" : 0,
        "name" : "192.168.0.1:27017",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "optime" : {
            "t" : 1342601552000,
            "i" : 245
        },
        "optimeDate" : ISODate("2012-07-18T08:52:32Z"),
        "self" : true
    },
    {
        "_id" : 1,
        "name" : "192.168.0.2:27018",
        "health" : 1,
        "state" : 3,
        "stateStr" : "RECOVERING",
        "uptime" : 64770,
        "optime" : {
            "t" : 1342539026000,
            "i" : 5188
        },
        "optimeDate" : ISODate("2012-07-17T15:30:26Z"),
        "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"),
        "pingMs" : 0,
        "errmsg" : "error RS102 too stale to catch up"
    },
    {
        "_id" : 2,
        "name" : "192.168.0.3:27019",
        "health" : 1,
        "state" : 3,
        "stateStr" : "RECOVERING",
        "uptime" : 64735,
        "optime" : {
            "t" : 1342539026000,
            "i" : 5188
        },
        "optimeDate" : ISODate("2012-07-17T15:30:26Z"),
        "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"),
        "pingMs" : 0,
        "errmsg" : "error RS102 too stale to catch up"
    },
    {
        "_id" : 3,
        "name" : "192.168.0.4:27020",
        "health" : 1,
        "state" : 3,
        "stateStr" : "RECOVERING",
        "uptime" : 65075,
        "optime" : {
            "t" : 1342539085000,
            "i" : 3838
        },
        "optimeDate" : ISODate("2012-07-17T15:31:25Z"),
        "lastHeartbeat" : ISODate("2012-07-18T09:00:46Z"),
        "pingMs" : 0,
        "errmsg" : "error RS102 too stale to catch up"
    }
],
"ok" : 1

セットはまだデータを受け入れていますが、3台のサーバーが「ダウン」しているので、どのように修復を進める必要がありますか（データを削除して再同期するよりも時間がかかりますが、機能します）？

そして特に： これはあまりにも暴力的なスクリプトのためですか？それが本番環境ではほとんど起こらないという意味ですか？

4

1 に答える 1

10

修復する必要はありません。完全な再同期を実行するだけです。

セカンダリでは、次のことができます。

  1. 失敗したmongodを停止します
  2. dbpath内のすべてのデータ（サブディレクトリを含む）を削除します
  3. 再起動すると、自動的に再同期されます

こちらの手順に従ってください。

あなたのケースで起こったことは、あなたのセカンダリが古くなったということです。つまり、彼らのoplogとプライマリのoplogに共通点はありません。さまざまなステータスの詳細が記載されているこのドキュメントをご覧ください。プライマリメンバーへの書き込みはセカンダリに複製する必要があり、セカンダリは最終的に古くなるまで追いつくことができませんでした。oplogのサイズ変更を検討する必要があります。

oplogサイズに関しては、時間の経過とともに挿入/更新するデータの量によって異なります。私はあなたに何時間、あるいは何日ものoplogを許すサイズを選びました。

さらに、実行しているO/Sがわかりません。ただし、64ビットのLinux、Solaris、およびFreeBSDシステムの場合、MongoDBは使用可能な空きディスク容量の5％をoplogに割り当てます。この量がギガバイトよりも小さい場合、MongoDBは1ギガバイトのスペースを割り当てます。64ビットOSXシステムの場合、MongoDBは183メガバイトのスペースをoplogに割り当て、32ビットシステムの場合、MongoDBは約48メガバイトのスペースをoplogに割り当てます。

レコードはどれくらいの大きさで、いくつ欲しいですか？このデータ挿入が、単にテストしただけの典型的なものなのか、異常なものなのかによって異なります。

たとえば、1KBのドキュメントに対して1秒あたり2000ドキュメントの場合、1分あたり120MBのネットになり、5GBのoplogは約40分続きます。つまり、セカンダリが40分間オフラインになるか、それ以上遅れる場合は、古くなり、完全な再同期を実行する必要があります。

ここでレプリカセットの内部ドキュメントを読むことをお勧めします。レプリカセットに4つのメンバーがありますが、これはお勧めしません。（プライマリの）投票プロセスには奇数が必要なので、アービター、別のセカンダリを追加するか、セカンダリの1つを削除する必要があります。

最後に、RS管理に関する詳細なドキュメントがあります。

于 2012-07-18T10:21:38.167 に答える