mongodb - 无法通过 Robomongo 工具查询 TimeStamp oplog.rs

Question

在 oplog.rs 集合中有如下内容:

{
    "ts" : Timestamp(1401265282, 41),
    "h" : NumberLong(-8979599167307291610),
    "v" : 2,
    "op" : "i",
    "ns" : "test",
    "o" : {
        ...........
    }
}

使用 Robomongo 工具我输入以下查询:

db.oplog.rs.find({"ts": Timestamp(1401265282,41)})

我一无所获:(

当我在控制台中使用 mongo 客户端工具时，它可以正常工作。

那么 Robomongo 工具有什么问题吗？我想使用此工具来管理我们的数据，但卡在了这里。

Answer 1

这是可能的问题(我已经在我自己的 Robomongo 副本上重新创建了它)。我可以在 Robomongo 中查询正在运行的 db['oplog.rs'].find() 或 db['oplog.rs'].findOne() 并且没有任何问题。但是当我在查询中指定“ts”字段时，它会运行很长时间然后什么都不返回。

oplog.rs 集合是一个特殊的上限集合。上限在于它会在达到设定大小时自动删除最旧的文档 - http://docs.mongodb.org/manual/core/capped-collections/

请注意，对于上限集合，通常的方法是按插入顺序进行查询，最年轻或最旧的文档排在最前面:

Query a Capped Collection

If you perform a find() on a capped collection with no ordering specified, MongoDB guarantees that the ordering of results is the same as the insertion order.

To retrieve documents in reverse insertion order, issue find() along with the sort() method with the $natural parameter set to -1, as shown in the following example:

db.cappedCollection.find().sort( { $natural: -1 } )

特别之处在于 oplog.rs 有额外的限制，因为它是作为系统级集合控制复制的角色。这会导致一些额外的限制，我稍后会详细讨论。

不过，首先，让我们讨论一下这里发生了什么。 oplog.rs 中的“ts”字段没有索引。因此，如果您运行了任意时间长度的复制，则此查询将需要一些时间来运行:

By default, the size of the oplog is as follows:

• For 64-bit Linux, Solaris, FreeBSD, and Windows systems, MongoDB allocates 5% of the available free disk space, but will always
  allocate at least 1 gigabyte and never more than 50 gigabytes.
• For 64-bit OS X systems, MongoDB allocates 183 megabytes of space to the oplog.
• For 32-bit systems, MongoDB allocates about 48 megabytes of space to the oplog.

这样查询就可以运行很长时间。此外，在查询完成时，您的文档可能已被删除。为什么？因为 oplog.rs 将删除最旧的文档以保持在上限大小以下。然而，如果您执行 findOne() 来提取示例文档，它可能会对它进行排序以提取集合中最旧的文档——这可能距离被删除仅几秒钟之遥。您可以通过在繁忙的系统上对 oplog.rs 重复运行 findOne() 来自己尝试 - 您每次都会不断获得不同的文档。

有些人之前曾尝试通过在 oplog.rs 中的“ts”字段上创建索引来解决这个问题，但没有奏效。原因是由于 oplog.rs 的特殊性——索引会创建但不会更新。有关详细信息，请参见此处的讨论:Index on ts field in oplog.rs is not updated

总的来说，Robomongo 的问题可能更严重(它在错误消息上有点轻，并且不清楚何时超时)，但根本原因在 MongoDB 架构中更深层次。