MongoDB：出现新的碎片，但不显示内容。这是预期的吗？

我有一个包含2个碎片的Mongo集群，RS1和RS2。RS1约为600G（*），RS2约为460G。几分钟前，我添加了一个新的碎片RS3。当我连接到mongos并检查状态时，我看到的是：

mongos> db.printShardingStatus()
--- Sharding Status --- 
  sharding version: { "_id" : 1, "version" : 3 }
  shards:
        {  "_id" : "RS1",  "host" : "RS1/dbs1d1:27018" }
        {  "_id" : "RS2",  "host" : "RS2/dbs1d2:27018" }
        {  "_id" : "RS3",  "host" : "RS3/dbs3a:27018" }
  databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
        {  "_id" : "demo",  "partitioned" : false,  "primary" : "RS1" }
        {  "_id" : "cm_prod",  "partitioned" : true,  "primary" : "RS1" }
                cm_prod.profile_daily_stats chunks:
                                RS2     16
                                RS1     16
                        too many chunks to print, use verbose if you want to force print
                cm_prod.profile_raw_stats chunks:
                                RS2     157
                                RS1     157
                        too many chunks to print, use verbose if you want to force print
                cm_prod.video_latest_stats chunks:
                                RS1     152
                                RS2     153
                        too many chunks to print, use verbose if you want to force print
                cm_prod.video_raw_stats chunks:
                                RS1     3257
                                RS2     3257
                        too many chunks to print, use verbose if you want to force print
          [ ...various unpartitioned DBs snipped...]

因此，新的RS3碎片出现在碎片列表中，但不在“每个碎片有多少块”列表中。我希望它出现在列表中，所有切分集合的计数都为0

---

如果我想要一点的话，这是否是一个可以自行解决的预期行为？

它将开始将块移动到它上面，是的，事实上，在可预见的未来，它将是每个块移动的默认目标（基本选择是从块最多的块移动到块最少的块）。每个shard primary一次只能参与一次迁移，因此要移动这么多的块需要一些时间，特别是如果其他两个块都很忙的话

我曾见过人们关掉平衡器而忘记它的案例。考虑到你的另外两个碎片平衡得很好，我不认为这里是这样的，但以防万一

您可以通过连接到mongos，然后执行以下操作来检查平衡器的状态：

use config;
db.settings.find( { _id : "balancer" } )

确保“stopped”未设置为true

要查看是什么支撑着锁，并因此在此时保持平衡，请执行以下操作：

use config;
db.locks.find({ _id : "balancer" });

最后，要检查平衡器实际在做什么，请查看该机器上的mongos日志。平衡器将行输出到以

[balancer]

为前缀的日志。您还可以在日志中的主mongod实例的日志中查找迁移消息

编辑：这可能是由2.2.0发布后发现的一个bug引起的。如果从源碎片迁移的范围（区块）中存在删除，则有时会导致这种瘫痪，即所有区块迁移都被中止，而目标碎片似乎总是参与迁移，而事实上并非如此

---

由于这已在2.2.1中修复，因此建议升级以解决此问题。尽管它可以通过重启和/或当目标碎片上的坏状态自行解决时解决，如下面的注释所示。

使用

db.printShardingStatus（true）
它将打印碎片、块和所有其他详细信息的列表
我得到了以下结果，这些结果似乎是错误的（格式为易读）：
mongos>use-config-switched-db-config-mongos>db.settings.find（{u-id:“balancer”}）mongos>db.locks.find（{u-id:“balancer”}）；{“_id”：“balancer”，“process”：“dbs1d1:27017:1343957738:1804289383”，“state”：2，“ts”：ObjectId（“5040347F74448E409C964AF3”），“when”：ISODate（“2012-08-31T00:20:23.879Z”），“who”：“dbs1d1:27017:1343957738:1804289383:balancer:846930886”，“why”：“正在进行平衡回合”}
Argh，无法使该数据清晰可见，抱歉。下面是一个摘要：db.settings.find（{u id:“balancer”}）不返回任何内容。find（{u id:“balancer”}）；返回一行，说明dbs1d1（dbs1a的替代名称）拥有锁。在新的shard上，db.chunks.find（{shard:“RS3”}）.count（）返回0….aa，编写完成后，它现在开始出现。我在新框（dbs3a）上的日志中看到了这一点，它表示块移动失败（调整为适合）：[Balancer]移动块ns:cm_prod.video_latest_stats moving（ns:cm_prod.video_latest_stats at:RS2:RS2/dbs1d2:27018…RS2:RS2/dbs1d2:27018->>RS3:RS3/dbs3a:27018至8月30日17:37:06[Balancer]移动块结果：{原因：{errmsg:“迁移已在进行中”，确定：0.0}，错误消息：“moveChunk在数据传输中未能与shard接合：迁移已在进行中”，确定：0.0}有趣-什么版本？我最近与谷歌用户组中升级到2.2的人讨论了这个问题-修复基本上涉及删除过时的锁和跳转primaries/mongos：假设这是2.2，我添加了一个链接到bug的注释（已经修复，将在2.2.1中出现）和一个快速解释