我有一个数据库
在大小为19.032GB的磁盘上（使用show dbs命令）
数据大小56 GB（使用db.collectionName.stats(1024*1024*1024).size命令）
当使用命令mongodump执行mongodump时，我们可以设置param --gzip。
| 命令|转储中占用时间|转储大小|恢复时间|观测值|
| - -|- -|- -|- -|- -|
| 使用gzip| 30分钟|7.5 GB内存|20分钟|在mongostat中，插入速率范围为30 K至80 K/秒|
| 没有gzip| 10分钟|57 GB内存|50分钟|在mongostat中，插入速率是非常不稳定的，并且范围从8 k到20 k每秒|
转储是从8核，40 GB内存的机器（机器B）到12核，48 GB内存的机器（机器A）。并从机器A恢复到12核，48 GB的机器（机器C），以确保mongo，mongorestore和mongodump进程之间没有资源争用。Mongo版本4.2.0
我有几个问题
- 2个转储之间的功能差异是什么？
- bson转储可以压缩使其压缩吗？
1.索引的数量如何影响mongodump和恢复过程.（如果我们删除一些唯一的索引，然后重新创建它，它会加快总的转储和恢复时间吗？考虑在做插入mongodb将不必照顾唯一性部分）
1.有没有办法让整个过程更快。从这些结果我看到，我们必须选择1转储和恢复速度之间。
1.使用更大的机器（RAM）读取转储并恢复它是否会加快整个过程？
1.较小的转储是否有助于缩短总时间？
更新：2. bson转储是否可以压缩为zip？
是的
% ./mongodump -d=test
2022-11-16T21:02:24.100+0530 writing test.test to dump/test/test.bson
2022-11-16T21:02:24.119+0530 done dumping test.test (10000 documents)
% gzip dump/test/test.bson
% ./mongorestore --db=test8 --gzip dump/test/test.bson.gz
2022-11-16T21:02:51.076+0530 The --db and --collection flags are deprecated for this use-case; please use --nsInclude instead, i.e. with --nsInclude=${DATABASE}.${COLLECTION}
2022-11-16T21:02:51.077+0530 checking for collection data in dump/test/test.bson.gz
2022-11-16T21:02:51.184+0530 restoring test8.test from dump/test/test.bson.gz
2022-11-16T21:02:51.337+0530 finished restoring test8.test (10000 documents, 0 failures)
2022-11-16T21:02:51.337+0530 10000 document(s) restored successfully. 0 document(s) failed to restore.
2条答案
按热度按时间qgzx9mmu1#
我不是MongoDBMaven，但我有很好的MongoDB备份和恢复活动的经验，并将回答我所知的最好的。
mongodump指令，而不使用--gzip选项，会将每个文件储存为bson的档案。这将显著减少备份和恢复操作所花费的时间，因为它只读取bson文件并插入文档，而牺牲的是
.bson转储文件大小--gzip选项时，bson数据被压缩并转储到一个文件中。这将显著增加mongodump和mongorestore所用的时间，但由于压缩，备份文件的大小将非常小。编辑：
正如“最好的祝愿”所指出的，我完全误解了这个问题。
由
mongodump执行的gzip只是在mongodump端执行的一个gzip，从字面上看，这与在我们端手动压缩原始BSON文件是一样的。例如，如果您使用任何压缩应用程序提取
.gzip.bson文件，您将获得实际的BSON备份文件。请注意，
zip和gzip是不同的（在压缩方面），因为它们都使用不同的压缩算法，即使它们都压缩文件。所以你会得到不同的结果，在比较mongodump gzip和手动压缩文件的文件大小。1.索引的数量如何影响mongodump和恢复过程。（如果我们删除一些唯一的索引，然后重新创建它，它会加快总的转储和恢复时间吗？考虑在做插入mongodb将不必照顾唯一性部分）
mongodump工具都会创建一个<Collection-Name.metadata.json>文件，它基本上包含了所有的索引，后面跟有集合名称，uuid，colmod，dbUsersAndRoles等等。mongodump操作期间，集合中索引的数量和类型不会产生影响。但是，在使用mongorestore命令还原数据后，它将遍历元数据文件中的所有索引并尝试重新创建索引。background: true选项在原始集合中应用索引，在恢复时重建索引将花费更多的时间。--noIndexRestore选项，以避免在mongorestore作业期间进行索引作业。您可以在稍后需要时进行索引。在我公司的生产备份环境中，与恢复数据相比，索引键需要更多的时间。
1.有没有办法让整个过程更快。从这些结果我看到，我们必须选择1转储和恢复速度
解决方案取决于...
--noIndexRestore标志执行恢复过程。gzip压缩或手动zip压缩，或同时应用这两种压缩（选择最适合您的压缩方式）选择最适合您的方案，但您必须在时间和空间之间找到适当的平衡，首先是在决定是否应用索引时，其次是在是否应用索引时。
在我的公司，我们通常对P-1进行非压缩备份和恢复，对几周前的生产备份进行gzip压缩，并对几个月前的备份进行进一步的手动压缩。
data路径，并在被迁移机器的MongoDB示例中更改DB路径。同样，我不推荐这种方法，因为有很多事情可能会出错。但我不能保证你也是一样。如果你决定这么做，风险自担。1.使用更大的机器（RAM）读取转储并恢复它是否会加快整个过程？
1.较小的转储是否有助于缩短总时间？
smaller dump是指使用--query标志限制要转储的数据，那么它肯定会这样做，因为要备份和恢复的数据非常少。希望这能帮助您回答问题。如果您有任何疑问，请告诉我：
5sxhfpxr2#
以下是我的两点看法：根据我的经验：使用--gzip来节省存储空间和时间，即所谓的以空间换时间，mongodump和mongorestore都将产生开销。
此外，我还使用并行设置：--numParallelCollections=n1 --numInsertionWorkersPerCollection=n2这可能会将性能提高大约10%，n1和n2取决于服务器上的CPU数量。
还原过程也有重建索引，这取决于您数据库中索引多少一般来说，重建索引比数据还原快
希望这些能有所帮助！