Geo 数据库复制

本文档介绍了将主站点极狐GitLab 数据库复制到从站点数据库所需的最低步骤。你可能需要根据数据库设置和大小等属性更改某些值。

确保从站点运行与主站点相同版本的极狐GitLab 企业版。确认你已向主站点添加了专业版或旗舰版订阅的许可证。

在执行这些步骤之前，请务必在测试或生产环境中阅读并审查所有步骤。

数据库密码一致性要求#

每个与数据库相关的密码类型必须在所有 Geo 站点（主站点和从站点）之间具有相同的值。这包括：

• postgresql['sql_replication_password']（复制用户密码，MD5）
• postgresql['sql_user_password']（极狐GitLab 数据库用户密码，MD5）
• gitlab_rails['db_password']（极狐GitLab 数据库用户密码，纯文本）
• patroni['replication_password']（对于 Patroni 设置，纯文本）
• patroni['password']（用于 Patroni API 身份验证，纯文本）
• postgresql['pgbouncer_user_password']（使用 PgBouncer 时，MD5）

例如，在主站点上配置的 patroni['password'] 值必须与所有从站点上的 patroni['password'] 值完全相同。

这些密码用于主站点和从站点之间的数据库身份验证和复制。 使用不同的密码会导致复制失败并阻止 Geo 正常工作。

单实例数据库复制#

单实例数据库复制更容易设置，并且仍然提供与集群替代方案相同的 Geo 功能。它对于在单台计算机上运行或尝试为未来的集群安装评估 Geo 的设置很有用。

可以使用 Patroni 将单实例扩展为集群版本，建议用于高可用架构。

请按照以下说明将 PostgreSQL 复制设置为单实例数据库。 或者，你可以查看多节点数据库复制 说明，了解如何使用 Patroni 集群设置复制。

PostgreSQL 复制#

极狐GitLab 主站点（执行写操作）连接到 主数据库服务器。从站点 连接到它们自己的数据库服务器（这些服务器为只读）。

你应该使用 PostgreSQL 的复制槽 以确保主站点保留从站点恢复所需的所有数据。详情见下文。

以下指南假设：

• 你使用的是 Linux 软件包（因此使用 PostgreSQL 12 或更高版本）， 其中包含 pg_basebackup 工具。
• 你已经设置了一个主站点（你要从中复制的极狐GitLab 服务器），运行由你的 Linux 软件包安装管理的 PostgreSQL（或同等版本），并且你已使用相同的 PostgreSQL 版本、 操作系统和极狐GitLab 在所有站点上设置了一个新的从站点。

步骤 1. 配置主站点#

1. SSH 登录到你的极狐GitLab 主站点并以 root 身份登录：

   shell
   sudo -i

2. 选择退出自动 PostgreSQL 升级以避免升级极狐GitLab 时出现意外停机。请注意使用 Geo 升级 PostgreSQL 时的注意事项。特别是对于较大的环境，必须有计划地、有意识地执行 PostgreSQL 升级。因此，今后请确 PostgreSQL 升级是定期维护活动的一部分。

3. 编辑 /etc/gitlab/gitlab.rb 并为你的站点添加一个唯一的名称：

   ruby
   ##
   ## Geo 站点的唯一标识符。请参阅
   ## https://gitlab.cn/docs/administration/geo_sites/#common-settings
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'

4. 重新配置主站点以使更改生效：

   shell
   gitlab-ctl reconfigure

5. 执行下面的命令将该站点定义为主站点：

   shell
   gitlab-ctl set-geo-primary-node

   此命令使用你在 /etc/gitlab/gitlab.rb 中定义的 external_url。

6. 为 gitlab 数据库用户定义密码：

   生成所需密码的 MD5 哈希：

   shell
   gitlab-ctl pg-password-md5 gitlab
   # 输入密码：<your_db_password_here>
   # 确认密码：<your_db_password_here>
   # fca0b89a972d69f00eb3ec98a5838484

   编辑 /etc/gitlab/gitlab.rb：

   ruby
   1# 填入由 `gitlab-ctl pg-password-md5 gitlab` 生成的哈希值
   2postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
   3
   4# 每个运行 Puma 或 Sidekiq 的节点都需要指定数据库
   5# 密码，如下所示。如果你有高可用性设置，则此设置
   6# 必须存在于所有应用节点中。
   7gitlab_rails['db_password'] = '<your_db_password_here>'

7. 为数据库复制用户定义密码。

   使用 /etc/gitlab/gitlab.rb 中 postgresql['sql_replication_user'] 设置下定义的用户名。默认值为 gitlab_replicator。如果你将用户名更改为其他名称，请相应地调整以下说明。

   生成所需密码的 MD5 哈希：

   shell
   gitlab-ctl pg-password-md5 gitlab_replicator
   # 输入密码：<your_replication_password_here>
   # 确认密码：<your_replication_password_here>
   # 950233c0dfc2f39c64cf30457c3b7f1e

   编辑 /etc/gitlab/gitlab.rb：

   ruby
   # 填入由 `gitlab-ctl pg-password-md5 gitlab_replicator` 生成的哈希值
   postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

   如果你使用的是非 Linux 软件包安装管理的外部数据库，则需要手动创建 gitlab_replicator 用户并为该用户定义密码：

   sql
   --- 创建一个新用户 'replicator'
   CREATE USER gitlab_replicator;
   
   --- 设置/更改密码并授予复制权限
   ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';

8. 编辑 /etc/gitlab/gitlab.rb 并将角色设置为 geo_primary_role（有关更多信息，请参阅 Geo 角色）：

   ruby
   ## Geo 主角色
   roles(['geo_primary_role'])

9. 配置 PostgreSQL 以侦听网络接口：

   出于安全原因，PostgreSQL 默认情况下不侦听任何网络接口。但是，Geo 要求从站点能够连接到主站点的数据库。因此，你需要每个站点的 IP 地址。

   对于外部 PostgreSQL 实例，请参阅附加说明。

   如果你使用的是云提供商，则可以通过云提供商的管理控制台查找每个 Geo 站点的地址。

   要查找 Geo 站点的地址，请通过 SSH 登录 Geo 站点并执行：

   shell
   1##
   2## 私有地址
   3##
   4ip route get 255.255.255.255 | awk '{print "Private address:", $NF; exit}'
   5
   6##
   7## 公共地址
   8##
   9echo "External address: $(curl --silent "ipinfo.io/ip")"

   在大多数情况下，以下地址用于配置极狐GitLab Geo：

   配置	地址
   postgresql['listen_address']	主站点的公共地址或 VPC 私有地址。
   postgresql['md5_auth_cidr_addresses']	主站点和从站点的公共地址或 VPC 私有地址。

   如果你使用的是 Google Cloud Platform、SoftLayer 或任何其他提供虚拟私有云（VPC）的供应商，我们建议使用主站点和从站点的“私有”或“内部”地址来配置 postgresql['md5_auth_cidr_addresses'] 和 postgresql['listen_address']。

   listen_address 选项使 PostgreSQL 对与给定地址对应的接口上的网络连接开放。更多详细信息，请参阅PostgreSQL 文档。

   如果你需要使用0.0.0.0 或 * 作为 listen_address，则还必须将 127.0.0.1/32 添加到 postgresql['md5_auth_cidr_addresses'] 设置中，以允许 Rails 通过 127.0.0.1 连接。有关更多信息，请参阅议题 5258。

   根据你的网络配置，建议的地址可能不正确。如果你的主站点和从站点通过局域网连接，或者通过连接可用区的虚拟网络连接，例如 Amazon VPC 或 Google VPC，则应为 postgresql['md5_auth_cidr_addresses'] 使用从站点的私有地址。

   编辑 /etc/gitlab/gitlab.rb 并添加以下内容，将 IP 地址替换为适合你网络配置的地址：

   ruby
   1##
   2## 主地址
   3## - 将 '<primary_node_ip>' 替换为你的 Geo 主节点的公共地址或 VPC 地址
   4##
   5postgresql['listen_address'] = '<primary_site_ip>'
   6
   7##
   8# 允许来自主站点和从站点 IP 的 PostgreSQL 客户端身份验证。这些 IP 可以是 CIDR 格式的公共地址或 VPC 地址，例如 ['198.51.100.1/32', '198.51.100.2/32']
   9##
   10postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']
   11
   12##
   13## 复制设置
   14##
   15# postgresql['max_replication_slots'] = 1 # 如果你有多个 Geo 从节点，请将此值设置为从节点的数量
   16# postgresql['max_wal_senders'] = 10
   17# postgresql['wal_keep_segments'] = 10

10. 暂时禁用自动数据库迁移，直到 PostgreSQL 重新启动并在私有地址上监听。 编辑 /etc/gitlab/gitlab.rb 并将配置更改为 false：

    ruby
    ## 禁用自动数据库迁移
    gitlab_rails['auto_migrate'] = false

11. 可选。如果你想添加另一个从站点，相关设置将如下所示：

    ruby
    postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32', '<another_secondary_site_ip>/32']

    你可能还想编辑 wal_keep_segments 和 max_wal_senders 以匹配你的数据库复制要求。有关更多信息，请参阅 PostgreSQL - 复制文档。

12. 保存文件并重新配置极狐GitLab，以使数据库监听更改和复制槽更改生效：

    shell
    gitlab-ctl reconfigure

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

    shell
    gitlab-ctl restart postgresql

13. 现在 PostgreSQL 已重新启动并在私有地址上监听，重新启用迁移。

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

    ruby
    gitlab_rails['auto_migrate'] = true

    保存文件并重新配置极狐GitLab：

    shell
    gitlab-ctl reconfigure

14. 现在 PostgreSQL 服务器已设置为接受远程连接，请运行 netstat -plnt | grep 5432 以确保 PostgreSQL 正在主站点的私有地址上监听端口 5432。

15. 重新配置极狐GitLab 时会自动生成证书。该证书自动用于保护你的 PostgreSQL 流量免受窃听。为了防止主动（“中间人”）攻击者，从站点需要一份签署该证书的 CA 的副本。对于自签名证书，请在主站点上运行以下命令，制作 PostgreSQL server.crt 文件的副本：

    shell
    cat ~gitlab-psql/data/server.crt

    将输出复制到剪贴板或本地文件中。在设置从站点时需要用到！该证书不是敏感数据。

    但是，此证书是使用通用 PostgreSQL 通用名称创建的。因此，你必须在复制数据库时使用 verify-ca 模式，否则主机名不匹配会导致错误。

16. 可选。生成你自己的 SSL 证书并手动为 PostgreSQL 配置 SSL，而不是使用生成的证书。

    你至少需要 SSL 证书和密钥。根据数据库 SSL 文档，将 postgresql['ssl_cert_file'] 和 postgresql['ssl_key_file'] 的值设置为其完整路径。

    这允许你在复制数据库时使用 verify-full SSL 模式，并获得验证 CN 中完整主机名的额外好处。

    今后，你可以使用此证书（你也在 postgresql['ssl_cert_file'] 中设置了该证书）来代替之前自动生成的自签名证书。如果 CN 匹配，这允许你使用 verify-full 而不会出现复制错误。

    在你的主数据库上，打开 /etc/gitlab/gitlab.rb 并搜索 postgresql['ssl_ca_file']（CA 证书）。将其值复制到剪贴板，稍后你将粘贴到 server.crt 中。

步骤 2. 配置从服务器#

1. SSH 登录到你的极狐GitLab 从站点并以 root 身份登录：

   shell
   sudo -i

2. 选择退出自动 PostgreSQL 升级以避免升级极狐GitLab 时出现意外停机。请注意使用 Geo 升级 PostgreSQL 时的注意事项。特别是对于较大的环境，必须有计划地、有意识地执行 PostgreSQL 升级。因此，今后请确 PostgreSQL 升级是定期维护活动的一部分。

3. 停止应用服务器和 Sidekiq：

   shell
   gitlab-ctl stop puma
   gitlab-ctl stop sidekiq

   此步骤很重要，可确保在站点完全配置之前不会尝试执行任何操作。

4. 检查 TCP 连接到主站点的 PostgreSQL 服务器：

   shell
   gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]

   如果此步骤失败，你可能使用了错误的 IP 地址，或者防火墙可能阻止了对站点的访问。检查 IP 地址，特别注意公共地址和私有地址之间的区别。确保如果存在防火墙，从站点被允许在端口 5432 上连接到主站点。

5. 在从站点上创建一个文件 server.crt，其中包含你在主站点设置的最后一步获得的内容：

   shell
   editor server.crt

6. 在从站点上设置 PostgreSQL TLS 验证：

   安装 server.crt 文件：

   shell
   1install \
   2   -D \
   3   -o gitlab-psql \
   4   -g gitlab-psql \
   5   -m 0400 \
   6   -T server.crt ~gitlab-psql/.postgresql/root.crt

   PostgreSQL 现在在验证 TLS 连接时只识别该确切的证书。该证书只能由有权访问私钥的人复制，而私钥仅存在于主站点上。

7. 测试 gitlab-psql 用户是否可以连接到主站点的数据库 （在 Linux 软件包安装中，默认数据库名称为 gitlabhq_production）：

   shell
   1sudo \
   2   -u gitlab-psql /opt/gitlab/embedded/bin/psql \
   3   --list \
   4   -U gitlab_replicator \
   5   -d "dbname=gitlabhq_production sslmode=verify-ca" \
   6   -W \
   7   -h <primary_site_ip>

   如果你使用的是手动生成的证书，并且希望使用sslmode=verify-full 来获益于完整的主机名验证， 请在运行命令时将 verify-ca 替换为 verify-full。

   出现提示时，输入你在第一步中为 gitlab_replicator 用户设置的纯文本密码。如果一切正常，你应该能看到主站点的数据库列表。

   此处连接失败表明 TLS 配置不正确。请确保主站点上 ~gitlab-psql/data/server.crt 的内容与从站点上 ~gitlab-psql/.postgresql/root.crt 的内容一致。

8. 编辑 /etc/gitlab/gitlab.rb 并将角色设置为 geo_secondary_role（有关更多信息，请参阅 Geo 角色）：

   ruby
   ##
   ## Geo 从角色
   ## - 自动配置相关标志以启用 Geo
   ##
   roles(['geo_secondary_role'])

9. 配置 PostgreSQL：

   此步骤与你配置主实例的方式类似。即使使用单节点，你也必须启用此设置。

   每种密码类型必须在所有 Geo 站点中具有相同的值。

   编辑 /etc/gitlab/gitlab.rb 并添加以下内容，将 IP 地址替换为适合你网络配置的地址：

   ruby
   1##
   2## 从地址
   3## - 将 '<secondary_site_ip>' 替换为你的 Geo 从站点的公共地址或 VPC 地址
   4##
   5postgresql['listen_address'] = '<secondary_site_ip>'
   6postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']
   7
   8##
   9## 数据库凭据密码（之前在主站点中定义）
   10## - 在此处复制与主站点中定义相同的值
   11##
   12postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'
   13postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
   14gitlab_rails['db_password'] = '<your_db_password_here>'

   对于外部 PostgreSQL 实例，请参阅附加说明。 如果你将一个以前的主站点重新上线以用作从站点，则你还必须移除 roles(['geo_primary_role']) 或 geo_primary_role['enable'] = true。

10. 重新配置极狐GitLab 以使更改生效：

    shell
    gitlab-ctl reconfigure

11. 重新启动 PostgreSQL 以使 IP 更改生效：

    shell
    gitlab-ctl restart postgresql

步骤 3. 启动复制过程#

下面是一个脚本，它将从站点上的数据库连接到主站点上的数据库。该脚本复制数据库并创建流复制所需的文件。

使用的目录是 Linux 软件包安装中设置的默认目录。如果你更改了任何默认值，请相应地配置脚本（替换任何目录和路径）。

1. SSH 登录到你的极狐GitLab 从站点并以 root 身份登录：

   shell
   sudo -i

2. 选择一个数据库友好的名称供你的从站点用作复制槽名称。例如，如果你的域是 secondary.geo.example.com，则使用 secondary_example 作为槽名称，如下面的命令所示。

3. 执行下面的命令以开始备份/还原并开始复制

   每个 Geo从站点必须具有自己唯一的复制槽名称。 在两个从站点之间使用相同的槽名称会破坏 PostgreSQL 复制。

   复制槽名称只能包含小写字母、数字和下划线字符。

   出现提示时，输入你在第一步中为 gitlab_replicator 用户设置的纯文本密码。

   shell
   gitlab-ctl replicate-geo-database \
      --slot-name=<secondary_site_name> \
      --host=<primary_site_ip> \
      --sslmode=verify-ca

   如果你生成了自定义的 PostgreSQL 证书，则需要使用--sslmode=verify-full（或完全省略 sslmode 行），以获益于对证书 CN/SAN 中完整主机名的额外验证，从而提高安全性。 否则，使用自动创建的证书使用 verify-full 会失败， 因为它具有通用的 PostgreSQL CN，不匹配此命令中的 --host 值。

   此命令还接受许多其他选项。你可以使用 --help 列出所有选项，但这里有一些提示：

   • 如果你的主站点只有一个节点，请使用主节点主机作为 --host 参数。
   • 如果你的主站点使用外部 PostgreSQL 数据库，则需要调整 --host 参数：
     • 对于 PgBouncer 设置，应直接定位实际的 PostgreSQL 数据库主机，而不是 PgBouncer 地址。
     • 对于 Patroni 配置，应定位当前的 Patroni 领导者主机。
     • 当使用负载均衡器（例如 HAProxy）时，如果负载均衡器配置为始终路由到 Patroni 领导者，则可以定位负载均衡器的地址。 如果不是，则必须定位实际的数据库主机。
     • 对于具有专用 PostgreSQL 节点的设置，应直接定位专用数据库主机。
   • 将 --slot-name 更改为主数据库上要使用的复制槽名称。如果复制槽不存在，脚本会尝试自动创建它。
   • 如果 PostgreSQL 监听非标准端口，请添加 --port=。
   • 如果你的数据库太大，无法在 30 分钟内传输完毕，则需要增加超时时间。例如，如果你预计初始复制需要不到一小时，则使用 --backup-timeout=3600。
   • 传递 --sslmode=disable 以完全跳过 PostgreSQL TLS 身份验证（例如，你知道网络路径是安全的，或者你正在使用站点到站点 VPN）。在公共 Internet 上这样做是不安全的！
   • 你可以在 PostgreSQL 文档中阅读有关每个 sslmode 的更多详细信息。 上面列出的说明经过精心编写，以确保免受被动窃听者和主动“中间人”攻击者的侵害。
   • 如果你要将一个旧站点重新用作 Geo 从站点，则必须向命令行添加 --force。
   • 当不在生产环境中时，你可以通过添加 --skip-backup 来禁用备份步骤（如果你确信这是你想要的）。

复制过程现已完成。

PgBouncer 支持（可选）#

要通过 Linux 软件包安装管理的 PostgreSQL 实例更改复制用户的密码：

在极狐GitLab Geo 主站点上：

1. 复制用户的默认值是 gitlab_replicator，但如果您在 /etc/gitlab/gitlab.rb 中的 postgresql['sql_replication_user'] 设置下设置了自定义复制用户，请确保根据您的用户调整以下说明。

   生成所需密码的 MD5 哈希值：

   shell
   sudo gitlab-ctl pg-password-md5 gitlab_replicator
   # 输入密码：<在此处输入您的复制密码>
   # 确认密码：<在此处输入您的复制密码>
   # 950233c0dfc2f39c64cf30457c3b7f1e

   编辑 /etc/gitlab/gitlab.rb：

   ruby
   # 使用 `gitlab-ctl pg-password-md5 gitlab_replicator` 生成的哈希值填充
   postgresql['sql_replication_password'] = '<您的复制密码的md5哈希值>'

2. 保存文件并重新配置极狐GitLab 以更改 PostgreSQL 中复制用户的密码：

   shell
   sudo gitlab-ctl reconfigure

3. 重启 PostgreSQL 以使复制密码更改生效：

   shell
   sudo gitlab-ctl restart postgresql

在密码在任何辅助站点上更新之前，辅助站点上的 PostgreSQL 日志会报告以下错误消息：

console
FATAL:  could not connect to the primary server: FATAL:  password authentication failed for user "gitlab_replicator"

在所有极狐GitLab Geo 辅助站点上：

1. 从配置角度来看，第一步不是必需的，因为哈希后的 'sql_replication_password' 不会在极狐GitLab Geo 辅助站点上使用。但是，如果辅助站点需要提升为极狐GitLab Geo 主站点，请确保匹配辅助站点配置中的 'sql_replication_password'。

   编辑 /etc/gitlab/gitlab.rb：

   ruby
   # 使用 Geo 主站点上 `gitlab-ctl pg-password-md5 gitlab_replicator` 生成的哈希值填充
   postgresql['sql_replication_password'] = '<您的复制密码的md5哈希值>'

2. 在初始复制设置期间，gitlab-ctl replicate-geo-database 命令将复制用户账户的明文密码写入两个位置：

   • gitlab-geo.conf：由 PostgreSQL 复制进程使用，写入 PostgreSQL 数据目录，默认路径为 /var/opt/gitlab/postgresql/data/gitlab-geo.conf。
   • .pgpass：由 gitlab-psql 用户使用，默认位于 /var/opt/gitlab/postgresql/.pgpass。

   更新这两个文件中的明文密码，并重启 PostgreSQL：

   shell
   sudo gitlab-ctl restart postgresql

多节点数据库复制#

将单个 PostgreSQL 节点迁移到 Patroni#

在引入 Patroni 之前，Geo 不支持在辅助站点上为高可用性设置使用 Linux 软件包安装。

借助 Patroni，现在可以实现此支持。要将现有的 PostgreSQL 迁移到 Patroni：

1. 确保您在辅助站点上设置了 Consul 集群（类似于在主站点上的设置方式）。
2. 配置永久复制槽。
3. 配置内部负载均衡器。
4. 配置 PgBouncer 节点
5. 在该单节点机器上配置备用集群。

最终您会得到一个单节点的备用集群。这样，您就可以按照之前列出的相同说明添加额外的 Patroni 节点。

Patroni 支持#

Patroni 是 Geo 的官方复制管理解决方案。Patroni 可用于在主站点和辅助 Geo 站点上构建高可用性集群。在辅助站点上使用 Patroni 是可选的，您不必在每个 Geo 站点上使用相同数量的节点。

有关如何在主站点上设置 Patroni 的说明，请参阅相关文档。

为 Geo 辅助站点配置 Patroni 集群#

在 Geo 辅助站点中，主 PostgreSQL 数据库是主站点 PostgreSQL 数据库的只读副本。

生产就绪且安全的设置至少需要：

• 3 个 Consul 节点 (主站点和辅助站点)
• 2 个 Patroni 节点 (主站点和辅助站点)
• 1 个 PgBouncer 节点 (主站点和辅助站点)
• 1 个内部负载均衡器 (仅主站点)

每当选举出新的 Leader 时，内部负载均衡器都会提供一个单一端点来连接到 Patroni 集群的 Leader。负载均衡器对于启用从辅助站点的级联复制是必需的。

请确保使用密码凭证和其他数据库最佳实践。

步骤 1. 在主站点上配置 Patroni 永久复制槽#

在主数据库上设置持久复制槽，以确保数据从主数据库持续复制到辅助节点上的 Patroni 集群。

步骤 2. 在主站点上配置内部负载均衡器#

为了避免在主站点上选举出新 Leader 时在辅助站点上重新配置备用 Leader，您应该设置一个 TCP 内部负载均衡器。此负载均衡器提供一个单一端点来连接到 Patroni 集群的 Leader。

Linux 软件包不包含负载均衡器。以下介绍如何使用 HAProxy 来实现。

以下 IP 和名称作为示例使用：

• 10.6.0.21：Patroni 1（patroni1.internal）
• 10.6.0.22：Patroni 2（patroni2.internal）
• 10.6.0.23：Patroni 3（patroni3.internal）

plaintext
1global
2    log /dev/log local0
3    log localhost local1 notice
4    log stdout format raw local0
5
6defaults
7    log global
8    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
9
10frontend internal-postgresql-tcp-in
11    bind *:5432
12    mode tcp
13    option tcplog
14
15    default_backend postgresql
16
17backend postgresql
18    mode tcp
19    option httpchk
20    http-check expect status 200
21
22    server patroni1.internal 10.6.0.21:5432 maxconn 100 check port 8008
23    server patroni2.internal 10.6.0.22:5432 maxconn 100 check port 8008
24    server patroni3.internal 10.6.0.23:5432 maxconn 100 check port 8008

更多指导，请参考您首选负载均衡器的文档。

步骤 3. 在辅助站点上配置 PgBouncer 节点#

生产就绪且高可用的配置至少需要三个 Consul 节点和至少一个 PgBouncer 节点。但是，建议每个数据库节点配备一个 PgBouncer 节点。当存在多个 PgBouncer 服务节点时，需要内部负载均衡器（TCP）。内部负载均衡器提供一个单一端点来连接到 PgBouncer 集群。更多信息请参阅相关文档。

在辅助站点上运行 PgBouncer 实例的每个节点上：

1. SSH 进入您的 PgBouncer 节点并以 root 身份登录：

   shell
   sudo -i

2. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容：

   ruby
   1# 禁用除 Pgbouncer 和 Consul 代理之外的所有组件
   2roles(['pgbouncer_role'])
   3
   4# PgBouncer 配置
   5pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
   6pgbouncer['users'] = {
   7'gitlab-consul': {
   8   # 使用以下命令生成：`gitlab-ctl pg-password-md5 gitlab-consul`
   9   password: 'GITLAB_CONSUL_PASSWORD_HASH'
   10 },
   11  'pgbouncer': {
   12    # 使用以下命令生成：`gitlab-ctl pg-password-md5 pgbouncer`
   13    password: 'PGBOUNCER_PASSWORD_HASH'
   14  }
   15}
   16
   17# Consul 配置
   18consul['watchers'] = %w(postgresql)
   19consul['configuration'] = {
   20  retry_join: %w[CONSUL_SECONDARY1_IP CONSUL_SECONDARY2_IP CONSUL_SECONDARY3_IP]
   21}
   22consul['monitoring_service_discovery'] =  true

3. 重新配置极狐GitLab 以使更改生效：

   shell
   gitlab-ctl reconfigure

4. 创建一个 .pgpass 文件，以便 Consul 能够重新加载 PgBouncer。在提示时输入两次 PLAIN_TEXT_PGBOUNCER_PASSWORD：

   shell
   gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul

5. 重新加载 PgBouncer 服务：

   shell
   gitlab-ctl hup pgbouncer

步骤 4. 在辅助站点上配置备用集群#

对于辅助站点上运行 Patroni 实例的每个节点：

1. SSH 进入您的 Patroni 节点并以 root 身份登录：

   shell
   sudo -i

2. 选择退出自动 PostgreSQL 升级，以避免升级极狐GitLab 时出现意外停机。请注意在 Geo 环境中升级 PostgreSQL 时的已知注意事项。特别是对于较大规模的环境，必须有计划地、谨慎地执行 PostgreSQL 升级。因此，今后请确保将 PostgreSQL 升级作为定期维护活动的一部分。

3. 编辑 /etc/gitlab/gitlab.rb 并添加以下内容：

   所有 Geo 站点上的每种密码类型都必须具有匹配的值。

   ruby
   1roles(['consul_role', 'patroni_role'])
   2
   3consul['enable'] = true
   4consul['configuration'] = {
   5  retry_join: %w[CONSUL_SECONDARY1_IP CONSUL_SECONDARY2_IP CONSUL_SECONDARY3_IP]
   6}
   7consul['services'] = %w(postgresql)
   8
   9postgresql['md5_auth_cidr_addresses'] = [
   10  'PATRONI_SECONDARY1_IP/32', 'PATRONI_SECONDARY2_IP/32', 'PATRONI_SECONDARY3_IP/32', 'PATRONI_SECONDARY_PGBOUNCER/32',
   11  # 根据文档，任何其他需要访问数据库的实例
   12]
   13
   14
   15# 将 patroni 节点添加到允许列表
   16patroni['allowlist'] = %w[
   17  127.0.0.1/32
   18  PATRONI_SECONDARY1_IP/32 PATRONI_SECONDARY2_IP/32 PATRONI_SECONDARY3_IP/32
   19]
   20
   21patroni['standby_cluster']['enable'] = true
   22patroni['standby_cluster']['host'] = 'INTERNAL_LOAD_BALANCER_PRIMARY_IP'
   23patroni['standby_cluster']['port'] = INTERNAL_LOAD_BALANCER_PRIMARY_PORT
   24patroni['standby_cluster']['primary_slot_name'] = 'geo_secondary' # 或您之前设置的唯一复制槽名称
   25patroni['username'] = 'PATRONI_API_USERNAME'
   26patroni['password'] = 'PATRONI_API_PASSWORD'
   27patroni['replication_password'] = 'PLAIN_TEXT_POSTGRESQL_REPLICATION_PASSWORD'
   28patroni['use_pg_rewind'] = true
   29patroni['postgresql']['max_wal_senders'] = 5 # 一个副本至少需要 3 个，每增加一个副本再加 2 个
   30patroni['postgresql']['max_replication_slots'] = 5 # 一个副本至少需要 3 个，每增加一个副本再加 2 个
   31
   32postgresql['pgbouncer_user_password'] = 'PGBOUNCER_PASSWORD_HASH'
   33postgresql['sql_replication_password'] = 'POSTGRESQL_REPLICATION_PASSWORD_HASH'
   34postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
   35postgresql['listen_address'] = '0.0.0.0' # 您可以在此处改用公网或 VPC 地址
   36
   37# `gitlab-ctl geo-replication-pause` 需要 GitLab Rails 配置
   38gitlab_rails['db_password'] = 'POSTGRESQL_PASSWORD'
   39gitlab_rails['enable'] = true
   40gitlab_rails['auto_migrate'] = false

   配置 patroni['standby_cluster']['host'] 和 patroni['standby_cluster']['port'] 时：

   • INTERNAL_LOAD_BALANCER_PRIMARY_IP 必须指向主内部负载均衡器 IP。
   • INTERNAL_LOAD_BALANCER_PRIMARY_PORT 必须指向为主 Patroni 集群 leader 配置的前端端口。不要使用 PgBouncer 前端端口。

4. 重新配置极狐GitLab 以使更改生效。 此步骤是引导 PostgreSQL 用户和设置所必需的。

   • 如果这是 Patroni 的全新安装：

     shell
     gitlab-ctl reconfigure

   • 如果您正在先前已有正常运行的 Patroni 集群的站点上配置 Patroni 备用集群：

     1. 在所有由 Patroni 管理的节点上停止 Patroni，包括级联副本：

        shell
        gitlab-ctl stop patroni

     2. 在 leader Patroni 节点上运行以下命令以重新创建备用集群：

        shell
        rm -rf /var/opt/gitlab/postgresql/data
        /opt/gitlab/embedded/bin/patronictl -c /var/opt/gitlab/patroni/patroni.yaml remove postgresql-ha
        gitlab-ctl reconfigure

     3. 在 leader Patroni 节点上启动 Patroni，以启动从主数据库的复制过程：

        shell
        gitlab-ctl start patroni

     4. 检查 Patroni 集群的状态：

        shell
        gitlab-ctl patroni members

        验证：

        • 当前 Patroni 节点出现在输出中。
        • 角色为 Standby Leader。角色最初可能显示为 Replica。
        • 状态为 Running。状态最初可能显示为 Creating replica。

        等待节点的角色稳定为 Standby Leader 且状态为 Running。这可能需要几分钟。

     5. 当 leader Patroni 节点成为 Standby Leader 并且为 Running 状态时，在备用集群中的其他 Patroni 节点上启动 Patroni：

        shell
        gitlab-ctl start patroni

        其他 Patroni 节点应以副本身份加入新的备用集群，并自动开始从 leader Patroni 节点进行复制。

5. 验证集群状态：

   shell
   gitlab-ctl patroni members

   确保所有 Patroni 节点都列为 Running 状态。应该有一个 Standby Leader 节点和多个 Replica 节点。

将单个跟踪数据库节点迁移到 Patroni#

在引入 Patroni 之前，Geo 不支持在辅助站点上为高可用性设置使用 Linux 软件包安装。

借助 Patroni，现在可以支持高可用性设置。但是，Patroni 中的一些限制阻止了在同一台机器上管理两个不同的集群。您应该按照为 Geo 辅助站点配置 Patroni 集群的相同说明，为跟踪数据库设置一个新的 Patroni 集群。

辅助节点会回填新的跟踪数据库，无需数据同步。

为跟踪 PostgreSQL 数据库配置 Patroni 集群#

辅助 Geo 站点使用单独的 PostgreSQL 安装作为跟踪数据库，以跟踪复制状态并自动从潜在的复制问题中恢复。

如果您想在单个节点上运行 Geo 跟踪数据库，请参阅在 Geo 辅助站点上配置 Geo 跟踪数据库。

Linux 软件包不支持在高可用性配置中运行 Geo 跟踪数据库。特别是故障转移无法正常工作。

如果您想在高可用性配置中运行 Geo 跟踪数据库，可以将辅助站点连接到外部 PostgreSQL 数据库，例如云托管数据库或手动配置的 Patroni 集群（不由极狐GitLab Linux 软件包管理）。请遵循使用外部 PostgreSQL 实例的 Geo。

故障排除#

阅读故障排除文档。