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/

请注意，对于上限集合，通常的方法是按插入顺序进行查询，其中最小或最旧的文档位于排序顶部：

查询上限集合

如果在没有排序的上限集合上执行find（）   如果指定，MongoDB保证结果的排序是相同的   作为插入顺序。

要以反向插入顺序检索文档，请发出find（）   使用sort（）方法并将$ natural参数设置为-1，如图所示   在以下示例中：

db.cappedCollection.find（）。sort（{$ natural：-1}）

特别之处在于对oplog.rs有其他限制，因为它可以作为控制复制的系统级集合。这导致了一些额外的限制，我将在稍后讨论。

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

默认情况下，oplog的大小如下：


对于64位Linux，Solaris，FreeBSD和Windows系统，MongoDB分配5％的可用可用磁盘空间，但始终为   分配至少1千兆字节，不超过50千兆字节。

对于64位OS X系统，MongoDB会为oplog分配183 MB的空间。

对于32位系统，MongoDB为oplog分配大约48兆字节的空间。

这样查询可以运行很长时间。此外，在查询完成时，您的文档可能已被删除。为什么？因为oplog.rs将删除最旧的文档以保持在上限大小下。然而，如果你执行一个findOne（）来拉出一个示例文档，它可能会将它排序为拉出集合中最旧的文档 - 这可能只需几秒钟就可以删除。您可以通过在繁忙的系统上的oplog.rs上重复运行findOne（）来自己尝试 - 每次都会收到不同的文档。

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

整体而言，Robomongo的问题可能更糟（它在错误消息上有点亮，而且在超时时不清楚）但是根本原因在MongoDB架构中更深层次。

Answer 2

此问题最近才向Robomongo问题跟踪器报告（请参阅：Timestamps being handled incorrectly）。

这里的问题实际上是由于Robomongo 0.8.x使用较旧版本的mongo shell。

Timestamp() shell中的mongo构造函数在MongoDB 2.4中发生了重大变化：SERVER-7718: Timestamp constructor in shell should take seconds instead of milliseconds。

由于mongo实现是本机代码而不是JavaScript，我现在还没有意识到解决方法（使用普通的Timestamp() shell进行查询）。这个问题将在Robomongo的下一个主要版本（0.9.0里程碑）中得到解决，但目前还没有ETA。

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

2 个答案: