使用直接迁移迁移 GitLab

您可以通过直接迁移迁移 GitLab 组：

• 从 GitLab Self-Managed 和 GitLab Dedicated 迁移到 GitLab.com
• 从 GitLab.com 迁移到 GitLab Self-Managed 和 GitLab Dedicated
• 从一个 GitLab Self-Managed 或 GitLab Dedicated 实例迁移到另一个
• 在同一个 GitLab 实例内

直接迁移会创建组的新副本。如果您想移动组而不是复制组，并且这些组在同一个 GitLab 实例中，您可以转移组。转移组而不是迁移它们是更快更完整的选择。

您可以通过两种方式迁移组：

• 通过直接迁移（推荐）。
• 通过上传导出文件。

如果您从 GitLab.com 迁移到 GitLab Self-Managed 或 GitLab Dedicated 实例，管理员可以在该实例上创建用户。

在 GitLab Self-Managed 和 GitLab Dedicated 上，默认情况下迁移组项目不可用。要显示该功能，管理员可以在应用设置中启用它。

通过直接迁移迁移组会将组从一个地方复制到另一个地方。您可以：

• 一次复制多个组。
• 在 GitLab UI 中，将顶级组复制到：
  • 另一个顶级组。
  • 任何现有顶级组的子组。
  • 另一个 GitLab 实例，包括 GitLab.com。
• 在 API 中，将顶级组和子组复制到这些位置。
• 复制带项目或不带项目的组。 在 GitLab.com 上，默认情况下可以复制带项目的组。

并非所有组和项目资源都会被复制。请参阅下面的已复制资源列表：

• 已迁移的组项目。
• 已迁移的项目项目。

开始迁移后，您不应对源实例上的导入组或项目进行任何更改，因为这些更改可能不会复制到目标实例。

我们邀请您在反馈问题中留下关于直接迁移的反馈。

迁移特定项目

在 GitLab UI 中使用直接迁移迁移组会迁移组中的所有项目。如果您只想使用直接迁移迁移组中的特定项目，您必须使用 API。

已知问题

• 由于 问题 406685，文件名长度超过 255 个字符的文件不会被迁移。
• 在 GitLab 16.1 及更早版本中，您不应将直接迁移与计划扫描执行策略一起使用。
• 有关其他已知问题的列表，请参阅史诗 6629。
• 在 GitLab 16.9 及更早版本中，由于 问题 438422，您可能会看到 DiffNote::NoteDiffFileCreationError 错误。当此错误发生时，合并请求差异上的注释差异缺失，但注释和合并请求仍会被导入。
• 当从源实例映射时，共享成员会被映射为目标实例上的直接成员，除非这些成员资格已存在于目标实例上。这意味着将源实例上的顶级组导入到目标实例上的顶级组时，总是映射到项目中的直接成员，即使源顶级组包含必要的共享成员资格层次结构详细信息。对共享成员资格的完整映射的支持已在问题 458345中提出。
• 在 GitLab 17.0、17.1 和 17.2 中，导入的史诗和工作项被映射到导入用户而不是原始作者。

估算迁移持续时间

估算直接迁移的持续时间很困难。以下因素会影响迁移持续时间：

• 源和目标 GitLab 实例上可用的硬件和数据库资源。源和目标实例上的更多资源可以导致更短的迁移持续时间，因为：
  • 源实例接收 API 请求，并提取和序列化要导出的实体。
  • 目标实例运行作业并在其数据库中创建实体。
• 要导出的数据的复杂性和大小。例如，假设您要迁移两个不同的项目，每个项目有 1000 个合并请求。如果一个项目的合并请求上有更多的附件、评论和其他项目，这两个项目可能需要非常不同的时间来迁移。因此，项目上的合并请求数量是预测项目迁移需要多长时间的不良指标。

没有确切的公式可以可靠地估算迁移。但是，每个流水线线工导入项目关系的平均持续时间可以帮助您了解导入项目可能需要多长时间：

尽管很难预测迁移持续时间，但我们已经看到：

• 100 个项目（19.9k 个问题，83k 个合并请求，100k+ 个流水线）在 8 小时内完成迁移。
• 1926 个项目（22k 个问题，160k 个合并请求，110 万个流水线）在 34 小时内完成迁移。

如果您正在迁移大型项目并遇到超时或迁移持续时间问题，请参阅减少迁移持续时间。

减少迁移持续时间

以下是一些减少使用直接迁移的迁移持续时间的策略。

向目标实例添加 Sidekiq 线工

单个直接迁移每次导入运行五个实体（组或项目），无论目标实例上有多少可用线工。 目标实例上的更多 Sidekiq 线工可以减少导入每个实体所需的时间，只要实例有足够的资源来处理额外的并发作业。 在 GitLab 16.8 及更高版本中，随着关系批量导入和导出的引入，目标实例上可用线工的数量变得更加重要。

有关如何向目标实例添加 Sidekiq 线工的更多信息，请参阅 Sidekiq 配置。

重新分配大型项目或启动单独的迁移

源实例上的线工数量应足以并行导出 5 个并发实体（对于每个正在运行的导入）。否则，当目标实例等待导出的数据可用时，可能会有延迟和潜在的超时。

将项目分配到不同的组有助于避免超时。如果多个大型项目在同一组中，您可以：

1. 将大型项目移动到不同的组或子组。
2. 为每个组和子组启动单独的迁移。

GitLab UI 只能迁移顶级组。使用 API，您也可以迁移子组。

限制

直接迁移应用硬编码限制。

还有可配置的限制。

在 GitLab 16.3 及更高版本中，以下先前硬编码的设置是可配置的：

• 可从源实例下载的最大关系大小（设置为 5 GiB）。
• 解压缩归档的最大大小（设置为 10 GiB）。

您可以使用以下 API 测试最大关系大小限制：

• 组关系导出 API。
• 项目关系导出 API

如果任一 API 生成的文件大于最大关系大小限制，直接迁移组将失败。

可见性规则

迁移后：

• 私有组和项目保持私有。
• 内部组和项目：
  • 复制到内部组时保持内部状态，除非内部可见性被限制。在这种情况下，组和项目变为私有。
  • 复制到私有组时变为私有。
• 公共和项目：
  • 复制到公共组时保持公共状态，除非公共可见性被限制。在这种情况下，组和项目变为内部。
  • 复制到内部组时变为内部，除非内部可见性被限制。在这种情况下，组和项目变为私有。
  • 复制到私有组时变为私有。

如果您在源实例上使用私有网络向公众隐藏内容，请确保在目标实例上有类似的设置，或者导入到私有组中。

直接迁移过程

请参阅使用直接迁移迁移组和项目。