将副本集实时迁移（拉取）到 Atlas（MongoDB 6.0.13 之前的版本）

迁移路径

Atlas 实时迁移（提取）支持以下迁移路径：

网络访问

为以下组件配置网络权限：

迁移前验证

启动提取实时迁移过程之前， Atlas 会对源集群和目标集群运行验证检查。

• 源集群为副本集。

  如果源集群是独立集群，请先将该独立集群转换为副本集，然后再使用拉动式实时迁移。

• 目标 Atlas 集群是副本集。

源集群安全性

各种内置角色提供了足够的权限。例如：

• 对于源集群，用户必须拥有 readAnyDatabase、clusterMonitor 和 backup 角色。

  要验证将运行实时迁移过程的数据库用户是否具有这些角色，请在 admin 数据库上运行 db.getUser() 命令。

  use admin
  db.getUser("admin")
  {
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
      {
        "role" : "backup",
        "db" : "admin"
      },
      {
        "role" : "clusterMonitor",
        "db" : "admin"
      }
      {
        "role" : "readAnyDatabase",
        "db" : "admin"
      }
    ]
  } ...

  此外，源集群的数据库用户必须具有读取 admin 数据库的 oplog 的角色。如需了解更多信息，请参阅 Oplog 访问权限。

• 对于运行 MongoDB 3.4 的源集群，用户至少必须拥有 clusterMonitor 和 readAnyDatabase 角色。例如：

   use admin
   db.createUser(
     {
       user: "mySourceUser",
       pwd: "mySourceP@$$word",
       roles: [ "clusterMonitor", "readAnyDatabase" ]
     }
   )

• 对于运行 MongoDB 3.2 的源集群，用户必须至少拥有 clusterManager 和 readAnyDatabase 角色，以及对 local 数据库的读取权限。为此，需要一个自定义角色，而您可使用以下命令创建该角色：

    use admin
    db.createRole(
         {
           role: "migrate",
           privileges: [
             { resource: { db: "local", collection: "" }, actions: [ "find" ] }
           ],
           roles: ["readAnyDatabase", "clusterManager"]
         }
       )
     db.createUser(
         {
           user: "mySourceUser",
           pwd: "mySourceP@$$word",
           roles: [ "migrate" ]
         }
       )

• 对于运行 MongoDB 2.6 或 3.0 的源集群，用户必须至少拥有 readAnyDatabase 角色。例如：

    use admin
       db.createUser(
         {
           user: "mySourceUser",
           pwd: "mySourceP@$$word",
           roles: [ "readAnyDatabase" ]
         }
       )

根据实时迁移过程提示指定 Atlas 用户名和密码。

Atlas 仅支持使用 SCRAM 连接到强制执行身份验证的源集群。

MongoDB 3.0 开始支持 SCRAM 身份验证。如果源集群 运行的是 MongoDB 2.6，则可以使用拉动式实时迁移进行迁移， 而无需启用 SCRAM 身份验证。

如果源集群使用不同的身份验证机制进行连接，则您可使用 mongomirror 将数据从源集群迁移到目标 Atlas 群集。

MongoDB 如何保护实时迁移服务器

向 Atlas 进行任何提取式实时迁移时， Atlas 会管理运行实时迁移的服务器，并将数据从源集群发送到目标集群。

MongoDB 采取以下措施来保护您的数据在传输到 Atlas 过程中的 完整性和保密性：

• MongoDB 会对 Atlas 托管的实时迁移服务器和目标集群之间的传输数据进行加密。如果需要对源集群和 Atlas 托管的迁移服务器之间传输的数据进行加密，请在源集群上配置 TLS。

• MongoDB 保护对 Atlas 托管的迁移服务器实例的访问， 就像保护对 Atlas 其他部分的访问一样。

• 在需要干预以调查和恢复关键服务的极少数情况下，MongoDB 遵循最低权限原则，仅授权一小部分有权限的用户在修复关键问题所需的最短时间内访问 Atlas 集群。MongoDB 要求这些用户使用 MFA 登录 Atlas 集群，并通过堡垒主机建立 SSH 连接。授予此类特权用户访问权限需要获得 MongoDB 高级管理层的批准。MongoDB 不允许任何其他 MongoDB 人员访问您的 MongoDB Atlas 集群。

• MongoDB 仅允许将特权用户帐户用于特权活动。要执行非特权活动，特权用户必须使用单独的帐户。特权用户帐户不能使用共享凭据。特权用户帐户必须遵守 Atlas 安全白皮书第 4.3.3 节所述的密码要求。

• 您可以在 Atlas 中限制包括特权用户在内的所有 MongoDB 人员访问集群。如果您选择限制此类访问，而 MongoDB 认为该访问对于解决支持问题是必要的，则 MongoDB 必须首先请求您的许可，然后您可以决定是否临时恢复特权用户的访问权限，恢复时间最长不超过 24 小时。您可以随时撤销授予 24 小时临时访问权限。启用此限制可能会导致响应和解决支持问题的时间增加，从而对 Atlas 集群的可用性产生负面影响。

• MongoDB 每季度审查一次特权用户访问授权。 此外，MongoDB 还会在不再需要特权用户访问权限时取消其访问权限， 包括在该特权用户更换角色或离开公司后 24 小时内 取消其访问权限。我们还会记录 MongoDB 人员对 Atlas 集群的 任何访问权限，并将审核日志保留至少六年， 其中包括时间戳、行为者、操作和输出。MongoDB采用 自动和手动审查相结合的方式来扫描这些审核日志。

如需了解有关 Atlas 安全的更多信息，请参阅“Atlas 安全”白皮书。请特别查看“MongoDB 人员访问 MongoDB Atlas 集群”部分。

索引键值限制

如果 MongoDB 部署包含的索引的键值超过索引键值限制，则在启动实时迁移之前修改索引，使其不包含过大的键值。

### 网络加密

提取实时迁移期间，如果源集群不对数据使用 TLS 加密， 则从源集群到 Atlas 的流量不会加密。 开始提取实时迁移过程之前， 确定是否可以接受这种情况。

数据库用户和角色

Atlas 不会将任何用户或角色数据迁移到目标集群。

如果源集群不使用身份验证，则必须在 Atlas 中创建用户， 因为 Atlas 不支持在没有身份验证的情况下运行。

如果源集群强制执行身份验证，则必须重新创建应用程序在目标 Atlas 集群上使用的凭证。Atlas 使用 SCRAM 进行用户身份验证。如需了解更多信息，请参阅“配置数据库用户”。

MongoDB 3.0 开始支持 SCRAM 身份验证。如果源集群 运行的是 MongoDB 2.6，则可以使用拉动式实时迁移进行迁移， 而无需启用 SCRAM 身份验证。

目标集群配置

配置目标集群时，请考虑以下几点：

• 实时迁移进程通过 MongoDB 托管的实时迁移服务器流式传输数据。 每台服务器都运行在距离源集群最近的地区 所托管的基础架构上。以下地区可用：

  欧洲

  • 法兰克福

  • 爱尔兰

  • London

  Americas

  • 美国东部

  • 美国西部

  亚太地区

  • 孟买

  • 新加坡

  • 悉尼

  • Tokyo

• 使用 Atlas 中与源集群上托管的应用程序服务器或部署相比，网络延迟最小的目标集群云区域。理想情况下，您的应用程序服务器应在云中运行，与目标 Atlas 集群的主区域位于同一区域。要了解更多信息，请参阅云提供商。

• Atlas 中的目标集群必须在 RAM、CPU 和存储方面与源部署相匹配或超过源部署。配置足够大的目标集群，使其能够同时容纳迁移过程和预期工作负载，或将目标集群扩展到具有更强处理能力、更高带宽或更高磁盘 IO 的层级。

• 要最大限度地提高迁移性能，目标集群至少要使用 M40 集群。 迁移大型数据集时，请使用配置 6000 IOPS 或更高的磁盘的 M80 集群。

  您还可以选择在迁移过程中临时增加目标 Atlas 集群的大小。

  将应用程序的工作负载迁移到Atlas中的集群后，请联系支持以获取进一步性能调优和目标集群大小调整方面的帮助，从而最大限度地降低成本。

• 为避免意外的大小更改，请禁用目标集群上的自动扩展功能。要了解更多信息，请参阅管理集群。

• 为了防止oplog集合无限制增长，并确保实时迁移的延迟窗口保持在oplog复制延迟窗口的范围内，请在实时迁移进程中将oplog大小设立为足够大的固定值。

  要了解详情，请参阅：

  • 扩展集群

  • Atlas 配置选项

  • Cluster-to-Cluster Sync 文档中的 oplog大小调整 。

  如果您在遵循这些建议后仍发现性能问题，请联系支持人员。

• 目标 Atlas 集群必须是副本集。

• 您无法选择 M0（免费套餐）或 M2/M5 共享层集群作为实时迁移的目标集群。

• 使用此页面上的程序无法将集群迁移到 MongoDB v6.0 或更高版本。

  如果源集群和目标集群运行的是 MongoDB 6.0.13 或更高版本，则可以使用此过程实时迁移到 Atlas。

• 当 Atlas 实时迁移正在运行时，请勿更改 featureCompatibilityVersion 标志。

避免目标集群上的工作负载

避免在目标集群上运行任何工作负载， 包括可能在与实时迁移进程不重叠的命名空间上运行的工作负载。 此操作可避免 实时迁移进程中潜在的锁定冲突和性能下降。

请勿对同一目标集群同时执行多个迁移。

在实时迁移进程同步时，请勿启动应用程序到目标集群的切换进程。

避免云备份

在实时迁移期间，Atlas 停止拍摄目标集群的按需云备份快照。一旦您完成本页面实时迁移过程中的切换步骤，Atlas 将根据备份策略，恢复拍摄云备份快照。

避免命名空间更改

在迁移过程中，不要对命名空间进行任何更改，例如使用 renameCollection 命令或执行包含 $out 聚合阶段的聚合管道。

避免选举

在源群集或目标群集出现临时网络中断和选举时， 实时迁移进程会尽最大努力继续迁移。 但是，这些事件可能会导致实时迁移进程失败。 如果实时迁移进程无法自动恢复，请重新启动。

迁移前检查清单

在开始实时迁移过程之前：

• 如果您还没有目标集群，请创建新的 Atlas 部署并根据需要进行配置。有关创建 Atlas 集群的完整文档，请参阅创建集群。

• 部署 Atlas 集群后， 请确保您可以从运行应用程序的所有客户端硬件将连接到该集群。测试 您的连接字符串有助于确保您的数据迁移过程 可以在最短的停机时间内完成。

  1. 如果您尚未安装 mongosh，请下载并安装到代表性的客户端机器。

  2. 使用 Atlas UI 中的连接字符串连接到目标集群。更多信息，请参阅通过 mongosh 连接。

  一旦您验证与目标集群的连接，请启动实时迁移过程。

步骤

A migration to your Atlas cluster will expire in <number> hours!
Navigate to your destination cluster to start the cutover process. If
you don't take any action within <number> hours, the migration will be
cancelled and you will need to start again. You can also extend the
migration process if you need more time.