Repository storage types

原文：https://docs.gitlab.com/ee/administration/repository_storage_types.html

• Hashed storage
  • Translating hashed storage paths
    • From project name to hashed path
    • From hashed path to project name
  • Hashed object pools
  • Hashed storage coverage migration
    • Avatars
    • CI artifacts
    • LFS objects
• Legacy storage

Repository storage types

版本历史

• 在 GitLab 10.0 中引入 .
• 静默存储已成为 GitLab 12.0 中新安装的默认存储
• 默认情况下，在 GitLab 13.0 中为新项目和重命名项目启用了哈希存储.

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

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

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

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

Hashed storage

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

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

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

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

# Project's repository:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"
# Wiki's repository:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.wiki.git"

Translating hashed storage paths

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

From project name to hashed path

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

要访问”项目”页面，请转到” 管理区域”>”概述”>”项目” ，然后打开该项目的页面.

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

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

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

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

Project.find(16).disk_path
Project.find_by_full_path('group/project').disk_path

From hashed path to project name

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

1. 启动Rails 控制台 .
2. 运行以下命令：

ProjectRepository.find_by(disk_path: '@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9').project

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

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

=> #<Project id:16 it/supportteam/ticketsystem>

Hashed object pools

在 GitLab 12.1 中引入 .

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

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

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

Hashed storage coverage migration

如果存储在 S3 兼容端点中的文件没有前缀#{namespace}/#{project_name} （对于 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 个级别的文件夹实现了类似的存储模式：

"shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}"
# Based on object `oid`: `8909029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c`, path will be:
"shared/lfs-objects/89/09/029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c"

LFS 对象也与S3 兼容 .

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 的旧项目或已重命名的项目. 这意味着您备份中的mygroup/myproject可能与今天使用相同 URL 的原始项目不同.

URL 的任何更改都需要反映在磁盘上（重命名组/用户或项目时）. 在大型安装中，这可能会增加很多负载，尤其是在使用任何类型的基于网络的文件系统时.