2

我有一个包含超过 820 万份文档的集合。我需要通过查询删除其中的 2-3 百万个（属性或两个属性被索引）。

我担心的是由于 oplog 变得比我的容量大，然后需要我从备份中重新播种它们，从而导致我的辅助服务器落后。

会不会有这样的...

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

或者

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

是单个 oplog 条目，不会对我的辅助节点产生负面影响（除了实际删除文档）？或者它会被转换为 2-3 百万次复制操作吗？

我认为答案是这将是一个操作，并且我可能需要从中恢复一些碎片，但不一定是 oplog/辅助同步问题。

4

2 回答 2

2

对于在主节点上删除的每个文档，您最终会在 oplog 中获得一个单独的条目。

因此，如果您在主节点上删除了 300 万个文档，那么您最终将通过辅助节点上的 _id 键获得 300 万个删除语句。

我会对它们进行批处理并根据滞后限制删除，然后再压缩或重新同步。

如果您有很多文档移动，您可能需要考虑使用 paddingFactor 集进行压缩。

于 2013-09-23T21:31:05.870 回答
2

通过创建一个集合并将一些匹配的文档添加到remove().

然后，您可以检查 oplog 以查看生成了哪些条目：

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

为了确保在主备节点上删除相同的文档，每个删除的文档都会在 oplog 中生成一个条目。

例如，在匹配两个文档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 回答