db.collection.count（）为MongoDB中的分片集合返回更多文档

我有2个带有复制集的碎片（每个碎片有3个实例）。当我对切分的集合执行

count（）

时，我得到的文档数量远远超过了实际数量（超过250万个文档）。在

forEach（）

循环中执行

find（）

和递增计数器时也是如此

我如何知道文件的真实数量？首先，我知道增长的趋势，也就是说，增长不可能如此剧烈。其次，当我使用下面的M/R脚本计算文档数时，我得到了真实的文档数（正如我假设的那样）。我使用此脚本查看重复的文档。重复的数量是几千而不是几百万。而

test\u duplicate\u collection

减去duplicates的计数给出了文档的真实数量

var map = function(){
   emit(this.doc_id, 1);
};

var reduce = function(key, values){
   var result = 0;
   values.forEach(function(value) {
     result += value;
   });

   return result;
};

db.test_collection.mapReduce(map, reduce, "test_duplicate_collection",null );

现在，我知道在平衡过程中，可能会发生一些块在传输到另一个碎片时还没有被删除的情况。但是我在status（

sh.status（）

）中看到所有的块都是均匀分布的。我还尝试暂停写操作，看看是否需要一些时间，但什么也没发生

您可能会说删除移动的块仍在继续，事实上，当我刚开始使用分片时，我看到分片收集的数量略有减少（没有写操作）。但目前，随着时间的推移没有任何变化，它只是停滞不前。 我还尝试使用

orphanage.js

，希望找到孤立的文档（使用中的脚本），但没有找到这样的文档

我的问题是，

count（）

和

find（）.forEach（）

提供的文档数量超过实际数量的原因是什么（即与M/R脚本相比）

谢谢你的帮助

EDIT1

其中一个碎片中的复制集配置有问题。具体而言，配置文件中未设置任何主控。在MMS仪表板中，我总是看到被其他复制主机侦听的主机的

从机

，而不是

主

。当我们修复它时，

forEach

循环计数开始显示与上面M/R脚本中相同数量的文档。因此，目前唯一的问题是

count（）

本身

在MongoDB JIRA中，我在sharded环境中发现了以下未解决的带有count（）的bug

---

但它实际上与平衡期间的count（）有关，即count可以计算当前由平衡器移动的块。作为一种解决方法，这个bug建议放置一个始终为真的查询。我也尝试过，但它仍然像以前一样返回count。

尝试使用较慢（但显然更准确）的

.itcount（）

您是否检查了插入/更新查询是否正确（共享将非常有用）？您通过mongos执行所有查询，而不是直接针对碎片执行查询，正确吗？@Sai我将再次检查有关插入/更新的信息。@AsyaKamsky是的，我所有的查询都是通过mongos进行的。您是否找到解决此问题的方法？mongo 2.6.7 cluster1中的不同步索引也存在同样的问题。itcount是java驱动程序的一个特殊功能。OP从未说过他们在使用Java2。它有一个大的“仅供测试！”警告。我在外壳中使用过它。只是还不能有任何文档。