• 停止对数据库的写入
• 升级 Consul 节点
• 升级 Gitaly 节点（Praefect / Gitaly 集群）
• 升级不属于 Gitaly 集群的 Gitaly 节点
• 升级 PostgreSQL 节点
• 升级 Patroni 节点
• 升级 PgBouncer 节点
• 升级 Redis 节点
• 升级 Redis HA（使用 Sentinel）
• 升级 Rails 组件
• 升级监控节点

多节点停机升级

虽然你可以通过零停机时间升级多节点极狐GitLab部署，但有一些限制。特别是，你一次只能升级到一个小版本，例如，从 14.6 升级到 14.7，然后到 14.8，等等。

如果你想一次升级到多个小版本（例如，从 14.6 升级到 14.9），你必须将极狐GitLab实例下线，这意味着停机。在开始此过程之前，请验证与您的升级路径相关的特定版本升级说明：

• 极狐GitLab 17 改变
• 极狐GitLab 16 改变
• 极狐GitLab 15 改变

对于单节点安装，你只需升级极狐GitLab软件包。

升级多节点极狐GitLab安装的多个组件的过程与零停机升级相同。区别在于运行 Rails（Puma/Sidekiq）的服务器和事件的顺序。

在高层次上，过程是：

1. 关闭极狐GitLab 应用程序。
2. 升级你的 Consul 服务器。
3. 升级其他后端组件：
   • Gitaly、Rails PostgreSQL、Redis、PgBouncer：这些可以按任何顺序升级。
   • 如果你使用的是来自云平台的 PostgreSQL 或 Redis 并且需要升级，请用云提供商的说明替换 Omnibus 极狐GitLab 的说明。
4. 升级极狐GitLab应用程序（Sidekiq, Puma）并启动应用程序。

停止对数据库的写入

在升级之前，你需要停止对数据库的写入。该过程因你的参考架构而异。

::Tabs

:::TabTitle Linux 软件包

关闭所有运行这些进程的服务器上的 Puma 和 Sidekiq：

sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

:::TabTitle 云原生混合

对于云原生混合环境：

1. 记录当前数据库客户端的副本数量以便后续重启：

kubectl get deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}'

1. 停止数据库的客户端：

kubectl scale deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' --replicas=0

::EndTabs

升级 Consul 节点

请参阅 Consul 文档以获取完整说明。

总结：

1. 检查所有 Consul 节点是否健康。
2. 在所有 Consul 服务器上升级极狐GitLab 软件包。

3. 一次一个节点地重启所有极狐GitLab服务：

   sudo gitlab-ctl restart
   

如果你的 Consul 集群进程不在它们自己的服务器上，并且与其他服务（如 Redis HA 或 Patroni）共享，请确保在升级这些服务器时遵循以下原则：

• 不要一次重启多个服务器的服务。
• 在升级或重启服务之前，检查 Consul 集群是否健康。

升级 Gitaly 节点（Praefect / Gitaly 集群）

如果你正在运行 Gitaly 集群，请遵循 Gitaly 集群的零停机过程。

如果你在 AWS 上使用 Amazon 机器映像（AMI），你可以通过 AMI 过程升级 Gitaly 节点，或者升级软件包本身：

• 如果你使用的是弹性网络接口（ENI），你可以通过 AMI 过程进行升级。使用 ENI，你可以通过 AMI 实例更改保留私有 DNS 名称，这对于 Gitaly 的工作至关重要。
• 如果你没有使用 ENI，则必须使用极狐GitLab软件包升级 Gitaly。这是因为 Gitaly 集群通过服务器主机名跟踪 Git 存储库的副本，而使用 AMI 的重新部署会为节点分配新的主机名。即使存储相同，当主机名更改时，Gitaly 集群也无法工作。

然而，Praefect 节点可以通过 AMI 重新部署过程进行升级：

1. AMI 重新部署过程必须包含 gitlab-ctl reconfigure。在 AMI 上设置 praefect['auto_migrate'] = false 以便所有节点都获取此设置。这可以防止 reconfigure 自动运行数据库迁移。
2. 第一个使用升级映像重新部署的节点应为你的部署节点。
3. 部署后，在 gitlab.rb 中设置 praefect['auto_migrate'] = true 并应用 gitlab-ctl reconfigure。这将运行数据库迁移。
4. 重新部署你的其他 Praefect 节点。

升级不属于 Gitaly 集群的 Gitaly 节点

对于不属于 Gitaly 集群的 Gitaly 服务器，升级极狐GitLab 软件包。

如果你有多个 Gitaly 分片或使用 NFS 的多个负载平衡 Gitaly 节点，则升级 Gitaly 服务器的顺序无关紧要。

升级 PostgreSQL 节点

对于非集群 PostgreSQL 服务器：

1. 升级极狐GitLab 软件包。

2. 升级过程在升级二进制文件时不会重启 PostgreSQL。重启以加载新版本：

   sudo gitlab-ctl restart
   

升级 Patroni 节点

Patroni 用于实现 PostgreSQL 的高可用性。

如果需要 PostgreSQL 的主要版本升级，请遵循主要版本过程。

其他版本的升级过程首先在所有副本上进行。在升级后，会发生从领导者到其中一个升级的副本的集群故障转移。这确保只需要一次故障转移，一旦完成，新领导者将被升级。

遵循以下过程：

1. 确定领导者和副本节点，并验证集群是否健康。在数据库节点上运行：

   sudo gitlab-ctl patroni members
   

2. 在其中一个副本节点上升级极狐GitLab软件包。

3. 重启以加载新版本：

   sudo gitlab-ctl restart
   

4. 验证集群是否健康。
5. 对其他副本重复这些步骤：升级、重启、健康检查。
6. 按照与副本相同的软件包升级来升级领导者节点。

7. 重启领导者节点上的所有服务以加载新版本，并触发集群故障转移：

   sudo gitlab-ctl restart
   

8. 检查集群是否健康。

升级 PgBouncer 节点

如果你在 Rails（应用程序）节点上运行 PgBouncer，则 PgBouncer 作为应用程序服务器升级的一部分进行升级。

升级 PgBouncer 节点上的极狐GitLab软件包。

升级 Redis 节点

通过升级极狐GitLab软件包来升级独立的 Redis 服务器。

升级 Redis HA（使用 Sentinel）

遵循零停机说明来升级你的 Redis HA 集群。

升级 Rails 组件

::Tabs

:::TabTitle Linux 软件包

所有 Puma 和 Sidekiq 进程已关闭。在每个节点上：

1. 确保 /etc/gitlab/skip-auto-reconfigure 不存在。

2. 检查 Puma 和 Sidekiq 是否已关闭：

   ps -ef | egrep 'puma: | puma | sidekiq '
   

选择一个运行 Puma 的节点。这是你的部署节点，负责运行所有数据库迁移。在部署节点上：

1. 确保服务器配置为允许常规迁移。检查 /etc/gitlab/gitlab.rb 中没有 gitlab_rails['auto_migrate'] = false。要么将其明确设置为 gitlab_rails['auto_migrate'] = true，要么省略以保持默认行为（true）。

2. 如果你使用 PgBouncer：

   在运行迁移之前，你必须绕过 PgBouncer 并直接连接到 PostgreSQL。

   Rails 在尝试运行迁移时使用一个建议锁，以防止在同一数据库上运行并发迁移。这些锁不会在事务之间共享，导致在事务池模式下使用 PgBouncer 运行数据库迁移时出现 ActiveRecord::ConcurrentMigrationError 和其他问题。

   1. 如果你正在运行 Patroni，请找到领导者节点。在数据库节点上运行：

      sudo gitlab-ctl patroni members
      

   2. 更新部署节点上的 gitlab.rb。更改 gitlab_rails['db_host'] 和 gitlab_rails['db_port'] 为：

      • 你的数据库服务器（非集群 PostgreSQL）的主机和端口。
      • 如果你正在运行 Patroni，使用你的集群领导者的主机和端口。

   3. 应用更改：

      sudo gitlab-ctl reconfigure
      

3. 升级极狐GitLab软件包。

4. 如果你修改了部署节点上的 gitlab.rb 来绕过 PgBouncer：
   1. 更新部署节点上的 gitlab.rb。将 gitlab_rails['db_host'] 和 gitlab_rails['db_port'] 改回你的 PgBouncer 设置。

   2. 应用更改：

      sudo gitlab-ctl reconfigure
      

5. 为了确保所有服务都运行升级后的版本，并且（如果适用）使用 PgBouncer 访问数据库，重启部署节点上的所有服务：

   sudo gitlab-ctl restart
   

接下来，升级所有其他 Puma 和 Sidekiq 节点。在这些节点的 gitlab.rb 中，gitlab_rails['auto_migrate'] 可以设置为任何值。

可以并行升级：

1. 升级极狐GitLab 软件包。

2. 确保所有服务已重启：

   sudo gitlab-ctl restart
   

:::TabTitle 云原生混合

现在所有有状态组件都已升级，你需要遵循极狐GitLab chart 升级步骤以升级无状态组件（Webservice、Sidekiq、其他支持服务）。

在执行极狐GitLab chart 升级后，恢复数据库客户端：

kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<value>

::EndTabs

升级监控节点

升级极狐GitLab软件包。