使用复制的集群之间的 mongodb 迁移是一个可行的选择吗？

Question

我们有一个在 Compose 上运行的托管 mongodb 3.0.11 集群，数据约为 300gb（称为 C0）。我们希望将此数据移动到在 GCP 上运行的自我管理的 mongodb 4.x 集群（称为 C1）。我已经尝试了一些用于克隆/同步数据库的 github 存储库，但它们都不能可靠地用于我的测试（老实说，我不确定我是否想使用这些未经大量测试的存储库来迁移我们的生产数据）。

在阅读有关副本集、oplog 等的 mongodb 文档时，我突然想到，也许我们可以让 mongodb 通过其内置的副本集成员添加过程为我们进行迁移。但是，由于我不是 mongodb 专家，我不知道这是否是一个可行的解决方案。

这是我感兴趣的内容 - mongodb 专家请评论这是否可行（如果您有任何基于经验的建议）：

• 将两个 mongodb 实例从 C1 作为优先级 0 的副本集成员添加到 C0
• 等待 C1.members 更新
• 进入“维护模式” - 数据库访问客户端关闭
• 强制将 C1.members 之一升级为主要成员
• 从副本集中删除所有 C0.members
• 使用新的连接字符串重新启动数据库客户端到 C1 副本集

替代方法是编写我自己的克隆器/同步器，因为到目前为止我发现的工具似乎都没有为 mongo 4.x 做好生产准备。

想法？

Answer 1

我强烈不建议将集群迁移与通过几个主要版本进行升级相结合。单独处理这些任务将有助于您在进行故障排除时限制更改范围。

如果您使用兼容的 MongoDB 服务器版本并且能够将所有成员添加到同一副本集，则可以使用您概述的一般方法在集群之间迁移。目前，滚动升级仅支持相邻的主要服务器版本，因此如果您的起点是 MongoDB 3.0.x，那么您可以直接添加到 3.0.x 副本集中的最新版本将是 3.2.x。如果您的最终目标是 4.0.x，那么您必须从 3.2 => 3.4、3.4 => 3.6 升级，最后是 3.6 => 4.0。 MongoDB Release Notes 包含每个主要版本的特定先决条件、升级过程和兼容性信息。

DBaaS 提供商通常不允许添加外部自我管理成员，因为这可能会损害他们管理的集群的安全性和稳定性。但是，DBaaS 提供商通常会自动帮助您就地升级，因此您可能希望在迁移到自我管理之前利用这一点。

从 DBaaS 进行实时迁移的最佳选择是创建一个可以访问复制 oplog 的用户，并找到适合您的用例和源/目标服务器版本的迁移工具。对于生产环境，我会谨慎尝试跨多个主要版本（例如 3.0.x 到 4.0.x）进行实时迁移，并鼓励使用单独的升级步骤进行相同版本的迁移（3.0.x => 3.0.x）。

作为一般方法，我会：

• 查看您计划的服务器和驱动程序升级的所有发布、升级和兼容性说明。
• 确保您使用的是兼容的驱动程序版本，并在升级服务器版本之前升级您的驱动程序/应用程序代码。
• 在具有代表性的暂存/QA 环境中使用生产数据的备份来测试升级过程。
• 使用升级的驱动程序/服务器版本和具有代表性的工作负载测试您的应用程序，以寻找潜在的问题，例如性能下降。