Repository storage types

Repository storage types

版本历史

  • 在 GitLab 10.0 中引入 .
  • 静默存储已成为 GitLab 12.0 中新安装的默认存储

可以将 GitLab 配置为使用一个或多个存储库存储路径/碎片位置，它们可以是：

  • 挂载到本地磁盘
  • 公开为 NFS 共享卷
  • 在自己的计算机上通过访问.

在 GitLab 中，这是通过配置哈希值在/etc/gitlab/gitlab.rb进行配置的. 此处讨论的存储布局将适用于其中定义的所有分片.

在未自定义它的任何安装中可用的default存储库碎片指向本地文件夹： /var/opt/gitlab/git-data . 下面讨论的所有内容都应属于该文件夹.

注意：在 GitLab 13.0 中，默认情况下启用了哈希存储，并且不建议使用旧存储. 在 GitLab 14.0 中将删除对旧存储的支持. 如果您尚未迁移，请查看迁移说明 . 在管理区域中的哈希存储和旧存储之间进行选择的选项已被禁用.

哈希存储是我们从 10.0 开始推出的存储行为. 与其耦合项目 URL 和将存储库存储在磁盘上的文件夹结构，不如基于项目 ID 耦合散列. 这使得文件夹结构不可变，因此消除了将状态从 URL 同步到磁盘结构的任何要求. 这意味着重命名组，用户或项目将仅花费数据库事务的费用，并且将立即生效.

哈希还有助于将存储库更均匀地分布在磁盘上，因此顶层目录包含的文件夹少于顶层命名空间的总数.

哈希格式基于 SHA256 的十六进制表示形式： SHA256(project.id) . 顶级文件夹使用前两个字符，然后是另一个文件夹，其后两个字符. 它们都存储在特殊的@hashed文件夹中，以便能够与现有的 Legacy Storage 项目共存：

对 Git 存储库中的问题进行故障排除，添加挂钩和其他任务，将需要您在人类可读的项目名称和哈希存储路径之间进行转换.

From project name to hashed path

哈希路径显示在项目页面的admin 区域中 .

此处显示” Gitaly 相对路径”，例如：

  1. "@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"

这是默认 Omnibus 安装中/var/opt/gitlab/git-data/repositories/下的路径.

在 ，使用数字项目 ID 或完整路径获取此信息：

From hashed path to project name

要将哈希存储路径转换为项目名称，请执行以下操作：

  1. 启动 .
  2. 运行以下命令：

该命令中带引号的字符串是您在 GitLab 服务器上找到的目录树. 例如，在默认的 Omnibus 安装上，该.git将是/var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git从目录名称的末尾删除.

输出包括项目 ID 和项目名称：

在 GitLab 12.1 中引入 .

危险：不要在池存储库中运行git prune或git gc ！ 这可能会导致依赖于相关池的”实际”存储库中的数据丢失.

通过创建第三个存储库（对象池）对公共项目的分支进行重复数据删除，其中包含来自源项目的对象. 使用objects/info/alternates ，源项目和派生将对象池用于共享对象. 当在源项目上运行内务管理时，会将对象从源项目移动到对象池.

  1. # object pool paths
  2. "@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"

如果存储在 S3 兼容端点中的文件没有前缀 （对于 CI Cache 和 LFS 对象是正确的#{namespace}/#{project_name} ，则不会有前面提到的缺点.

Avatars

每个文件都以其id来自数据库的形式存储在一个文件夹中. 用户头像的文件名始终为avatar.png . 替换头像后， Upload模型将被销毁，并使用另一个id进行替换.

CI artifacts

CI Artifacts 从9.4 （GitLab Premium）开始兼容 S3，从10.6开始在 GitLab Core 中可用.

LFS objects

GitLab 中的 LFS 对象遵循 Git 自己的实现，使用 2 个字符，2 个级别的文件夹实现了类似的存储模式：

LFS 对象也与 .

Legacy storage

不建议使用：在 GitLab 13.0 中，默认情况下启用了哈希存储，并且不建议使用旧存储. 如果您尚未迁移，请查看 . 在 GitLab 14.0 中将删除对旧存储的支持. 如果您使用的是 GitLab 13.0 及更高版本，则无法将新项目切换到旧版存储. 在管理区域中的哈希存储和旧存储之间进行选择的选项已被禁用.

旧版存储是 10.0 版之前的存储行为. 由于历史原因，GitLab 从项目 URL 复制了相同的映射结构：

  • 项目的存储库： #{namespace}/#{project_name}.git
  • 项目的 Wiki： #{namespace}/#{project_name}.wiki.git

这种结构使从现有解决方案到 GitLab 的迁移变得简单，并且管理员可以轻松找到存储库的存储位置.

On the other hand this has some drawbacks:

存储位置将集中大量的顶级名称空间. 可以通过引入多个存储路径来减少影响.

由于备份是相同 URL 映射的快照，因此，如果您尝试恢复非常旧的备份，则需要验证是否有任何项目代替了共享相同 URL 的旧项目或已重命名的项目. 这意味着您备份中的可能与今天使用相同 URL 的原始项目不同.