GitLab Geo 高可用方案：计划内故障转移操作指南-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00986/article/details/148391663

GitLab Geo 高可用方案：计划内故障转移操作指南

gitlabhq GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com 项目地址: https://gitcode.com/gh_mirrors/gi/gitlabhq

前言

在企业级软件开发中，确保系统的高可用性和灾难恢复能力至关重要。GitLab Geo 作为 GitLab 的分布式解决方案，提供了跨地域的数据复制和灾难恢复能力。本文将深入讲解如何执行计划内故障转移（Planned Failover），这是将主站点（Primary）平滑迁移到备用站点（Secondary）的关键操作。

计划内故障转移概述

计划内故障转移不同于紧急故障恢复，它是在可控条件下进行的系统迁移操作，通常用于以下场景：

数据中心迁移
系统升级前的准备工作
云服务提供商更换
主动灾难演练

准备工作

1. 环境检查

执行前必须确保：

Geo 复制配置完整且正常运行
所有节点上的 /etc/gitlab/gitlab-secrets.json 一致
SSH 主机密钥在所有节点上匹配
系统检查无报错（gitlab-rake gitlab:check）

2. 数据复制状态确认

在管理后台的 Geo → Sites 页面检查：

复制进度应接近 100%
验证进度应接近 100%
数据库复制延迟应为 0ms
Geo 日志光标应完全同步

3. 非自动复制数据的处理

对于 Geo 不自动支持的数据类型（如某些文件存储），需要手动建立同步机制。推荐策略：

使用 rsync 进行增量同步
首次全量同步在维护窗口前完成
维护窗口内执行最终增量同步

详细操作步骤

阶段一：维护窗口准备

启用维护模式
```
sudo gitlab-ctl deploy-page up
```
调整后台作业
- 禁用所有非 Geo 相关的定时任务
- 保留以下关键 Geo 作业：
  - geo_metrics_update_worker
  - geo_prune_event_log_worker
  - geo_verification_cron_worker
  - repository_check_worker

阶段二：最终数据同步

等待队列清空
- 监控 Sidekiq 队列，确保除 geo 队列外所有队列归零
- 确认所有用户提交的作业已完成处理

执行完整性检查

sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check

阶段三：提升备用站点

执行提升前检查

sudo gitlab-ctl promotion-preflight-checks

正式提升操作

sudo gitlab-ctl promote-to-primary-node

验证提升结果
- 检查新主站点的读写功能
- 验证所有服务正常运行
- 确认复制方向已自动反转

容器镜像仓库特殊处理

如果使用本地存储的容器镜像仓库，需要额外步骤：

rsync 同步方案

rsync -azP --delete root@primary:/var/opt/gitlab/gitlab-rails/shared/registry/ /var/opt/gitlab/gitlab-rails/shared/registry/

备份恢复方案

# 在主站点创建仅包含仓库的备份
sudo gitlab-backup create SKIP=db,uploads,builds,artifacts,lfs,terraform_state,pages,repositories,packages

# 在备用站点恢复
sudo gitlab-backup restore BACKUP=<timestamp>