蒙蒂甘:拥有575 GB数据的4个碎片是否认为是一个小的共享集群？

Question

我需要用操作管理器测试恢复。为此，我“克隆”了生产切分的集群。我创建的VM具有与生产相同的大小，并执行mongodump/mongorestore (操作系统管理器部署)。我的测试(恢复)不需要是一个一致的副本，对我来说，没有问题，如果大约5GB是丢失。

DATA SIZE: 573.6 GB

shard0
142.6 GB

shard1
145.94 GB

shard2
142.55 GB

shard3
142.52 GB

出于简单的原因，我希望在把它输送到蒙古国上使用mongos。

我找到了一个旧的医生(v3.0) 用单根节点备份一个小共享集群。这些文档在新的MongoDB版本中不再存在。

如果您的切分群集包含一个小数据集，则可以使用mongodump连接到一个mongos。

什么是以GB表示的小数据集？关于我的部署，请参阅上文。

如果您在不指定数据库或集合的情况下使用mongodump，mongodump将从配置服务器捕获收集数据和集群元数据。

我不需要备份显式配置RS？

将数据还原到切分群集时，必须在从备份还原数据之前部署和配置切分。有关更多信息，请参见部署共享群集。

意思是在还原之前，我需要定义shard key (and enable sharding)？

我错过了什么步骤/重要的事情吗？

Answer 1

我找到了一个旧的医生(v3.0) 用单根节点备份一个小共享集群。这些文档在新的MongoDB版本中不再存在。

此过程仅用于备份来自小型切分群集的数据，而不包括重新创建切分环境或捕获实时备份。正如您已经注意到的，没有提到备份配置服务器数据或切分环境所需的其他基本步骤(例如，停止平衡器)。此过程可能适用于从开发或暂存环境中备份数据，但对于典型的生产环境则不推荐。

有关使用mongodump的更完整的切分备份过程，请参见：使用数据库转储备份共享群集。请确保您所引用的文档的版本与您的MongoDB发行版系列相匹配，因为可能存在显著的差异。

但是，您提到了使用MongoDB操作管理器，它包含用于备份切分群集的特定功能。如果选择人工恢复选项，操作管理器将提供存档文件来恢复配置服务器和碎片。由于Ops许可是MongoDB企业订阅的一部分，如果您需要对任何过程或需求进行建议或澄清，我建议使用MongoDB提供商业支持。

什么是以GB表示的小数据集？

没有绝对数字。一般因素包括资源挑战，例如数据相对于RAM的大小、可用网络带宽以及数据更改的速度。通常，如果您有足够的数据或工作负载来保证分片，那么作为备份方法，您也已经超越了mongodump。

mongodump将把所有数据读入内存中，如果数据比可用内存大得多，这将对碎片的工作集产生重大影响。您还需要有足够的磁盘空间来保存通过单个MongoDB 3.2+转储的数据的完整备份(或对mongos的压缩备份)、足够的网络带宽来处理增加的流量等。

对于特定的用例，mongodump肯定不是一个值得推荐的策略，原因有几个：

• 这是一个生产环境
• 您希望在另一个环境中克隆/重新创建已分割的群集。
• 您可以访问MongoDB操作管理器进行备份

Answer 2

它不是一个被分割的小集群。

Mongodump将花费大约5小时，600 on和恢复将需要超过5小时根据索引在您的收集。

我最好的建议是：

1. 如果已经有一个由Manager执行的备份，请使用该备份并在新环境上进行恢复。
2. 如果在您的情况下时间不是问题，请使用转储和恢复方法。
3. Mongodump和restore方法可以处理巨大的数据库，如果您想恢复少量的集合，那么可以使用导出和导入选项。

注意:我可以在这里给出一个小提示，让这个过程更快：

Mongodump将对db进行备份，并为每个文件收集2个文件，一个是bson，另一个是json。Bson将拥有索引，json将拥有数据。

因此，Mongorestore进程将首先恢复json文件，然后开始恢复bson文件并应用索引。

为了使这个过程更快地完成，首先创建一个mongodump并从所有dbs和集合中获取所有索引，然后手动应用索引，然后使用mongorestore恢复数据，此过程将节省至少30%-40%的时间。