Disaster recovery for planned failover · Gitlab 中文文檔

# Disaster recovery for planned failover > 原文：[https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html) * [Not all data is automatically replicated](#not-all-data-is-automatically-replicated) * [Preflight checks](#preflight-checks) * [Object storage](#object-storage) * [Review the configuration of each **secondary** node](#review-the-configuration-of-each-secondary-node) * [Run system checks](#run-system-checks) * [Check that secrets match between nodes](#check-that-secrets-match-between-nodes) * [Ensure Geo replication is up-to-date](#ensure-geo-replication-is-up-to-date) * [Verify the integrity of replicated data](#verify-the-integrity-of-replicated-data) * [Notify users of scheduled maintenance](#notify-users-of-scheduled-maintenance) * [Prevent updates to the **primary** node](#prevent-updates-to-the-primary-node) * [Finish replicating and verifying all data](#finish-replicating-and-verifying-all-data) * [Promote the **secondary** node](#promote-the-secondary-node) # Disaster recovery for planned failover[](#disaster-recovery-for-planned-failover-premium-only "Permalink") The primary use-case of Disaster Recovery is to ensure business continuity in the event of unplanned outage, but it can be used in conjunction with a planned failover to migrate your GitLab instance between regions without extended downtime. 由于 Geo 節點之間的復制是異步的，因此計劃中的故障轉移需要一個維護窗口，該窗口中阻止了對**主**節點的更新. 該窗口的長度取決于您的復制能力-一旦**輔助**節點與**主**節點完全同步，就可以進行故障轉移而不會丟失數據. 本文檔假定您已經具有完整配置的，可以正常使用的 Geo 設置. 在繼續之前，請完整閱讀它和[Disaster Recovery](index.html)故障轉移文檔. 計劃內的故障轉移是一項主要操作，如果執行不正確，則存在很高的數據丟失風險. 考慮對程序進行排練，直到您對必要的步驟感到滿意并且對能夠準確執行它們有高度的信心. ## Not all data is automatically replicated[](#not-all-data-is-automatically-replicated "Permalink") 如果您使用的是 Geo [不支持的](../replication/index.html#current-limitations)任何 GitLab 功能， [則](../replication/index.html#current-limitations)必須單獨進行準備，以確保**輔助**節點具有與該功能關聯的任何數據的最新副本. 這可能會大大延長所需的計劃維護時間. 使文件中存儲的數據的時間盡可能短的常見策略是使用`rsync`傳輸數據. 可以在維護窗口之前執行初始`rsync` . 隨后的`rsync` s（包括維護窗口內的最終傳輸）將僅傳輸**主**節點和**輔助**節點之間的*更改* . 在[移動存儲庫](../../operations/moving_repositories.html)文檔中可以找到有效使用`rsync`的以存儲庫為中心的策略. 這些策略可以調整為與任何其他基于文件的數據一起使用，例如 GitLab 頁面（如果使用 Omnibus，則可在`/var/opt/gitlab/gitlab-rails/shared/pages` ）. ## Preflight checks[](#preflight-checks "Permalink") 運行此命令以列出所有預檢檢查，并在計劃計劃的故障轉移之前自動檢查復制和驗證是否完成，以確保過程順利進行： ``` gitlab-ctl promotion-preflight-checks ``` 即使預檢檢查失敗，也可以以`force`模式運行此命令以升級為主要命令： ``` sudo gitlab-ctl promotion-preflight-checks --force ``` 每個步驟將在下面更詳細地描述. ### Object storage[](#object-storage "Permalink") 如果您有大量的 GitLab 安裝或無法忍受停機，請**在**計劃計劃的故障轉移**之前**考慮[遷移到對象存儲](../replication/object_storage.html) . 這樣做既可以減少維護窗口的長度，又可以減少由于計劃內故障轉移執行不當而導致的數據丟失風險. In GitLab 12.4, you can optionally allow GitLab to manage replication of Object Storage for **secondary** nodes. For more information, see [Object Storage replication](../replication/object_storage.html). ### Review the configuration of each **secondary** node[](#review-the-configuration-of-each-secondary-node "Permalink") 數據庫設置會自動復制到**輔助**節點，但是`/etc/gitlab/gitlab.rb`文件必須手動設置，并且在節點之間有所不同. 如果在**主要**節點上啟用了 Mattermost，OAuth 或 LDAP 集成等功能，但在**次要**節點上未啟用這些功能，則它們將在故障轉移期間丟失. 查看兩個節點的`/etc/gitlab/gitlab.rb`文件，并確保**輔助**節點支持**主**節點**在**計劃計劃的故障轉移**之前**所做的一切. ### Run system checks[](#run-system-checks "Permalink") 在**主**節點和**輔助**節點上運行以下命令： ``` gitlab-rake gitlab:check gitlab-rake gitlab:geo:check ``` 如果在任一節點上報告了任何故障，則應**在**計劃計劃的故障轉移**之前**解決這些故障. ### Check that secrets match between nodes[](#check-that-secrets-match-between-nodes "Permalink") SSH 主機密鑰和`/etc/gitlab/gitlab-secrets.json`文件在所有節點上均應相同. 通過在所有節點上運行以下命令并比較輸出來進行檢查： ``` sudo sha256sum /etc/ssh/ssh_host* /etc/gitlab/gitlab-secrets.json ``` 如果有任何文件不同，請用**主**節點中的內容替換**輔助**節點上的內容. ### Ensure Geo replication is up-to-date[](#ensure-geo-replication-is-up-to-date "Permalink") 直到地理復制和驗證完成，維護窗口才會結束. 為了使窗口盡可能短，在使用過程中，應確保這些過程盡可能接近 100％. 導航到 **管理區>** **輔助**節點上的**地理**儀表板以查看狀態. 復制的對象（以綠色顯示）應接近 100％，并且不應出現故障（以紅色顯示）. 如果尚未復制大量對象（顯示為灰色），請考慮給節點更多時間來完成 [![Replication status](https://img.kancloud.cn/dd/99/dd994470e9319c617355e814c1a56908_899x291.png)](img/replication-status.png) 如果有任何對象無法復制，則應在安排維護窗口之前進行調查. 在計劃好的故障轉移之后，所有無法復制的內容都會**丟失** . 您可以使用[地理狀態 API](../../../api/geo_nodes.html#retrieve-project-sync-or-verification-failures-that-occurred-on-the-current-node)查看失敗的對象以及失敗的原因. 復制失敗的常見原因是**主**節點上缺少數據-您可以通過從備份還原數據或刪除對丟失數據的引用來解決這些故障. ### Verify the integrity of replicated data[](#verify-the-integrity-of-replicated-data "Permalink") This [content was moved to another location](background_verification.html). ### Notify users of scheduled maintenance[](#notify-users-of-scheduled-maintenance "Permalink") 在**主**節點上，導航到 **管理區>** **消息** ，添加廣播消息. 你可以檢查下 **管理區>** **地理位置，**以估算完成同步需要多長時間. 一個示例消息是： > 計劃的維護將在世界標準時間 XX：XX 進行. 我們預計將花費不到 1 個小時. ## Prevent updates to the **primary** node[](#prevent-updates-to-the-primary-node "Permalink") 在實施[只讀模式](https://gitlab.com/gitlab-org/gitlab/-/issues/14609)之前，必須防止手動進行更新. 請注意，在維護窗口期間， **輔助**節點仍需要對**主**節點具有只讀訪問權限. 1. 在計劃的時間，使用您的云提供商或節點的防火墻，阻止去往/來自**主**節點的所有 HTTP，HTTPS 和 SSH 通信， **但** IP 和**輔助**節點的 IP **除外** . 例如，您可能在組成**主**節點的服務器上運行以下命令： ``` sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT sudo iptables -A INPUT --destination-port 22 -j REJECT sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 80 -j ACCEPT sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT sudo iptables -A INPUT --tcp-dport 80 -j REJECT sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 443 -j ACCEPT sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT sudo iptables -A INPUT --tcp-dport 443 -j REJECT ``` 從這一點來看，用戶將無法查看其數據或在**主**節點上進行更改. 他們也將無法登錄到**輔助**節點. 但是，現有的會話將在維護期間的剩余時間內起作用，并且可以在整個維護期間訪問公共數據. 2. 通過使用其他 IP 在瀏覽器中訪問**主**節點，驗證**主**節點是否受到 HTTP 流量的阻止. 服務器應拒絕連接. 3. 嘗試通過使用 SSH 遠程 URL 提取現有的 Git 存儲庫，來驗證**主**節點是否已通過 SSH 流量阻止 Git. 服務器應拒絕連接. 4. 通過導航到禁用**主要**節點上的非 Geo 定期后臺作業 **管理區>** **監視>后臺作業> Cron** ，按`Disable All` ，然后為`geo_sidekiq_cron_config_worker` cron 作業按`Enable` . 該作業將重新啟用其他幾個 cron 作業，這些作業對于計劃的故障轉移成功完成至關重要. ## Finish replicating and verifying all data[](#finish-replicating-and-verifying-all-data "Permalink") 1. 如果您要手動復制不是由 Geo 管理的任何數據，請立即觸發最終復制過程. 2. 在**主**節點上，導航到 **管理區>** **監視>后臺作業>隊列，**并等待所有隊列（名稱中帶有`geo`的隊列降至 0）.這些隊列包含用戶提交的工作；在完成之前進行故障轉移將導致工作丟失. 3. 在**主**節點上，導航到 **管理區>** **地理位置，**并等待您要故障轉移到的**輔助**節點滿足以下條件： * 所有復制計量到 100％復制，0％失敗. * 所有驗證儀表均達到 100％驗證，0％失敗. * 數據庫復制滯后為 0ms. * 地理日志光標是最新的（落后 0 個事件）. 4. 在**輔助**節點上，導航到 **管理區>** **監視>后臺作業>隊列，**然后等待所有`geo`隊列下降到 0 個已排隊的作業和 0 個正在運行的作業. 5. 在**輔助**節點上，使用[以下說明](../../raketasks/check.html)來驗證 CI 工件，LFS 對象以及文件存儲中的上載的完整性. 此時， **輔助**節點將包含**主**節點擁有的所有內容的最新副本，這意味著在進行故障轉移時不會丟失任何內容. ## Promote the **secondary** node[](#promote-the-secondary-node "Permalink") 最后，按照[災難恢復文檔](index.html)將**輔助**節點升級為**主要**節點. 此過程將導致**輔助**節點發生短暫中斷，并且用戶可能需要再次登錄. 一旦完成，維護窗口就結束了！新的**主**節點現在開始發散，從舊的. 如果確實出現在這一點上的問題，沒有回到原來的**主**節點[是可能](bring_primary_back.html)的，但可能會導致在此期間上傳到新的**主**任何數據丟失. 故障轉移完成后，請不要忘記刪除廣播消息.