Repository storage types · Gitlab 中文文档

# Repository storage types > 原文：[https://docs.gitlab.com/ee/administration/repository_storage_types.html](https://docs.gitlab.com/ee/administration/repository_storage_types.html) * [Hashed storage](#hashed-storage) * [Translating hashed storage paths](#translating-hashed-storage-paths) * [From project name to hashed path](#from-project-name-to-hashed-path) * [From hashed path to project name](#from-hashed-path-to-project-name) * [Hashed object pools](#hashed-object-pools) * [Hashed storage coverage migration](#hashed-storage-coverage-migration) * [Avatars](#avatars) * [CI artifacts](#ci-artifacts) * [LFS objects](#lfs-objects) * [Legacy storage](#legacy-storage) # Repository storage types[](#repository-storage-types-core-only "Permalink") 版本历史 * 在 GitLab 10.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28283) . * 静默存储已成为 GitLab 12.0 中新安装的默认存储 * 默认情况下，在 GitLab 13.0 中为新项目和重命名项目启用了哈希存储. 可以将 GitLab 配置为使用一个或多个存储库存储路径/碎片位置，它们可以是： * 挂载到本地磁盘 * 公开为 NFS 共享卷 * 在自己的计算机上通过[Gitaly](gitaly/index.html)访问. 在 GitLab 中，这是通过`git_data_dirs({})`配置哈希值在`/etc/gitlab/gitlab.rb`进行配置的. 此处讨论的存储布局将适用于其中定义的所有分片. 在未自定义它的任何安装中可用的`default`存储库碎片指向本地文件夹： `/var/opt/gitlab/git-data` . 下面讨论的所有内容都应属于该文件夹. ## Hashed storage[](#hashed-storage "Permalink") **注意：**在 GitLab 13.0 中，默认情况下启用了哈希存储，并且不建议使用旧存储. 在 GitLab 14.0 中将删除对旧存储的支持. 如果您尚未迁移，请查看[迁移说明](raketasks/storage.html#migrate-to-hashed-storage) . 在管理区域中的哈希存储和旧存储之间进行选择的选项已被禁用. 哈希存储是我们从 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[](#translating-hashed-storage-paths "Permalink") 对 Git 存储库中的问题进行故障排除，添加挂钩和其他任务，将需要您在人类可读的项目名称和哈希存储路径之间进行转换. #### From project name to hashed path[](#from-project-name-to-hashed-path "Permalink") 哈希路径显示在项目页面的[admin 区域中](../user/admin_area/index.html#administering-projects) . 要访问"项目"页面，请转到" **管理区域">"概述">"项目"** ，然后打开该项目的页面. 此处显示" Gitaly 相对路径"，例如： ``` "@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git" ``` 这是默认 Omnibus 安装中`/var/opt/gitlab/git-data/repositories/`下的路径. 在[Rails 控制台中](troubleshooting/debug.html#starting-a-rails-console-session) ，使用数字项目 ID 或完整路径获取此信息： ``` Project.find(16).disk_path Project.find_by_full_path('group/project').disk_path ``` #### From hashed path to project name[](#from-hashed-path-to-project-name "Permalink") 要将哈希存储路径转换为项目名称，请执行以下操作： 1. 启动[Rails 控制台](troubleshooting/debug.html#starting-a-rails-console-session) . 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[](#hashed-object-pools "Permalink") 在 GitLab 12.1 中[引入](https://gitlab.com/gitlab-org/gitaly/-/issues/1606) . **危险：**不要在池存储库中运行`git prune`或`git gc` ！这可能会导致依赖于相关池的"实际"存储库中的数据丢失. 通过创建第三个存储库（对象池）对公共项目的分支进行重复数据删除，其中包含来自源项目的对象. 使用`objects/info/alternates` ，源项目和派生将对象池用于共享对象. 当在源项目上运行内务管理时，会将对象从源项目移动到对象池. ``` # object pool paths "@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git" ``` ### Hashed storage coverage migration[](#hashed-storage-coverage-migration "Permalink") 如果存储在 S3 兼容端点中的文件没有前缀`#{namespace}/#{project_name}` （对于 CI Cache 和 LFS 对象是正确的`#{namespace}/#{project_name}` ，则不会有前面提到的缺点. 在下表中，您可以找到迁移到哈希存储的范围. | 可存储对象 | 旧版存储 | 杂物箱 | 兼容 S3 | GitLab 版本 | | --- | --- | --- | --- | --- | | Repository | Yes | Yes | - | 10.0 | | Attachments | Yes | Yes | - | 10.2 | | Avatars | Yes | No | - | - | | Pages | Yes | No | - | - | | Docker 注册表 | Yes | No | - | - | | CI 构建日志 | No | No | - | - | | CI Artifacts | No | No | Yes | 9.4 / 10.6 | | CI 缓存 | No | No | Yes | - | | LFS 对象 | Yes | Similar | Yes | 10.0 / 10.7 | | 储存库 | No | Yes | - | 11.6 | #### Avatars[](#avatars "Permalink") 每个文件都以其`id`来自数据库的形式存储在一个文件夹中. 用户头像的文件名始终为`avatar.png` . 替换头像后， `Upload`模型将被销毁，并使用另一个`id`进行替换. #### CI artifacts[](#ci-artifacts "Permalink") CI Artifacts 从**9.4** （GitLab Premium）开始兼容 S3，从**10.6**开始在 GitLab Core 中可用. #### LFS objects[](#lfs-objects "Permalink") [GitLab 中的 LFS 对象](../topics/git/lfs/index.html)遵循 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 兼容](lfs/index.html#storing-lfs-objects-in-remote-object-storage) . ## Legacy storage[](#legacy-storage "Permalink") **不建议使用：**在 GitLab 13.0 中，默认情况下启用了哈希存储，并且不建议使用旧存储. 如果您尚未迁移，请查看[迁移说明](raketasks/storage.html#migrate-to-hashed-storage) . 在 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: 存储位置将集中大量的顶级名称空间. 可以通过引入[多个存储路径](repository_storage_paths.html)来减少影响. 由于备份是相同 URL 映射的快照，因此，如果您尝试恢复非常旧的备份，则需要验证是否有任何项目代替了共享相同 URL 的旧项目或已重命名的项目. 这意味着您备份中的`mygroup/myproject`可能与今天使用相同 URL 的原始项目不同. URL 的任何更改都需要反映在磁盘上（重命名组/用户或项目时）. 在大型安装中，这可能会增加很多负载，尤其是在使用任何类型的基于网络的文件系统时.