问具有副本集的MongoDB恢复

EN

根据MongoDB BOL文档，这里 MongoDB为复制集的restoring辅助成员提供two options：

1)每个数据目录的手动复制数据库文件。

2) 允许初始同步自动分发数据。

注意：-如果您的数据库很大，initial sync可能需要很长时间才能完成。对于大型数据库，最好将数据库文件复制到每个host上。

主要问题是:恢复备份的最佳方法是什么？

如果要将mongodump备份还原到副本集中，则需要将mongorestore还原到当前主服务器。数据将通过正常方式复制到其他副本集成员。您可以在导入之前使用mongorestore --drop ...删除每个集合(如果它已经存在)，但是在完全恢复场景中，通常是从空部署开始重新构建副本集。与MongoDB 3.6一样，mongorestore只插入文档--它不会删除任何现有数据库，也不会重新插入/更新/替换任何现有文档。

Q1:我必须遵循这些步骤吗？

此列表中唯一适用的步骤是“将备份还原为主”。使用mongodump，您将导出数据和索引定义，并且必须将mongorestore导入主文件以重新生成数据文件。当您正在恢复时，您的备用文件必须处于联机状态，并且能够通过复制保持同步。您可以使用--writeConcern majority选项等待大多数副本集确认写入，并确保还原速度不超过复制速度。

Q2:恢复主服务器上的备份而不停止任何服务器？

这是正确的方法。

Q3。使次要备份为主备份，并将备份还原为次要备份(以前的主备份)，并将其恢复为主备份。

一个副本集只能有一个主服务器，因此您不会通过交换当前主服务器和辅助服务器的角色来获得任何信息。数据仍需复制。

Q4:有任何方法来恢复这两个服务器吗？请建议恢复MongoDB的最佳方法。

为了构建数据文件，您必须将mongodump还原到主文件中。如果您正在寻找将数据复制到每个次要文件的替代方案:您可以将mongorestore复制到单个节点副本集中，停止主副本集，然后复制数据文件为新的次要文件种子并避免初始同步。

当然有更好的方法来进行备份，特别是如果您的目标是拥有更快(且影响更小)的备份和恢复时间。使用mongodump备份大型部署会对性能产生重大影响(特别是如果数据集比可用内存大得多)，并且需要更长时间恢复，因为需要重新构建所有数据文件和索引。

有关备份策略的一般比较，请参见备份及其在灾难恢复中的作用。在此比较中引用的MMS产品现在被称为MongoDB云管理器，但是一般的注意事项和比较点仍然适用。