大型 `mongodump` 后跟 `mongorestore`

Question

我有一个相当大（约 240GB）的 Mongo 数据库，我需要通过缓慢的网络将其传输到新服务器上。

传统上针对这些情况，我发现一个mongodump后跟一个mongorestore已经很多比更快的db.cloneCollection()方法。但是，我今天意识到，执行 fullmongodump后跟mongorestorea 有点浪费（我认为），因为我先完成所有数据传输，然后再进行所有插入。

我更喜欢从旧 mongo 传输数据（mongodump步骤），同时将可用数据插入新数据库（mongorestore步骤）。

有谁知道如何在 MongoDB 中并行化转储和插入过程？（这实际上会更快吗？）

Answer 1

首先，您可以使用管道

mongodump -h sourceHost -d yourDatabase … | mongorestore -h targetHost -d yourDatabase …

这减少了时间，因为读取的每个文档或多或少会立即在targetHost.

但是，这样做的缺点是，如果该过程因某种原因（例如网络故障）中止，您可能会遇到问题。至于并行化，您可以对每个集合执行上述操作，但我怀疑您是否会获得任何性能提升，因为限制因素很可能是 IO，即使没有，并发性也很可能是一个杀手。

我要做的是创建一个临时副本集，由旧服务器、新服务器和仲裁器组成。初始同步速度相当快，即使您遇到网络问题，同步机制也会确保一切正常。初始同步完成后，您只需让旧服务器退出主服务器并重新启动新服务器，而不使用replSetName 选项，使其再次成为独立服务器。现在您可以连接到新服务器并传输所有数据。

这样做的好处是停机时间最少，而且无人值守。初始化副本集后，您的应用程序仍然可以使用旧服务器，甚至新数据也会自动转移到新服务器。所以你不必坐在旁边——而且我们都知道这个过程很可能在凌晨 3 点完成，无论时区如何。;)初始同步完成后的任何时间（甚至数小时或数天后），您都可以将新服务器设为独立服务器，并将应用程序的连接字符串更改为新服务器。如果计划得当，这只需 2 或 3 分钟。

编辑

但是，此方法有一个缺点：您只能从一个版本升级到更高的版本。因此，从 2.4（撰写本文时的考古学）迁移到 3.4（前沿），您必须多次重复该过程：

• 从 2.4 到 2.6
• 从 2.6 到 3.0
• 从 3.0 到 3.2
• 从 3.2 到 3.4

Answer 2

接受的答案对我不起作用，因为它缺少一些参数：

mongodump --host source:port --db databasename --gzip --archive | \
mongorestore --drop -vvvvvv -h target:port --db databasename --gzip --archive

--gzip可以并且可能应该省略，因为这仅压缩管道中的数据（在执行命令的机器的总线上），而不压缩数据库和执行命令的机器之间的数据（通过线路）。也许它只是导致不必要的计算开销。如果我没记错的话，MongoDB 无论如何都会通过网络压缩数据（在服务器和驱动程序之间）。

--archive如果没有给出文件名，则没有文件名分别写入stdout和读取stdin

--drop 完全替换目标数据库。