灾难恢复 (Geo)

Tier: 专业版, 旗舰版
Offering: 私有化部署

极狐GitLab 复制您的数据库、Git 仓库和其他资产。

多次备份配置需要对所有未提升的备份进行完全重新同步和重新配置，导致停机。

提升单备份配置中的备份 Geo 站点#

虽然您不能自动提升 Geo 副本并进行故障转移，但如果您拥有机器的 root 访问权限，可以手动提升它。此过程将备份 Geo 站点提升为主站点。为了尽快恢复地理冗余，您应该在遵循这些说明后立即添加新的备份站点。

第一步。允许复制完成（如果可能）#

如果备份站点仍在从主站点复制数据，请尽量遵循计划故障转移文档，以避免不必要的数据丢失。

第二步。永久禁用主站点#

如果 **主** 站点出现故障，可能会有一些未复制到 **备份** 站点的数据保存在 **主** 站点。这些数据应视为丢失。

如果主站点发生故障，您应该尽一切努力避免在两个不同的极狐GitLab 实例中进行写入的分裂脑状态，这会使恢复工作复杂化。因此，为了准备故障转移，我们必须禁用主站点。

如果您有 SSH 访问权限：
1. SSH 到主站点以停止和禁用极狐GitLab：
```
shell
sudo gitlab-ctl stop
```
2. 防止极狐GitLab 在服务器意外重启时再次启动：
```
shell
sudo systemctl disable gitlab-runsvdir
```
如果您没有主站点的 SSH 访问权限，请将机器离线并通过任何可能的手段防止其重启。您可能需要：
- 重新配置负载均衡器。
- 更改 DNS 记录（例如，将主要 DNS 记录指向备份站点以停止使用主站点）。
- 停止虚拟服务器。
- 通过防火墙阻止流量。
- 撤销主站点的对象存储权限。
- 物理断开机器。
如果您计划更新主要域名的 DNS 记录，您可能希望保持较低的 TTL 以确保 DNS 更改的快速传播。

主站点的 `/etc/gitlab/gitlab.rb` 文件在此过程中不会自动复制到备份站点。确保备份主站点的 `/etc/gitlab/gitlab.rb` 文件，以便以后可以恢复备份站点所需的值。

第三步。提升备份站点#

提升备份时请注意以下事项：

如果备份站点已暂停，提升会执行到最后已知状态的时间点恢复。在备份暂停期间在主站上创建的数据将丢失。
此时不应添加新的备份。如果您想添加新的备份，请在完成将备份提升为主的整个过程后执行此操作。
如果在此过程中遇到 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 错误消息，请参阅此故障排除建议获取更多信息。
如果您使用不同的 URL，您应该将主要域名 DNS 指向新提升的站点。否则，必须在新提升的站点重新注册 runner，并更新所有 Git 远程、书签和外部集成。
如果您使用位置感知 DNS，在旧主站点从 DNS 条目中移除后，runner 应自动连接到新的主站点。
如果您不期望连接到先前主站的 runner 返回，您应该移除它们：
- 通过 UI：
  1. 在左侧栏底部选择 管理员。
  2. 选择 CI/CD > Runner 并移除它们。
- 使用 Runner API。

提升运行在单节点上的备份站点#

SSH 到您的备份站点并执行：
- 将备份站点提升为主站点：
```
shell
sudo gitlab-ctl geo promote
```
- 将备份站点提升为主站点无需进一步确认：
```
shell
sudo gitlab-ctl geo promote --force
```
验证您可以使用之前用于备份站点的 URL 连接到新提升的主站点。
如果成功，备份站点现已提升为主站点。

提升具有多个节点的备份站点#

SSH 到备份站点中的每个 Sidekiq、PostgreSQL 和 Gitaly 节点，并运行以下命令之一：
- 将备份站点上的节点提升为主站点：
```
shell
sudo gitlab-ctl geo promote
```
- 将备份站点提升为主站点无需进一步确认：
```
shell
sudo gitlab-ctl geo promote --force
```
SSH 到备份站点中的每个 Rails 节点，并运行以下命令之一：
- 将备份站点提升为主站点：
```
shell
sudo gitlab-ctl geo promote
```
- 将备份站点提升为主站点无需进一步确认：
```
shell
sudo gitlab-ctl geo promote --force
```
验证您可以使用之前用于备份站点的 URL 连接到新提升的主站点。
如果成功，备份站点现已提升为主站点。

提升具有 Patroni 备用集群的备份站点#

SSH 到备份站点中的每个 Sidekiq、PostgreSQL 和 Gitaly 节点，并运行以下命令之一：
- 将备份站点提升为主站点：
```
shell
sudo gitlab-ctl geo promote
```
- 将备份站点提升为主站点无需进一步确认：
```
shell
sudo gitlab-ctl geo promote --force
```
SSH 到备份站点中的每个 Rails 节点，并运行以下命令之一：
- 将备份站点提升为主站点：
```
shell
sudo gitlab-ctl geo promote
```
- 将备份站点提升为主站点无需进一步确认：
```
shell
sudo gitlab-ctl geo promote --force
```
验证您可以使用之前用于备份站点的 URL 连接到新提升的主站点。
如果成功，备份站点现已提升为主站点。

提升具有外部 PostgreSQL 数据库的备份站点#

gitlab-ctl geo promote 命令可以与外部 PostgreSQL 数据库结合使用。在这种情况下，您必须首先手动提升与备份站点关联的副本数据库：

提升与备份站点关联的副本数据库。这将数据库设置为读写。说明根据数据库托管位置的不同而有所变化：

Amazon RDS
Azure PostgreSQL

对于其他外部 PostgreSQL 数据库，将以下脚本保存在您的备份站点中，例如 /tmp/geo_promote.sh，并根据您的环境修改连接参数。然后执行它以提升副本：

shell
1#!/bin/bash
2
3PG_SUPERUSER=postgres
4
5# 你的 pg_ctl 二进制文件的路径。您可能需要调整此路径以匹配您的 PostgreSQL 安装
6PG_CTL_BINARY=/usr/lib/postgresql/10/bin/pg_ctl
7
8# 你的 PostgreSQL 数据目录的路径。您可能需要调整此路径以匹配您的 PostgreSQL 安装。您还可以从 PostgreSQL 中运行 `SHOW data_directory;` 来查找您的数据目录
9PG_DATA_DIRECTORY=/etc/postgresql/10/main
10
11# 提升 PostgreSQL 数据库并允许读写操作
12sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote

SSH 到备份站点中的每个 Sidekiq、PostgreSQL 和 Gitaly 节点，并运行以下命令之一：
- 将备份站点提升为主站点：
```
shell
sudo gitlab-ctl geo promote
```
- 将备份站点提升为主站点无需进一步确认：
```
shell
sudo gitlab-ctl geo promote --force
```
SSH 到备份站点中的每个 Rails 节点，并运行以下命令之一：
- 将备份站点提升为主站点：
```
shell
sudo gitlab-ctl geo promote
```
- 将备份站点提升为主站点无需进一步确认：
```
shell
sudo gitlab-ctl geo promote --force
```
验证您可以使用之前用于备份站点的 URL 连接到新提升的主站点。
如果成功，备份站点现已提升为主站点。

第四步。（可选）更新主要域名 DNS 记录#

更新主要域名的 DNS 记录以指向备份站点。这消除了更新所有对主要域名的引用的需求，例如更改 Git 远程和 API URL。

SSH 到备份站点并以 root 身份登录：
```
shell
sudo -i
```
更新主要域名的 DNS 记录。在更新主要域名的 DNS 记录以指向备份站点后，编辑备份站点上的 /etc/gitlab/gitlab.rb 以反映新 URL：
```
ruby
# 更改现有的 external_url 配置
external_url 'https://<new_external_url>'
```
更改 `external_url` 并不妨碍通过旧的备份 URL 访问，只要备份 DNS 记录仍然完好。
更新备份的 SSL 证书：
- 如果您使用 Let's Encrypt 集成，证书会自动更新。
- 如果您已手动设置，则备份的证书，请从主复制证书到备份。如果您无法访问主，请颁发新证书并确保其包含主和备份 URL 在主体备用名称中。您可以使用以下命令检查：
```
shell
/opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer \
    -nameopt multiline -ext subjectAltName -in /etc/gitlab/ssl/new-gitlab.new-example.com.crt
```
重新配置备份站点以使更改生效：
```
shell
gitlab-ctl reconfigure
```
执行以下命令以更新新提升的主站点 URL：
```
shell
gitlab-rake geo:update_primary_node_url
```
此命令使用在 /etc/gitlab/gitlab.rb 中定义的更改的 external_url 配置。
验证您可以使用其 URL 连接到新提升的主。如果您更新了主要域名的 DNS 记录，这些更改可能尚未传播，具体取决于之前 DNS 记录的 TTL。

第五步。（可选）将备份 Geo 站点添加到提升的主站点#

使用上述过程将备份站点提升为主站点不会在新主站点上启用 Geo。

要上线新的备份站点，请按照 Geo 设置说明。

第六步。移除前备份的跟踪数据库#

每个备份都有一个特殊的跟踪数据库，用于保存从主同步的所有项目的状态。因为备份已经提升，所以跟踪数据库中的数据不再需要。

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

shell
sudo rm -rf /var/opt/gitlab/geo-postgresql

如果您在 gitlab.rb 文件中启用了任何 geo_secondary[] 配置选项，请将它们注释掉或移除，然后重新配置极狐GitLab以使更改生效。

在多备份配置中提升备份 Geo 副本#

如果您有多个备份站点，并且需要提升其中一个，我们建议您遵循提升单备份配置中的备份 Geo 站点，之后您还需要两个额外步骤。

第一步。准备新主站点以服务一个或多个备份站点#

SSH 到新的主站点并以 root 身份登录：
```
shell
sudo -i
```

编辑 /etc/gitlab/gitlab.rb：

ruby
1## 启用 Geo 主角色（如果您尚未启用）
2roles ['geo_primary_role']
3
4##
5# 允许从主站和备份站的 IP 进行 PostgreSQL 客户端认证。这些 IP 可以是 CIDR 格式的公共或 VPC 地址，例如 ['198.51.100.1/32', '198.51.100.2/32']
6##
7postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']
8
9# 每个备份站点需要有自己的插槽，因此请指定您将要拥有的备份站点数量
10# postgresql['max_replication_slots'] = 1 # 如果您有多个 Geo 备份节点，请将此设置为备份节点的数量
11
12##
13## 暂时禁用自动数据库迁移
14##（直到 PostgreSQL 重启并在私有地址上监听）。
15##
16gitlab_rails['auto_migrate'] = false

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

保存文件并重新配置极狐GitLab，以应用数据库监听更改和复制插槽更改：
```
shell
gitlab-ctl reconfigure
```
重启 PostgreSQL 以使其更改生效：
```
shell
gitlab-ctl restart postgresql
```
重新启用迁移，因为 PostgreSQL 已重启并在私有地址上监听。

编辑 /etc/gitlab/gitlab.rb 并更改配置为 true：
```
ruby
gitlab_rails['auto_migrate'] = true
```
保存文件并重新配置极狐GitLab：
```
shell
gitlab-ctl reconfigure
```

第二步。启动复制过程#

现在我们需要让每个备份站点监听新主站点的更改。为此，您需要再次启动复制过程，但这次是针对另一个主站点。所有旧的复制设置都被覆盖。

故障排除#

此部分已移至另一个位置。

灾难恢复 (Geo)

提升单备份配置中的 备份 Geo 站点#

第一步。允许复制完成（如果可能）#

第二步。永久禁用 主 站点#

第三步。提升 备份 站点#

提升运行在单节点上的 备份 站点#

提升具有多个节点的 备份 站点#

提升具有 Patroni 备用集群的 备份 站点#

提升具有外部 PostgreSQL 数据库的 备份 站点#