Disaster Recovery (Geo)

原文：https://docs.gitlab.com/ee/administration/geo/disaster_recovery/

Disaster Recovery (Geo)

Geo 复制您的数据库，Git 存储库和其他少量资产. 将来，我们将支持和复制更多数据，使您能够在灾难情况下以最少的精力进行故障转移.

有关更多信息，请参见地电流限制 .

警告：多辅助配置的灾难恢复在Alpha 中 . 有关最新更新，请查看多级灾难恢复史诗 .

Promoting a secondary Geo node in single-secondary configurations

目前，我们不提供自动方式来升级 Geo 副本并进行故障转移，但是如果您具有对该计算机的root访问权，则可以手动进行.

此过程将辅助地理节点升级为主要节点. 为了尽快恢复地理冗余，应在遵循这些说明后立即添加新的辅助节点.

Step 1. Allow replication to finish if possible

如果辅助节点仍在从主节点复制数据，请尽可能严格遵循计划的故障转移文档 ，以避免不必要的数据丢失.

Step 2. Permanently disable the primary node

警告：如果主节点脱机，则可能是主节点上保存的数据尚未复制到辅助节点. 如果继续，此数据应视为丢失.

如果主节点发生故障，则应尽一切可能避免发生裂脑情况，即在两个不同的 GitLab 实例中可能发生写操作，从而使恢复工作复杂化. 因此，为故障转移做准备，我们必须禁用主节点.

  1. SSH 进入主节点以停止并禁用 GitLab，如果可能的话：

    1. sudo gitlab-ctl stop

    如果服务器意外重启，请阻止 GitLab 重新启动：

    1. sudo systemctl disable gitlab-runsvdir

    注意：（ 仅 CentOS ）在 CentOS 6 或更旧的版本中，如果没有可用的机器重启，没有简单的方法可以阻止启动GitLab （请参阅Omnibus GitLab 问题＃3058 ）. 完全卸载 GitLab 软件包可能是最安全的：

    1. yum remove gitlab-ee

    注意： （ Ubuntu 14.04 LTS ）如果您使用的是较旧版本的 Ubuntu 或基于 Upstart init 系统的任何其他发行版，则可以通过以下操作来阻止 GitLab 在计算机重启时启动：

    1. initctl stop gitlab-runsvvdir
    2. echo 'manual' > /etc/init/gitlab-runsvdir.override
    3. initctl reload-configuration

  2. 如果您没有对主节点的 SSH 访问权限，请使计算机脱机并通过任何方式阻止其重启. 由于您可能有很多方法可以完成此操作，因此我们将避免使用单个建议. 您可能需要：

    • 重新配置负载均衡器.
    • 更改 DNS 记录（例如，将主要 DNS 记录指向辅助节点，以停止使用主要节点）.
    • 停止虚拟服务器.
    • 阻止通过防火墙的流量.
    • 从主节点撤消对象存储权限.
    • 物理断开机器连接.
  3. 如果您打算更新主域 DNS 记录 ，则可能希望立即降低 TTL，以加快传播速度.

Step 3. Promoting a secondary node

升级辅助服务器时，请注意以下事项：

  • A new secondary should not be added at this time. If you want to add a new secondary, do this after you have completed the entire process of promoting the secondary to the primary.
  • 如果遇到ActiveRecord::RecordInvalid: Validation failed: Name has already been taken在此过程中， ActiveRecord::RecordInvalid: Validation failed: Name has already been taken错误，请阅读故障排除建议 .

Promoting a secondary node running on a single machine

  1. SSH 登录到辅助节点并以 root 用户身份登录：

    1. sudo -i

  2. 编辑/etc/gitlab/gitlab.rb以通过删除启用geo_secondary_role所有行来反映其新的主要状态：

    1. ## In pre-11.5 documentation, the role was enabled as follows. Remove this line.
    2. geo_secondary_role['enable'] = true
    4. ## In 11.5+ documentation, the role was enabled as follows. Remove this line.
    5. roles ['geo_secondary_role']

  3. 将辅助节点升级为主要节点.

    在将辅助节点升级为主节点之前，应运行飞行前检查. 它们可以单独运行，也可以与升级脚本一起运行.

    要将辅助节点与预检检查一起提升为主节点：

    1. gitlab-ctl promote-to-primary-node

    警告：跳过飞行前检查将把辅助设备升级为主要设备，而无需进一步确认！

    如果您已经运行了预检检查，或者不想运行它们，则可以使用以下方法跳过预检检查：

    1. gitlab-ctl promote-to-primary-node --skip-preflight-check

    您还可以单独运行飞行前检查：

    1. gitlab-ctl promotion-preflight-checks

  4. 验证您可以使用先前用于辅助节点的 URL 连接到新提升的主节点.

  5. 如果成功，则辅助节点现在已提升为主要节点.

Promoting a secondary node with multiple servers

gitlab-ctl promote-to-primary-node命令尚不能与多台服务器一起使用，因为它只能在仅一台机器的辅助 gitlab-ctl promote-to-primary-node上执行更改. 相反，您必须手动执行此操作.

  1. SSH 进入辅助数据库中的数据库节点，并触发 PostgreSQL 升级为可读写：

    1. sudo gitlab-pg-ctl promote

    在 GitLab 12.8 及更早版本中，请参阅消息： sudo: gitlab-pg-ctl: command not found .

  2. 在辅助计算机上的每台计算机上编辑/etc/gitlab/gitlab.rb ，以通过删除启用geo_secondary_role所有行来将其新状态反映为主要 geo_secondary_role ：

    1. ## In pre-11.5 documentation, the role was enabled as follows. Remove this line.
    2. geo_secondary_role['enable'] = true
    4. ## In 11.5+ documentation, the role was enabled as follows. Remove this line.
    5. roles ['geo_secondary_role']

    进行这些更改后，请在每台机器上重新配置 GitLab，以使更改生效.

  3. 将中学提升到小学 . SSH 进入单个应用程序服务器并执行：

    1. sudo gitlab-rake geo:set_secondary_as_primary

  4. 验证您可以使用先前用于辅助服务器的 URL 连接到新升级的主服务器.

  5. 成功！ 中学已升格为小学 .

Promoting a secondary node with an external PostgreSQL database

gitlab-ctl promote-to-primary-node命令不能与外部 PostgreSQL 数据库一起使用，因为它只能在使用 GitLab 的辅助节点和数据库在同一台机器上执行更改. 结果，需要手动处理：

  1. 升级与辅助站点关联的副本数据库. 这会将数据库设置为可读写：

    • Amazon RDS- 将只读副本提升为独立数据库实例
    • PostgreSQL 的 Azure 数据库- 停止复制

    • 其他外部 PostgreSQL 数据库-将以下脚本保存在辅助节点中，例如/tmp/geo_promote.sh ，然后修改连接参数以匹配您的环境. 然后，执行它以提升副本：

      1.  #!/bin/bash PG_SUPERUSER = postgres # The path to your pg_ctl binary. You may need to adjust this path to match # your PostgreSQL installation PG_CTL_BINARY = /usr/lib/postgresql/10/bin/pg_ctl # The path to your PostgreSQL data directory. You may need to adjust this # path to match your PostgreSQL installation. You can also run # `SHOW data_directory;` from PostgreSQL to find your data directory PG_DATA_DIRECTORY = /etc/postgresql/10/main # Promote the PostgreSQL database and allow read/write operations sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote

  2. 在辅助站点中的每个节点上编辑/etc/gitlab/gitlab.rb ，以通过删除启用geo_secondary_role所有行来将其新状态反映为主 geo_secondary_role ：

    1. ## In GitLab 11.4 and earlier, remove this line.
    2. geo_secondary_role['enable'] = true
    4. ## In GitLab 11.5 and later, remove this line.
    5. roles ['geo_secondary_role']

    进行这些更改后，请在每个节点上重新配置 GitLab ，以使更改生效.

  3. 将中学提升到小学 . SSH 进入单个辅助应用程序节点并执行：

    1. sudo gitlab-rake geo:set_secondary_as_primary

  4. 验证您可以使用先前用于辅助站点的 URL 连接到新升级的主站点.

成功！ 辅助站点现在已提升为主要站点.

Step 4. (Optional) Updating the primary domain DNS record

将主域的 DNS 记录更新为指向辅助节点将避免需要将对主域的所有引用更新为辅助域，例如更改 Git 远程服务器和 API URL.

  1. SSH 进入辅助节点并以 root 用户身份登录：

    1. sudo -i

  2. 更新主域的 DNS 记录. 更新主域名的 DNS 记录指向辅助节点后，编辑/etc/gitlab/gitlab.rb 辅助节点上，以反映新的网址：

    1. # Change the existing external_url configuration
    2. external_url 'https://<new_external_url>'

    Note: Changing external_url won’t prevent access via the old secondary URL, as long as the secondary DNS records are still intact.

  3. 重新配置辅助节点以使更改生效：

    1. gitlab-ctl reconfigure

  4. 执行以下命令以更新新提升的主节点 URL：

    1. gitlab-rake geo:update_primary_node_url

    此命令将使用/etc/gitlab/gitlab.rb定义的更改的external_url配置.

  5. 仅对于 GitLab 11.11 到 12.7，您可能需要更新数据库中的主节点名称. 此错误已在 GitLab 12.8 中修复.

    要确定是否需要执行此操作，请在/etc/gitlab/gitlab.rb文件中搜索gitlab_rails["geo_node_name"]设置. 如果用#注释掉或根本找不到它，则您将需要更新数据库中主节点的名称. 您可以像这样搜索它：

    1. grep "geo_node_name" /etc/gitlab/gitlab.rb

    要更新数据库中主节点的名称：

    1. gitlab-rails runner 'Gitlab::Geo.primary_node.update!(name: GeoNode.current_node_name)'

  6. 验证您可以使用其 URL 连接到新升级的主数据库 . 如果您更新了主域的 DNS 记录，则这些更改可能尚未传播，具体取决于以前的 DNS 记录 TTL.

Step 5. (Optional) Add secondary Geo node to a promoted primary node

使用上述过程将辅助节点提升为主要节点不会在新的主要节点上启用 Geo.

要使新的辅助节点在线，请按照Geo 设置说明进行操作 .

Step 6. (Optional) Removing the secondary’s tracking database

每个次级有一个用于保存从初级的所有项目的同步状态的特殊的跟踪数据库. 由于辅助服务器已经升级，因此不再需要跟踪数据库中的数据.

可以使用以下命令删除数据：

  1. sudo rm -rf /var/opt/gitlab/geo-postgresql

如果您在gitlab.rb文件中启用了任何geo_secondary[]配置选项，则可以安全地注释掉这些选项或将其删除，然后重新配置 GitLab以使更改生效.

Promoting secondary Geo replica in multi-secondary configurations

如果您有多个辅助节点，并且需要升级其中一个，建议您按照单辅助配置中的”升级辅助 Geo”节点进行操作 ，之后还需要执行两个额外步骤.

Step 1. Prepare the new primary node to serve one or more secondary nodes

  1. SSH 进入新的主节点并以 root 用户身份登录：

    1. sudo -i

  2. Edit /etc/gitlab/gitlab.rb

    1. ## Enable a Geo Primary role (if you haven't yet)
    2. roles ['geo_primary_role']
    4. ##
    5. # Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
    6. # public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
    7. ##
    8. postgresql['md5_auth_cidr_addresses'] = ['<primary_node_ip>/32', '<secondary_node_ip>/32']
    10. # Every secondary server needs to have its own slot so specify the number of secondary nodes you're going to have
    11. postgresql['max_replication_slots'] = 1
    13. ##
    14. ## Disable automatic database migrations temporarily
    15. ## (until PostgreSQL is restarted and listening on the private address).
    16. ##
    17. gitlab_rails['auto_migrate'] = false

    （有关这些设置的更多详细信息，您可以阅读配置主服务器 ）

  3. 保存文件并重新配置 GitLab，以进行数据库侦听更改和要应用的复制插槽更改.

    1. gitlab-ctl reconfigure

    重新启动 PostgreSQL 以使其更改生效：

    1. gitlab-ctl restart postgresql

  4. 现在，重新启动 PostgreSQL 并重新侦听私有地址，即可重新启用迁移.

    编辑/etc/gitlab/gitlab.rb并将配置更改为true ：

    1. gitlab_rails['auto_migrate'] = true

    保存文件并重新配置 GitLab：

    1. gitlab-ctl reconfigure

Step 2. Initiate the replication process

现在，我们需要使每个辅助节点侦听新的主要节点上的更改. 为此，您需要再次启动复制过程 ，但这一次是针对另一个主节点. 所有旧的复制设置将被覆盖.

Troubleshooting

I followed the disaster recovery instructions and now two-factor auth is broken

10.5 之前的 Geo 的安装说明无法复制otp_key_base机密，该机密用于加密存储在数据库中的两因素身份验证机密. 如果主节点和辅助节点之间的设置不同，启用了双重身份验证的用户将无法在故障转移后登录.

如果您仍然可以访问旧的主节点，则可以按照” 升级到 GitLab 10.5”部分中的说明解决错误. 否则，密码将丢失，您需要为所有用户重置两步验证 .