将已降级的主站点重新上线
- Tier: Premium, Ultimate
- Offering: GitLab Self-Managed
在故障转移之后,您可以故障恢复到已降级的主站点,以恢复您的原始配置。此过程包含两个步骤:
- 将旧的主站点设置为从站点。
- 将一个从站点提升为主站点。
如果您对此站点上的数据一致性有任何疑虑,我们建议您从头开始重新搭建。
将前主站点配置为从站点
由于前主站点与当前的主站点不同步,第一步是使前主站点更新到最新状态。请注意,在使前主站点重新同步时,不会重放存储在磁盘上的数据(如仓库和上传文件)的删除操作,这可能会导致磁盘使用量增加。 或者,您可以搭建一个新的 GitLab 从站点实例来避免此问题。
要使前主站点更新到最新状态:
-
通过 SSH 登录到已落后的前主站点。
-
如果存在
/etc/gitlab/gitlab-cluster.json文件,请将其删除。如果待重新添加为从站点的站点之前是通过
gitlab-ctl geo promote命令提升的,那么它可能包含一个/etc/gitlab/gitlab-cluster.json文件。例如,在运行gitlab-ctl reconfigure时,您可能会看到如下输出:The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb如果存在该文件,则必须从站点中的每个 Sidekiq、PostgreSQL、Gitaly 和 Rails 节点上删除
/etc/gitlab/gitlab-cluster.json,以使/etc/gitlab/gitlab.rb再次成为唯一的真实来源。 -
确保所有服务都已启动:
sudo gitlab-ctl start如果您在灾难恢复过程中更改了此站点的 DNS 记录,那么在此过程中您可能需要阻止对此站点的所有写入操作。
-
搭建 Geo。在这种情况下,从站点指的是前主站点。
- 如果PgBouncer在当前从站点(当它还是主站点时)上已启用,请通过编辑
/etc/gitlab/gitlab.rb并运行sudo gitlab-ctl reconfigure来禁用它。 - 然后,您可以在从站点上设置数据库复制。
- 如果PgBouncer在当前从站点(当它还是主站点时)上已启用,请通过编辑
如果您丢失了原始的主站点,请按照搭建说明来设置一个新的从站点。
将从站点提升为主站点
当初始复制完成,且主站点和从站点已基本同步时,您可以执行计划性故障转移。
恢复从站点
如果您的目标是再次拥有两个站点,您还需要为从站点重复第一步(将前主站点配置为从站点),以使其重新上线。
恢复其他从站点
如果存在不止一个从站点,现在可以将其余的站点上线。对于其余的每个站点,请与主站点启动复制过程。
在从站点上跳过数据的重新传输
当添加一个从站点时,如果它包含了本应从主站点同步的数据,那么 Geo 会避免重新传输这些数据。
- Git 仓库通过
git fetch传输,它只传输缺失的引用。 - Geo 的容器仓库同步代码会比较标签和摘要元组,并只拉取缺失的部分。
- 如果在首次同步时二进制大对象 (Blobs)已存在,则会跳过它们。
用例:
- 您执行了一次计划性故障转移,并通过将旧主站点作为从站点附加(而非重建)来降级它。
- 您拥有多个 Geo 从站点。您执行了一次计划性故障转移,并重新附加了其他 Geo 从站点(而非重建它们)。
- 您通过提升和降级一个从站点来进行故障转移测试,然后在不重建的情况下重新附加它。
- 您恢复了一个备份,并将该站点作为从站点附加。
- 您手动将数据复制到从站点以解决同步问题。
- 您删除或截断了 Geo 跟踪数据库中的注册表行以解决某个问题。
- 您重置了 Geo 跟踪数据库以解决某个问题。
跳过二进制大对象的重新传输
当您添加一个已存在二进制大对象 (blobs) 数据的从站点时,Geo 从站点将避免重新传输这些数据。这适用于:
- CI 作业制品
- CI 流水线制品
- CI 安全文件
- LFS 对象
- 合并请求差异
- 包文件
- Pages 部署
- Terraform 状态版本
- 上传文件
- 依赖代理清单
- 依赖代理二进制大对象
如果从站点上的副本实际上已损坏,那么后台验证最终会失败,并且该二进制大对象会被重新同步。
只有当二进制大对象在 Geo 跟踪数据库中没有对应的注册记录时,才会以这种方式跳过它们。这些条件之所以严格,是因为重新同步几乎总是有意为之的,我们不能冒错误跳过传输的风险。