在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工具有什么问题吗？我想用这个工具来管理我们的数据，但是我被困在这里了。
最佳答案
这是可能的问题（我已经在我自己的Robomongo副本上重新创建了它）。我可以在robomongo中查询runningdb['oplog.rs'].find()或db['oplog.rs'].findOne()，没有问题。但是当我在查询中指定“ts”字段时，它会运行很长时间，然后什么也不返回。
oplog.rs集合是一个特殊的封顶集合。最大限度的是，当达到设置的大小时，它会自动删除最旧的文档-http://docs.mongodb.org/manual/core/capped-collections/
注意，对于有上限的集合，通常的方法是按插入顺序进行查询，最新或最旧的文档位于排序的顶部：
查询有上限的集合
如果在没有排序的带上限集合上执行find（），
指定，MongoDB保证结果的顺序相同
作为插入顺序。
要以相反的插入顺序检索文档，请沿
使用sort（）方法，将$natural参数设置为-1，如图所示
在以下示例中：
db.cappedcollection.find（）.sort（{$natural:-1}）
特别是，由于oplog.rs是控制复制的系统级集合，因此对它有额外的限制。这会导致一些额外的限制，我稍后将进一步讨论。
不过，首先，让我们讨论一下这里发生了什么。oplog.rs中的“ts”字段上没有索引。因此，如果您已运行复制任意时间长度，则此查询将需要运行一段时间：
默认情况下，oplog的大小如下：
对于64位linux、solaris、freebsd和windows系统，mongodb会分配5%的可用磁盘空间，但总是
至少分配1 GB，但不超过50 GB。
对于64位os x系统，mongodb为oplog分配183兆的空间。
对于32位系统，mongodb为oplog分配了大约48MB的空间。
这样查询可以运行很长时间。此外，在查询完成时，您的文档可能已被删除。为什么？因为oplog.rs将删除最旧的文档，以保持在上限大小以下。但是，如果您使用findone（）来提取示例文档，则可能会对其进行排序，以提取集合中最旧的文档—这可能离被删除还有几秒钟的时间。您可以通过在繁忙的系统上的oplog.rs上反复运行findone（）来尝试这一点—每次都会得到不同的文档。
一些人以前曾试图通过在oplog.rs中的“ts”字段上创建索引来解决这个问题，但它没有起作用。原因是oplog.rs的特殊性-索引将创建但不会更新。有关详细信息，请参见此处的讨论：Index on ts field in oplog.rs is not updated
总的来说，robomongo的问题可能更严重（它对错误消息有点轻描淡写，不清楚何时超时），但根本原因在于mongodb体系结构。