2

820 万を超えるドキュメントを含むコレクションがあります。クエリで 200 万から 300 万のそれらを削除する必要があります (1 つまたは 2 つの属性がインデックス化されています)。

私の懸念は、oplog が容量を超えて大きくなり、バックアップからすべてを再シードする必要があるため、セカンダリが遅れることです。

このようなものでしょうか...

db.my_collection.remove({attribute_1:'xyz'},false);

また

db.my_collection.remove({attribute_1:'xyz',attribute_2:'abc'},false);

(実際にドキュメントを削除する以外に) セカンダリに悪影響を与えない単一の oplog エントリになりますか? それとも、レプリケーションのために 200 万から 300 万の操作に変換されますか?

答えは、それは 1 つの操作であり、断片化から回復する必要があるかもしれないが、必ずしも oplog/2 次同期の問題ではないということだと思います。

4

2 に答える 2

2

コレクションを作成し、いくつかの一致するドキュメントを に追加することで、これを簡単にテストできremove()ます。

その後、oplog を調べて、生成されたエントリを確認できます。

use local
db.oplog.rs.find({op:'d'})

プライマリとセカンダリで同じドキュメントが削除されるようにするために、削除された各ドキュメントは oplog にエントリを生成します。

たとえば、一致する 2 つのドキュメントop: 'd'の後に oplog ( )内のエントリを削除すると、次のようになります。remove()

{
    "ts" : Timestamp(1379971718, 1),
    "h" : NumberLong("8227301495520897544"),
    "v" : 2,
    "op" : "d",
    "ns" : "test.foo",
    "b" : true,
    "o" : {
        "_id" : ObjectId("5240b21e2fa8b603e8aaaceb")
    }
}
{
    "ts" : Timestamp(1379971718, 2),
    "h" : NumberLong("-5339031341149346886"),
    "v" : 2,
    "op" : "d",
    "ns" : "test.foo",
    "b" : true,
    "o" : {
        "_id" : ObjectId("5240b2202fa8b603e8aaacec")
    }
}
于 2013-09-23T21:34:28.773 に答える
2

プライマリで削除されるドキュメントごとに、oplog に個別のエントリが作成されます。

したがって、プライマリで 300 万のドキュメントを削除した場合、セカンダリでは _id キーを介して 300 万の remove ステートメントが作成されることになります。

それらをバッチ処理して、ラグに基づいて削除を調整し、後で圧縮または再同期します。

ドキュメントの移動が多い場合は、おそらく paddingFactor セットを使用して圧縮することを検討してください。

于 2013-09-23T21:31:05.870 に答える