Geo 与对象存储

对象存储中文件的验证功能在 GitLab 16.4 中通过一个名为 geo_object_storage_verification 的功能标志引入。默认情况下已启用。

Geo 可以与对象存储（AWS S3 或其他兼容的对象存储）结合使用。

Secondary 站点可以使用以下方式之一：

• 与 primary 站点相同的存储桶。
• 一个已复制的存储桶。
• 如果主站点使用本地存储，则使用本地存储。

文件的存储方法（本地存储或对象存储）会记录在数据库中，并且该数据库会从 primary Geo 站点复制到 secondary Geo 站点。

当访问一个已上传的对象时，我们会从数据库中获取其存储方法（本地存储或对象存储），因此 secondary Geo 站点的存储方法必须与 primary Geo 站点保持一致。

因此，如果 primary Geo 站点使用对象存储，那么 secondary Geo 站点也必须使用它。

要实现：

• 由 GitLab 管理复制，请遵循启用 GitLab 复制中的步骤。
• 由第三方服务管理复制，请遵循第三方复制服务中的步骤。

有关 GitLab 管理的复制与第三方复制之间的比较，请参阅对象存储复制测试。

了解有关在 GitLab 中使用对象存储的更多信息。

启用 GitLab 管理的对象存储复制

Secondary 站点可以复制 primary 站点上存储的文件，无论这些文件是存储在本地文件系统还是对象存储中。

要启用 GitLab 复制：

1. 在左侧边栏的底部，选择 管理员。
2. 选择 Geo > 节点。
3. 在 secondary 站点上选择 编辑。
4. 在 同步设置 部分，找到 允许此辅助节点复制对象存储上的内容 复选框并启用它。

对于 LFS，请按照文档设置 LFS 对象存储。

对于 CI 作业产物，有类似的文档可用于配置作业产物对象存储。

对于用户上传，有类似的文档可用于配置上传对象存储。

如果要将 primary 站点的文件迁移到对象存储，可以通过以下几种方式配置 secondary 站点：

• 使用完全相同的对象存储。
• 使用单独的对象存储，但利用对象存储解决方案的内置复制功能。
• 使用单独的对象存储，并启用 允许此辅助节点复制对象存储上的内容 设置。

GitLab 不支持以下两种情况同时存在：

• primary 站点使用本地存储。
• secondary 站点使用对象存储。

迁移后的不一致性

从本地存储迁移到对象存储时，可能会发生数据不一致，这在对象存储故障排除部分中有进一步说明。

第三方复制服务

使用 Amazon S3 时，您可以使用跨区域复制 (CRR)在 primary 站点使用的存储桶和 secondary 站点使用的存储桶之间进行自动复制。

如果您使用的是 Google Cloud Storage，可以考虑使用多区域存储。或者，您可以使用存储传输服务，尽管它仅支持每日同步。

对于手动同步，或通过 cron 计划的同步，请参阅：

• s3cmd sync
• gsutil rsync