Automatic background verification · Gitlab 中文文檔

# Automatic background verification > 原文：[https://docs.gitlab.com/ee/administration/geo/disaster_recovery/background_verification.html](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/background_verification.html) * [Disabling or enabling the automatic background verification](#disabling-or-enabling-the-automatic-background-verification) * [Repository verification](#repository-verification) * [Using checksums to compare Geo nodes](#using-checksums-to-compare-geo-nodes) * [Repository re-verification](#repository-re-verification) * [Reset verification for projects where verification has failed](#reset-verification-for-projects-where-verification-has-failed) * [Reconcile differences with checksum mismatches](#reconcile-differences-with-checksum-mismatches) * [Current limitations](#current-limitations) # Automatic background verification[](#automatic-background-verification-premium-only "Permalink") **注意：**在 GitLab EE 10.6 中添加了存儲庫和 Wiki 的自動背景驗證，但默認情況下僅在 GitLab EE 11.1 上啟用了該功能. 您可以按照[以下說明](#disabling-or-enabling-the-automatic-background-verification)手動禁用或啟用此功能. 自動背景驗證可確保傳輸的數據與計算出的校驗和匹配. 如果**主**節點上數據的校驗和與**輔助**節點上數據的校驗和匹配，則數據傳輸成功. 在計劃的故障轉移之后，根據損壞的程度，任何損壞的數據都可能**丟失** . 如果在**主**節點上驗證失敗，則表明 Geo 正在復制損壞的對象. 您可以從備份中還原它，也可以從**主**節點中將其刪除以解決問題. 如果驗證在**主**節點上成功，但在**輔助**節點上失敗，則表明在復制過程中對象已損壞. Geo 積極嘗試糾正驗證失敗，將存儲庫標記為有退避期重新同步. 如果您想重置這些失敗的驗證，則應遵循[以下說明](background_verification.html#reset-verification-for-projects-where-verification-has-failed) . 如果驗證明顯落后于復制，請考慮在安排計劃的故障轉移之前給節點更多時間. ## Disabling or enabling the automatic background verification[](#disabling-or-enabling-the-automatic-background-verification "Permalink") 在**主**節點上的 Rails 控制臺中運行以下命令： ``` gitlab-rails console ``` 要檢查是否啟用了自動背景驗證： ``` Gitlab::Geo.repository_verification_enabled? ``` 要禁用自動背景驗證： ``` Feature.disable('geo_repository_verification') ``` 要啟用自動背景驗證： ``` Feature.enable('geo_repository_verification') ``` ## Repository verification[](#repository-verification "Permalink") 導航到 **管理區>** 在**主**節點上的**地理**儀表板，并展開該節點的" **驗證信息"**選項卡以查看存儲庫和 Wiki 的自動校驗和狀態. 成功以綠色顯示，待處理的工作以灰色顯示，失敗以紅色顯示. [![Verification status](https://img.kancloud.cn/8e/d2/8ed292ff592bc515499b96e46d08c1ed_1256x286.png)](img/verification-status-primary.png) 導航到 **管理區>** **輔助**節點上的**地理**儀表板，并展開該節點的" **驗證信息"**選項卡，以查看存儲庫和 Wiki 的自動驗證狀態. 與校驗和一樣，成功顯示為綠色，待處理工作顯示為灰色，失敗顯示為紅色. [![Verification status](https://img.kancloud.cn/9e/ba/9ebaa132de8a1e9fb7424f228c240146_1258x294.png)](img/verification-status-secondary.png) ## Using checksums to compare Geo nodes[](#using-checksums-to-compare-geo-nodes "Permalink") 要檢查 Geo **輔助**節點的運行狀況，我們在 Git 引用及其值的列表上使用校驗和. 校驗和包括`HEAD` ， `heads` ， `tags` ， `notes`和特定于 GitLab 的引用，以確保真正的一致性. 如果兩個節點具有相同的校驗和，則它們肯定擁有相同的引用. 我們在每次更新后為每個節點計算校驗和，以確保它們都同步. ## Repository re-verification[](#repository-re-verification "Permalink") 在 GitLab 企業版 11.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/8550) . 在[GitLab Premium 中](https://about.gitlab.com/pricing/)可用. 由于錯誤或臨時基礎架構故障，Git 存儲庫可能會發生意外更改，而不會被標記為要進行驗證. Geo 會不斷重新驗證存儲庫以確保數據的完整性. 盡管可以設置短至 1 天的間隔，但默認和建議的重新驗證間隔是 7 天. 較短的時間間隔可以降低風險，但會增加負載，反之亦然. 導航到 **管理區>** 在**主**節點上**的地理**信息中心，并單擊**編輯**按鈕為所述**主**節點來定制最小重新驗證間隔： [![Re-verification interval](https://img.kancloud.cn/ec/de/ecdec605ffc1eb55d731719f1f57e378_2530x818.png)](img/reverification-interval.png) 默認情況下，自動后臺重新驗證處于啟用狀態，但是如果需要，您可以將其禁用. 在**主**節點上的 Rails 控制臺中運行以下命令： ``` gitlab-rails console ``` 要禁用自動后臺重新驗證： ``` Feature.disable('geo_repository_reverification') ``` 要啟用自動后臺重新驗證： ``` Feature.enable('geo_repository_reverification') ``` ## Reset verification for projects where verification has failed[](#reset-verification-for-projects-where-verification-has-failed "Permalink") Geo 積極嘗試糾正驗證失敗，將存儲庫標記為有退避期重新同步. 如果要手動重置它們，此 Rake 任務會將項目標記為驗證失敗或校驗和不匹配的項目重新同步而沒有退避期：對于存儲庫： ``` sudo gitlab-rake geo:verification:repository:reset ``` 對于 Wiki： ``` sudo gitlab-rake geo:verification:wiki:reset ``` ## Reconcile differences with checksum mismatches[](#reconcile-differences-with-checksum-mismatches "Permalink") 如果**主**節點和**輔助**節點的校驗和驗證不匹配，則原因可能不明顯. 要查找校驗和不匹配的原因： 1. 導航到 **管理區>** 在**主**節點上的" **概述">"項目"**儀表板中，找到要檢查校驗和差異的項目，然后單擊" **編輯"**按鈕： [![項目儀表板](https://img.kancloud.cn/a6/80/a68011aad6ebf86e2cd6b8e41de17ebe_2544x582.png)](img/checksum-differences-admin-projects.png) 2. 在項目管理頁面上，獲取**Gitaly 存儲名稱**和**Gitaly 相對路徑** ： [![項目管理頁面](https://img.kancloud.cn/65/2b/652b7e7ec4af48b572672df8959d8d89_2528x1294.png)](img/checksum-differences-admin-project-page.png) 3. 導航到**主**節點和**輔助**節點上的項目的存儲庫目錄（路徑通常是`/var/opt/gitlab/git-data/repositories` ）. 請注意，如果`git_data_dirs`是自定義的，請確保檢查服務器上的目錄布局. ``` cd /var/opt/gitlab/git-data/repositories ``` 4. 在**主**節點上運行以下命令，將輸出重定向到文件： ``` git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-node-refs ``` 5. 在**輔助**節點上運行以下命令，將輸出重定向到文件： ``` git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-node-refs ``` 6. 復制同一系統上先前步驟中的文件，并在內容之間進行區分： ``` diff primary-node-refs secondary-node-refs ``` ## Current limitations[](#current-limitations "Permalink") 自動后臺驗證不包括附件，LFS 對象，作業工件以及文件存儲中的用戶上傳. 您可以跟蹤進度，以將其包括在" [地理位置"中：驗證所有復制的數據](https://gitlab.com/groups/gitlab-org/-/epics/1430) . 現在，您可以通過在兩個節點上遵循[以下說明](../../raketasks/check.html)并比較它們之間的輸出來手動驗證其完整性. 在 GitLab EE 12.1 中，Geo 會在傳輸后計算輔助節點上的附件，LFS 對象和已歸檔跟蹤的校驗和，并將其與存儲的校驗和進行比較，如果不匹配則拒絕傳輸. 請注意，如果在 GitLab EE 12.1 之前已經同步了這些數據，Geo 當前不支持自動驗證這些數據的方法. 對象存儲中的數據**未經驗證** ，因為對象存儲負責確保數據的完整性.