将数据从 MongoDB 迁移到 Azure DocumentDB 的选项有哪些？

本文可帮助你规划和执行从 MongoDB 到 Azure DocumentDB 的迁移。 它介绍了可用的迁移工具、迁移的关键阶段，以及降低风险和最小化停机时间的最佳做法。

无论是从本地 MongoDB 服务器、云托管的 VM 还是托管的 MongoDB 服务进行迁移，本文中的迁移选项、指南和最佳做法都适用。

关键迁移阶段

成功的迁移遵循这些不同的阶段。 每个阶段都有特定的目标和成功标准。

1. 评估

使用 Azure DocumentDB 迁移扩展自动扫描源 MongoDB，以识别不支持的功能、命令、查询语法和索引类型。 评估还提供了 MongoDB 版本、许可证、实例类型和数据库和集合指标的概述。 使用这些发现来规划架构更改，并在迁移之前识别任何所需的重构。

2. 准备

分析评估报告并测量源 TPS （每秒事务数）。 对代表性数据运行试用迁移，以建立目标计算层、存储层和分片计数。 执行性能测试，以确保目标配置满足你的要求。

在开始迁移之前，请记录生存时间（TTL）索引的定义，并从源集合中删除这些索引。 确保在迁移或最终数据验证期间目标集合没有 TTL 索引。 迁移和验证完成后，使用记录的定义在目标上创建 TTL 索引。

3. 优化

使用与生产查询模式匹配的相应分片键和索引准备目标集合。 如果使用多个分片，请决定如何在分片之间分配集合，以平衡负载并最大程度地减少跨分片操作。

4. 迁移

运行迁移作业以脱机或联机模式移动数据：

• 脱机迁移：在启动时拍摄源的快照，并将其批量复制到目标。 此过程不会复制快照后在源上添加、更新或删除的任何数据。 所需的停机时间取决于大容量复制需要多长时间。
• 联机迁移：执行与脱机相同的大容量复制，同时在整个过程中监视更改流。 迁移期间所做的更改将复制到目标，因此所需的应用程序停机时间最少。 此方法需要变更流和源上足够大的 oplog。

有关可用工具，请参阅 迁移工具。

5. 验证

验证迁移过程是否复制了所有数据，包括最新更新。 比较文档计数、运行基于示例的验证，并验证索引和数据结构是否符合目标的预期。 使用自动化脚本使验证可重复且一致。

6. 割接

将读取流量移动到目标，并验证没有功能或性能问题。 读取验证成功后，将写入流量移到目标端。 在割接窗口期间，密切监视是否存在任何异常。

迁移工具

本文中讨论的工具有助于从以下源迁移 MongoDB 工作负载：

• MongoDB 虚拟机
• MongoDB Atlas
• AWS DocumentDB

Azure DocumentDB 迁移扩展

使用 Azure DocumentDB 迁移扩展在 Visual Studio Code 中创建和管理迁移作业。 此解决方案旨在简化、安全性和零停机时间。

此工具提供了明确的分步指南，可帮助你迁移工作负载，而不会造成服务中断。 您可以：

• 选择要迁移的特定数据库和集合
• 在熟悉的 VS Code 接口中执行所有步骤
• 在整个过程中确保安全连接
• 享受使用扩展的零成本

通过使用 Azure DocumentDB 迁移扩展，可以在保持控制和安全性的同时简化迁移过程，而无需额外的基础结构或复杂性。

Azure 数据库迁移服务

使用 Azure 数据库迁移服务 在 Azure 门户中创建和管理迁移作业。 如果不想安装Visual Studio Code扩展，请使用门户体验。

Azure 数据库迁移服务支持：

• 联机和脱机迁移。
• 公共连接和专用连接。
• 选择和配置单个数据库和集合。
• 关闭门户后仍会继续进行的 Azure 托管迁移执行。

Web 应用实用工具 （已弃用）

如果维护使用 Web 应用实用工具的现有迁移，请参阅 MongoMigrationwebBasedUtility 存储库 ，了解部署和使用说明。 该实用工具支持联机和脱机迁移，并且可以在虚拟网络中私下部署。

主要功能包括：

• 连接丢失或暂时性错误后自动恢复
• 用于配置迁移的图形界面
• 访问 C# 源代码
• 支持迁移性能扩展的可自定义 Azure 应用服务 计划

原生 MongoDB 工具（脱机）

还可以使用本机 MongoDB 工具（例如 mongodump/mongorestore、 mongoexport/mongoimport ）将数据集脱机（无需复制实时更改）迁移到 Azure DocumentDB 产品/服务。

• mongoexport/mongoimport 是迁移 MongoDB 数据库子集的最佳迁移工具组合。
  • mongoexport 将现有的数据导出为可读的 JSON 或 CSV 文件。 mongoexport 通过一个参数来指定要导出的现有数据的子集。
  • mongoimport 打开 JSON 或 CSV 文件，并将内容插入目标数据库实例（在本例中为 Azure DocumentDB）。
  • JSON 和 CSV 不是紧凑格式。 当 mongoimport 将数据发送到 Azure DocumentDB 时，可能会产生多余的网络费用。
• mongodump/mongorestore 是迁移整个 MongoDB 数据库的最佳迁移工具组合。 压缩的 BSON 格式可以更有效地使用网络资源，因为数据插入到 Azure DocumentDB 中。
  • mongodump 会将现有数据导出为 BSON 文件。
  • mongorestore 将 BSON 文件转储的数据导入 Azure DocumentDB。

迁移最佳做法

以下流程图展示了应用程序和迁移团队在切换之前、期间和之后如何协调，以成功完成从 MongoDB 到 Azure DocumentDB 的迁移。

切换流程

在联机迁移切换期间，迁移工具会查找源集合没有更改的时间窗口，以便它可以完成复制挂起的更改并完成迁移。 在迁移开始之前删除源 TTL 索引，并在切换时停止应用程序写入以创建此无更改窗口。 如果写入或 TTL 驱动的删除继续，该工具可能无法找到无更改窗口，并且切换过程可能会一直处于进行中，直到这些更改停止。

协调应用程序和迁移团队以按顺序完成以下过程：

1. 应用程序团队确定低流量切换窗口，并将其传达给两个团队。
2. 迁移团队比较 MongoDB 和 Azure DocumentDB 集合，确认它们已同步，并通知应用程序团队。
3. 在切换窗口开始时，应用程序团队停止应用程序向 MongoDB 写入数据。 此操作是第一个控制点。
4. 迁移团队确认 TTL 索引在源集合和目标集合中都不存在，以防止在最终同步和验证期间进行后台删除。
5. 应用程序团队向迁移团队确认所有源写入都已停止。
6. 迁移团队在迁移工具中启动切换。
7. （可选）迁移团队会再次比较 MongoDB 和 Azure DocumentDB 集合。 确认集合完全同步后，迁移团队会通知应用程序团队。
8. 迁移和最终数据验证完成后，迁移团队将使用迁移前记录的定义在目标上创建 TTL 索引。
9. 应用程序团队将应用程序的写入操作重定向到 Azure DocumentDB。 此操作是第二个控制点。
10. 应用程序团队监视流量、应用程序运行状况和数据库写入。
11. 这两个团队都查看结果并确认已完成的迁移。

使用这些最佳做法可以降低风险、更准确地估计容量、提高迁移速度并安全地执行直接转换。

减少故障

• 在连接字符串中使用 URL 编码的密码。 特殊字符（例如 @、# 和 :）如果不对这些字符进行编码，可能导致解析失败。 URL 编码有助于避免在评估和迁移运行期间出现连接失败。

• 在迁移之前执行预迁移评估。 评估可帮助你提前识别不受支持的功能、兼容性差距和潜在阻止程序。 解决迁移前发现的问题，以减少切换期间的返工。

• 在生产之前练习迁移和切换。 在非生产环境中进行一次或多次演练迁移。 实践可提高时间安排的准确性、团队准备和生产切换期间的信心。

精确确定基础设施规模

• 在小型但具有代表性的数据集上运行试用迁移。 使用试用版捕获实际吞吐量、延迟和资源消耗。 与综合测试数据相比，代表性示例提供更好的估计值。

• 推断试用结果以估计计算层、存储层和分片数。 使用观察到的测试指标，根据数据集的总体量预测最终规模需求。 如果生产数据分布与示例不同，请重新评估估算值。

• 使用接近生产环境的设置来确定代表性文档的数量、大小和结构。 在试用期间匹配生产索引和分片设置，以避免低估成本或迁移持续时间。 非生产设置可能会产生误导性的结果。

• 从试用结果估算目标存储，而不是假设源大小和目标大小相等。 由于索引定义和数据布局的差异，源和目标存储占用空间可能会有所不同。 使用试用结果通过安全缓冲区规划存储。

优化迁移速度

• 尽可能在同一区域中迁移。 在同一区域中保留源和目标可降低网络延迟并提高数据传输性能。 它还可以减少跨区域数据传输成本。

• 在迁移期间扩展，然后在切换后缩减。 例如，可以暂时将目标群集扩展到 M200，以提高迁移吞吐量。 迁移后，请缩减到受支持范围内的适当层级，以便稳定运行负载。

• 选择高级 SSD v2 磁盘以加快写入速度。 高级 SSD v2 磁盘可以显著提高写入密集型迁移性能。

仔细规划切换，因为没有回滚

• 规划低流量时段的停机时间。 停机时间取决于迁移完成后验证过程所需的时间。 低流量窗口可降低业务影响。

• 在切换之前，停止所有对源的写入操作。 此步骤可防止源和目标之间的最后一分钟分歧。 在完成切换之前，确认写入活动已完全暂停。

• 在迁移之前删除 TTL 索引，然后在目标上创建 TTL 索引。 记录源 TTL 索引定义，并在开始迁移之前删除这些索引，以便不会将其复制到目标。 在切换期间及最终数据验证期间，使源集合和目标集合都没有 TTL 索引。 源 TTL 删除可能会阻止切换所需的无更改窗口，而目标 TTL 删除可能会导致文档计数即使在复制追平后仍有所不同。 迁移和验证完成后，使用记录的定义在目标上创建 TTL 索引。 然后，在目标上恢复生效，包括在迁移期间过期的文档。

• 在移动写入之前验证迁移数据。 比较文档计数，然后运行随机示例文档比较（例如基于哈希的检查）。 尽可能使用脚本使验证可重复。

• 更新应用程序连接字符串并测试目标。 在启用生产写入之前，针对目标读操作和测试流量进行功能和性能测试验证。 确认关键路径的行为与预期相同。

• 仅在验证成功后移动写入流量。 只有在测试结果成功且可靠时，才会将生产写入操作执行到目标。 如果应用程序体系结构支持，可以使用分阶段推出。

协调各团队的努力，实现无缝迁移

• 确保来自应用、数据、基础设施、安全、网络和管理团队等所有利益相关者的支持和认同。 尽早协调期望和责任。 共享所有权减少了执行期间的误解和延迟。

• 使用规划和试运行来增强团队信心和优化流程。 没有顺利迁移的快捷方式。 试运行可以在低风险环境中发现问题，并为团队提供实践机会。

• 请将割接视为关键且需及时处理。 切换需要精确的协调和清晰的沟通。 在事情开始之前指定决策者并建立升级路径。

• 了解谁执行每个步骤、何时发生，以及如何最大程度地减少停机时间。 分配职责，建立时间线，并就成功标准达成一致。 记录 Cutover Runbook 并将其与所有参与者共享。

• 当切换需要同时更新多个工作负载时，请与所有相关方协调。 在适用于所有团队的维护时段内安排割接。 避免周五晚上或主要商业活动附近的时段。

• 不要急于操作或跳过必要的检查步骤——此操作无法撤销。 彻底验证和仔细执行可防止成本高昂的错误。 接受切换需要时间，因为专注于速度的捷径会带来风险。

相关内容

• 评估和规划迁移准备情况
• 使用 Azure 数据库迁移服务 进行迁移
• 使用 Azure DocumentDB 迁移扩展进行迁移
• 使用 MongoDB 原生工具进行迁移
• 查看支持的 MongoDB 查询语言功能