我需要使用 Ops Manager 测试恢复。为此,我“克隆”了生产分片集群。我创建了与生产规模相同的 VM 并执行mongodump/mongorestore
(Ops Manager 部署)。我的测试(用于恢复)不需要是一致的副本,对我来说,如果丢失大约 5 GB 就没问题。
DATA SIZE: 573.6 GB
shard0
142.6 GB
shard1
145.94 GB
shard2
142.55 GB
shard3
142.52 GB
为简单起见,我希望使用mongodump 并将其通过管道传输到mongos
.
我找到了一个旧文档 (v3.0) Backup a Small Sharded Cluster with mongodump。该文档在新的 MongoDB 版本中不再存在。
如果您的分片集群包含一个小数据集,您可以使用 mongodump 连接到 mongos。
GB中的小数据集是什么?见上文我的部署。
如果您在不指定数据库或集合的情况下使用 mongodump,mongodump 将从配置服务器捕获集合数据和集群元数据。
我不需要显式备份配置 RS?
将数据恢复到分片集群时,必须在从备份恢复数据之前部署和配置分片。有关详细信息,请参阅部署分片集群。
这意味着用简单的英语我需要shard key (and enable sharding)
在恢复之前定义?
我会错过任何步骤/重要的事情吗?
它不是一个小的分片集群。
600GB 的 Mongodump 大约需要 5 个小时,而根据您收藏中的索引,恢复需要超过 5 个小时。
我最好的建议是:
如果您已经有 Mongo Ops-Manager 进行的备份,请使用它并在新环境中恢复。
如果时间对您来说不是真正的问题,请使用转储和恢复方法。
Mongodump 和 restore 方法可以处理巨大的数据库,如果你想恢复几个集合然后使用 export 和 import 选项。
注意:我可以在这里给出一个让这个过程更快的小提示:
Mongodump 将在 2 个文件中备份 db 和集合,一个是 bson,另一个是 json。Bson 将拥有索引,而 json 将拥有数据。
因此,Mongorestore 进程将首先恢复 json 文件,然后开始恢复 bson 文件并应用索引。
为了更快地完成这个过程,首先制作一个 mongodump 并从所有数据库和集合中获取所有索引并首先手动应用索引,然后使用 mongorestore 恢复数据,这个过程将至少节省 30-40% 的时间。
此过程仅用于备份数据,不包括重新创建分片环境或捕获时间点备份。正如您所注意到的,没有提及备份配置服务器数据或分片环境所需的其他基本步骤(例如,停止平衡器)。此过程可能适用于从开发或暂存环境备份数据,但不推荐用于典型的生产环境。
有关使用 的更完整的分片备份过程
mongodump
,请参阅:使用数据库转储备份分片集群。请确保您引用的文档版本与您的 MongoDB 发布系列相匹配,因为可能存在显着差异。但是,您提到使用 MongoDB Ops Manager,它包括用于备份分片集群的特定功能。如果您选择手动恢复选项,Ops Manager 将提供存档文件来恢复配置服务器和分片。由于 Ops Manager 许可是 MongoDB Enterprise 订阅的一部分,如果您需要有关任何程序或要求的建议或说明,我建议您提出 MongoDB 的商业支持案例。
没有绝对的数字。一般因素包括资源挑战,例如数据相对于 RAM 的大小、可用网络带宽以及数据变化的速度。
mongodump
通常,如果您有足够的数据或工作负载来保证分片,那么作为备份方法,您也已经过时了。mongodump
将把所有数据读入内存,如果您的数据比可用 RAM 大得多,这将对分片的工作集产生重大影响。您还需要有足够的磁盘空间来保存通过单个转储的数据的完整备份(或 MongoDB 3.2+ 的压缩备份)mongos
,足够的网络带宽以应对增加的流量等。对于您的特定用例
mongodump
,出于以下几个重要原因,绝对不是值得推荐的策略: