碎片群集v4.2.x \x>错误：“恐慌:关闭通道的关闭”

Question

场景：

我有一个独立的MongoDB Serverv3.4.x，其中分别有几个DB和集合。由于计划是升级到最新的4.2.x，我已经创建了一个所有DB的mongo转储。

创建了配置服务器(副本集群)、shard-1服务器(副本集群)和shard-2服务器(集群) MongoDB v4.2.x的碎片集群。

发布：

现在，当我尝试恢复转储时，每次我尝试恢复DBs时，它都是部分恢复。如果我试图恢复单个DB，它会失败，但也会出现相同的错误。但是，每当我试图恢复特定的DB &特定集合时，它总是工作得很好。但问题是在许多DB中有这么多的集合。不能对所有的进程执行此操作&每次在不同的进度百分比/收集/DBs中失败时。

误差

2020-02-07719:07:03.822+0000 [#####################...] myproduct_new.chats 68.1MB/74.8MB (91.0%)
2020-02-07719:07:03.851+0000 [########## ] myproduct_new.metaCrashes 216MB/502MB (42.9%) 
2020-02-07719:07:03.876+0000 [################## ] myproduct_new.feeds 152MB/196MB (77.4%)

panic: close of closed channel
goroutine 25 [running]: github.com/mongodb/mongo-tools/mongorestore.(*MongoRestore).RestoreCollectionToDB(Oxc0001a0000, 0xc000234540, Oxc, 0xc00023454d, 900, Ox7fa5503e21f0, 0xc00020b890, 0x1f66e326, Ox0, ...)

/data/mci/533e19bcc94a47bf738334351cf58a07/src/src/mongo/gotools/src/github.com/mongodb/mongo-tools/mongorestore/restore. github.com/mongodb/mongo-tools/mongorestore.(*MongoRestore).RestoreIntent(Oxc0001a0000, Oxc00022f9e0, Ox0, Ox0, Ox0, Ox0) 
/data/mci/533e19bcc94a47bf738334351cf58a07/src/src/mongo/gotools/src/github.com/mongodb/mongo-tools/mongorestore/restore. github.com/mongodb/mongo-tools/mongorestore.(*MongoRestore).RestoreIntents.funcl(Oxc0001a0000, 0xc000146420, 0x3) 
/data/mci/533e19bcc94a47bf738334351cf58a07/src/src/mongo/gotools/src/github.com/mongodb/mongo-tools/mongorestore/restore. created by github.com/mongodb/mongo-tools/mongorestore.(*MongoRestore).RestoreIntents 
/data/mci/533e19bcc94a47bf738334351cf58a07/src/src/mongo/gotools/src/github.com/mongodb/mongo-tools/mongorestore/restore. ubuntu@ip-00-xxx-xxx-00:/usr/local/backups/Dev_backup_07-02-2020$  Ox10, Oxc00000f go:503 +0x49b go:311 +Oxbe9 go:126 +Oxlcb go:109
    +0x12d

问题：

我正在连接到芒果并试图恢复。目前，还没有为任何DB启用分片。有人能说明什么地方出了问题或者如何恢复垃圾场吗？

Answer 1

我有同样的问题，然后我发现是我的mongodb复制集的问题导致了这个错误。

检查数据库的rs.status()。

如果你收到消息

我们的复制集配置无效，或者我们不是它的成员。

试试这个答案

Answer 2

我们面临着完全相同的问题，同样的规格，试图从蒙突甘恢复。没有明确的理由，但最好检查以下因素

检查您的转储大小(Bjson)与集群上分配的磁盘空闲空间。转储大小可能是我们的核心Mongo数据文件夹大小的2到3倍(在BJSON之上压缩)

检查在集群创建期间配置的Oplog大小，第一次迁移提供了10-15%的空闲磁盘空间大小作为Oplog大小，您可以在迁移后更改这一点。这将有助于第二次访问延迟时间更长，并且能够更快地赶上WAL的同步。分配3.5GB的总硬盘大小的oplog，与45 GB的总数据(压缩)。在实际使用场景中(迁移后)，将其作为oplog大小的1-2小时写入数据卷。

现在，您的总磁盘空间将是转储文件夹大小+ Oplog +6GB(默认mongo安装+系统附加)。注意:如果无法分配转储文件夹大小，则必须分批运行恢复(DBs或Collections选项)，给Mongo在导入bjson后压缩的时间。这应该在几分钟内完成。

还原后，Mongo将缩小数据大小，磁盘空间将与独立数据文件夹大小大致匹配。

如果在迁移过程中没有设置磁盘空间，并且您的磁盘空间处于准备状态，则Mongo将尝试增加磁盘空间，而当使用Primary时，它无法增加磁盘空间，而是尝试增加次要磁盘空间，并使当前的主磁盘空间变为次要磁盘空间，这可能会导致上述错误。还可以检查硬件/状态Vitals，以查看服务器是否将状态从主服务器更改为辅助服务器

此外，在创建集群时不要启用服务器自动升级，我没有明确的理由，但我们不希望在后台发生任何操作，比如将M30升级到M40，因为CPU在迁移过程中很忙(发生在我身上)

最后，作为良好的实践，尝试运行大型数据库，主要是大型单一集合>4GB(无碎片)。我有40+ dbs，20% >15 4GB的转储BJSON大小，有1到2个大型集合，拥有>4GB的数百万个文档。一旦我把它们分开，它就给了蒙戈一些喘息的空间，可以用几分钟的时间大量地插入和压缩它们。Mongo恢复发生在收集级别上。

所以不用花40到50分钟来恢复，而是经过一些模拟练习和秩序后，花了90到120分钟。

如果你有时间计划的话，试试这个。任何其他学习请分享

关键外卖-检查您的转储文件夹大小和大型集合大小。磁盘写入率、OPLOG延迟、RAM、CPU、IO是Dumprestore期间保持监视的良好KPI。