Disaster recovery for planned failover

Disaster recovery for planned failover

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故障转移文档. 计划内的故障转移是一项主要操作，如果执行不正确，则存在很高的数据丢失风险. 考虑对程序进行排练，直到您对必要的步骤感到满意并且对能够准确执行它们有高度的信心.

如果您使用的是 Geo 任何 GitLab 功能， 则必须单独进行准备，以确保辅助节点具有与该功能关联的任何数据的最新副本. 这可能会大大延长所需的计划维护时间.

使文件中存储的数据的时间尽可能短的常见策略是使用传输数据. 可以在维护窗口之前执行初始rsync . 随后的rsync s（包括维护窗口内的最终传输）将仅传输主节点和辅助节点之间的更改 .

在文档中可以找到有效使用rsync的以存储库为中心的策略. 这些策略可以调整为与任何其他基于文件的数据一起使用，例如 GitLab 页面（如果使用 Omnibus，则可在 ）.

运行此命令以列出所有预检检查，并在计划计划的故障转移之前自动检查复制和验证是否完成，以确保过程顺利进行：

即使预检检查失败，也可以以force模式运行此命令以升级为主要命令：

每个步骤将在下面更详细地描述.

如果您有大量的 GitLab 安装或无法忍受停机，请在计划计划的故障转移之前考虑迁移到对象存储 . 这样做既可以减少维护窗口的长度，又可以减少由于计划内故障转移执行不当而导致的数据丢失风险.

In GitLab 12.4, you can optionally allow GitLab to manage replication of Object Storage for secondary nodes. For more information, see .

Review the configuration of each secondary node

数据库设置会自动复制到辅助节点，但是/etc/gitlab/gitlab.rb文件必须手动设置，并且在节点之间有所不同. 如果在主要节点上启用了 Mattermost，OAuth 或 LDAP 集成等功能，但在次要节点上未启用这些功能，则它们将在故障转移期间丢失.

在主节点和辅助节点上运行以下命令：

如果在任一节点上报告了任何故障，则应在计划计划的故障转移之前解决这些故障.

Check that secrets match between nodes

SSH 主机密钥和文件在所有节点上均应相同. 通过在所有节点上运行以下命令并比较输出来进行检查：

如果有任何文件不同，请用主节点中的内容替换辅助节点上的内容.

直到地理复制和验证完成，维护窗口才会结束. 为了使窗口尽可能短，在使用过程中，应确保这些过程尽可能接近 100％.

导航到 管理区> 辅助节点上的地理仪表板以查看状态. 复制的对象（以绿色显示）应接近 100％，并且不应出现故障（以红色显示）. 如果尚未复制大量对象（显示为灰色），请考虑给节点更多时间来完成

如果有任何对象无法复制，则应在安排维护窗口之前进行调查. 在计划好的故障转移之后，所有无法复制的内容都会丢失 .

您可以使用查看失败的对象以及失败的原因.

复制失败的常见原因是主节点上缺少数据-您可以通过从备份还原数据或删除对丢失数据的引用来解决这些故障.

Verify the integrity of replicated data

This .

在主节点上，导航到 管理区> 消息 ，添加广播消息. 你可以检查下 管理区> 地理位置，以估算完成同步需要多长时间. 一个示例消息是：

在实施只读模式之前，必须防止手动进行更新. 请注意，在维护窗口期间， 辅助节点仍需要对主节点具有只读访问权限.

  1. 通过使用其他 IP 在浏览器中访问主节点，验证主节点是否受到 HTTP 流量的阻止. 服务器应拒绝连接.

  2. 尝试通过使用 SSH 远程 URL 提取现有的 Git 存储库，来验证主节点是否已通过 SSH 流量阻止 Git. 服务器应拒绝连接.

  3. 通过导航到禁用主要节点上的非 Geo 定期后台作业 管理区> 监视>后台作业> Cron ，按Disable All ，然后为geo_sidekiq_cron_config_worker cron 作业按Enable . 该作业将重新启用其他几个 cron 作业，这些作业对于计划的故障转移成功完成至关重要.

  1. 如果您要手动复制不是由 Geo 管理的任何数据，请立即触发最终复制过程.
  2. 在主节点上，导航到 管理区> 监视>后台作业>队列，并等待所有队列（名称中带有的队列降至 0）.这些队列包含用户提交的工作； 在完成之前进行故障转移将导致工作丢失.

  3. 在主节点上，导航到 管理区> 地理位置，并等待您要故障转移到的辅助节点满足以下条件：

    • 所有复制计量到 100％复制，0％失败.
    • 所有验证仪表均达到 100％验证，0％失败.
    • 数据库复制滞后为 0ms.
    • 地理日志光标是最新的（落后 0 个事件）.
  4. 在辅助节点上，导航到 管理区> 监视>后台作业>队列，然后等待所有geo队列下降到 0 个已排队的作业和 0 个正在运行的作业.
  5. 在辅助节点上，使用来验证 CI 工件，LFS 对象以及文件存储中的上载的完整性.

此时， 辅助节点将包含主节点拥有的所有内容的最新副本，这意味着在进行故障转移时不会丢失任何内容.

最后，按照灾难恢复文档将辅助节点升级为主要节点. 此过程将导致辅助节点发生短暂中断，并且用户可能需要再次登录.

一旦完成，维护窗口就结束了！ 新的主节点现在开始发散，从旧的. 如果确实出现在这一点上的问题，没有回到原来的主节点的，但可能会导致在此期间上传到新的主任何数据丢失.

故障转移完成后，请不要忘记删除广播消息.