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

迁移路径

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

网络访问

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

迁移前验证

启动实时迁移过程之前， Atlas 会对源集群和目标集群执行一系列验证检查。

• 源集群必须是分片集群。

  如果源是副本集集群，请先使用拉取式实时迁移将集群迁移到 Atlas 副本集，然后将集群扩展到分片集群。

  如果源是单节点，请先将单节点转换为副本集，然后再使用拉取式实时迁移。然后将集群扩展到分片集群。

• 源集群必须使用 CSRS（配置MongoDB Server副本集）。 请参阅副本集配置服务器。

• Atlas 必须连接到源集群中每个节点的主机名和端口。

• Atlas 必须能够停止和启动源集群上的“分片集群负载均衡器”。

• 源集群具有与目标集群相同的特征兼容性版本和主要 MongoDB 版本。完整版5.0.x中的主要 MongoDB 版本 版本为5.0 。

  要检查源集群中主机的功能兼容性版本，请从mongosh运行以下命令：

  db.runCommand( { getParameter : 1, "featureCompatibilityVersion" : 1 } )

  使用setFeatureCompatibilityVersion数据库命令根据需要设置featureCompatibilityVersion标志。

• 目标 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 身份验证。

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 进行用户身份验证。如需了解如何在 Atlas 中创建数据库用户，请参阅“配置数据库用户”。

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

源集群负载均衡器

Atlas 实时迁移在过程开始时停止源集群上的分片集群负载均衡器，并在过程结束时启动负载均衡器。

如果取消实时迁移， Atlas 会重新启动在源集群上的负载均衡器。

目标集群配置

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

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

  欧洲

  • 法兰克福

  • 爱尔兰

  • 伦敦的

  美洲

  • 美国东部

  • 美国西部

  亚太地区

  • 孟买

  • 新加坡

  • 悉尼

  • 东京

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

• 为防止 oplog 集合无限制地增长，请在实时迁移进程中设置固定的 oplog 大小。如需了解更多信息，请参阅所需访问权限和 Atlas 配置选项。

• 您不能将全球集群作为实时迁移的目标。

  重要

  开始实时迁移过程后，就无法修改目标 Atlas 集群。如需扩展目标集群，请取消实时迁移过程，扩展集群，然后重新启动实时迁移过程。

目标集群网络访问

实时迁移期间，目标集群上的mongos进程将关闭，并且通过mongos服务器的集群连接将暂停。 迁移完成后， mongos进程会自动重新启动。

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

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

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

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

避免云备份

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

避免命名空间更改

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

避免选举

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

滚动重启

迁移过程完成后，集群将一次重启一个节点。这称为滚动重启，因此，主节点上将发生故障转移。为确保平稳迁移，请考虑在将数据迁移到目标集群之前运行测试主节点故障转移过程。

取消实时迁移

您可以随时单击 Cancel取消进程。 Atlas 会显示目标集群的Sharded Cluster Live Import in Progress消息，直到集群准备好进行正常访问。

如果在实时迁移过程完成前取消过程， Atlas 不会删除在此之前迁移的任何数据。如果 使用与目标集群相同的 Atlas 集群重新启动实时迁移过程， Atlas 会清除集群中的所有数据。

测试目标集群

考虑将数据迁移到目标集群， 然后停止迁移过程并测试目标集群， 同时让源集群继续运行并向应用程序提供数据。

要使用生产数据测试目标集群，请遵循迁移过程直到测试步骤。当您准备好执行完整的迁移过程时，请跳过测试步骤并继续执行切换步骤。

迁移前检查清单

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

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

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

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

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

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

步骤