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 的任何更改都需要反映在磁盤上（重命名組/用戶或項目時）. 在大型安裝中，這可能會增加很多負載，尤其是在使用任何類型的基于網絡的文件系統時.