极狐GitLab异地灾备方案设计，基于GEO的多地域容灾实践

定义框：GEO异地灾备是基于极狐GitLab Geo组件的多地域容灾方案，通过主从站点异步复制代码与数据，为站点级故障提供温备切换能力。

代码资产经不起机房级故障

先算一笔账：版本库、流水线历史、制品、议题与评审记录，全部沉淀在同一个实例里。如果这个实例所在的机房因为断电、网络中断或区域级灾害整体不可用，代码资产跟着一起"离线"，研发停摆多久、丢失多少提交，取决于灾备方案有没有提前设计。

很多人一提"高可用"就想到多节点冗余，但站点级故障和单节点故障是两个量级的问题。极狐GitLab官方文档对Geo的定位说得很清楚：它面向广泛分布的开发团队，作为灾难恢复策略的一部分提供温备站点，采用主动-被动（active-passive）架构和最终一致的同步模型。同时文档特别强调，Geo并非开箱即用的高可用解决方案——这两个概念必须先分清。

容灾和高可用，别用错工具

单机房内的高可用和跨地域的容灾，对应极狐GitLab两套不同的组件：

官方文档明确指出二者不可混淆、不可互替。生产级方案的正确姿势是：机房内用Gitaly集群扛单节点故障，跨地域用Geo扛站点级灾难，两层各司其职。

从站点的四种角色，规划先行

部署Geo前先想清楚每个从站点承担什么职责。官方支持一个主站点加多个从站点，从站点有四种典型用途：

1. 区域灾难恢复从站点：位于不同区域的温备站点，支持计划内故障转移，这是异地灾备的核心角色；

2. 远程团队加速从站点：为异地研发团队提供读取操作的本地缓存，可定制仅同步所需项目，配合透明代理实现统一URL；

3. CI/CD流量卸载从站点：Runner可从从站点克隆代码，数据过期时透明转发到主站点，为主站点减负；

4. 基础设施迁移从站点：迁移到新服务器或新数据中心时作为中转（注意不能用于跨操作系统的PostgreSQL迁移）。

同一个从站点可以兼多种职责，但灾备优先级和同步范围应按角色单独规划。

复制范围与三条硬边界

知道Geo复制什么，更要知道它不复制什么。官方数据类型文档列出了完整的可复制数据清单：PostgreSQL数据库（流式复制）、代码仓库（Git over HTTPS同步）、LFS对象、附件及其他文件（通过私有API端点下载），站点间同步使用JWT保护。

但有三条边界必须写进方案里：

• 选择性同步只管仓库和文件。按官方说明，即便配置了选择性同步，整个PostgreSQL数据库仍会被完整复制，因此它不适用于合规隔离场景；

• 损坏数据会被同步复制。官方文档明确提示，Geo会将主站点上的损坏数据复制到所有从站点，Geo不能替代备份体系，两者必须并行；

• 异步复制存在时间窗口。主站点离线时未复制的数据，官方文档的表述是"应被视为已丢失"——这条直接决定了RPO。

RPO与RTO，由切换方式决定

RPO（能容忍丢多少数据）和RTO（能容忍停多久）不是拍脑袋定的指标，而是由故障转移方式决定的。官方文档区分了两条路径：

计划内故障转移的官方流程建议提前4-6周启动准备：先解决所有同步与验证失败项，在预发布环境演练runbook，再按"预检→启用维护模式→完成复制与验证→提升从站点→后续处理"五阶段推进。复制完成度的验收标准也很量化：管理界面上所有指标达到100%已复制、100%已验证，数据库复制延迟0毫秒，日志游标落后0个事件。

切换演练的核心命令

灾备方案没有演练过，等于没有。以下是日常演练和真实切换都会用到的命令，均出自官方文档：

# 日常巡检：主、从站点分别执行系统检查
sudo gitlab-rake gitlab:check
sudo gitlab-rake gitlab:geo:check

# 计划外切换第一步：彻底禁用旧主站点，防止脑裂
sudo gitlab-ctl stop
sudo systemctl disable gitlab-runsvdir

# 主站点关闭后，在从站点运行提升预检
gitlab-ctl promotion-preflight-checks

# 提升从站点为新主站点（多节点部署需在每个节点执行）
sudo gitlab-ctl geo promote

# DNS切换后，更新新主站点的URL
gitlab-rake gitlab:geo:update_primary_node_url

三个容易踩的坑：其一，promotion-preflight-checks要求主站点已关闭，主站点在线时运行会直接报错；其二，提升后旧主站点完全脱离，若要恢复冗余必须将其重新配置为新从站点；其三，多从站点场景下，未提升的从站点需要用--force重新初始化复制，该操作会删除从站点数据库现有数据。

什么时候别急着上Geo

Geo是专业版/旗舰版、私有化部署的能力，且架构成本不低。三种情况建议先缓一缓：

• 只有单机房、没有第二地域：站点级容灾的前提是物理隔离，同城双机房都不能抵御区域性灾害；

• 数据量小、RTO要求宽松：如果"停一天可接受"，用定时备份加异地归档的方案更经济，不必引入主从架构的运维复杂度；

• 指望Geo替代备份：如前所述，损坏数据会被复制，备份体系必须独立存在。

常见问题

FAQ 1：Geo是不是配置完就等于灾备做好了？

不是。没有演练过的灾备方案不可信。官方建议至少在预发布环境完整演练计划内故障转移runbook，包括冒烟测试和回退流程，并定期用gitlab-rake gitlab:geo:check巡检复制状态。

FAQ 2：从站点提升后，未复制的数据还能找回来吗？

按官方文档的定义，主站点离线时未复制到从站点的数据应视为已丢失。要收窄RPO，只能通过降低复制延迟（监控数据库复制延迟指标）和尽量走计划内故障转移来实现。

FAQ 3：选择性同步能不能用来做数据合规隔离？

不能。官方明确说明选择性同步仅限制复制的代码仓库和文件，整个PostgreSQL数据库仍会被复制到从站点，因此不适用于合规或出口管制场景。

写在最后

异地灾备的本质不是买两台服务器，而是一套"复制有边界、切换有预案、演练有节奏"的工程体系。极狐GitLab Geo把站点级的复制与切换做成了产品能力，剩下的RPO/RTO目标设定和runbook演练，才是企业自己要补的功课。与其等事故来检验方案，不如先从一个从站点、一次计划内切换演练跑起来。

• 想深入了解Geo灾难恢复的完整流程，直接查阅极狐GitLab官方文档中心；

• 想评估自己实例的容灾就绪度，免费试用极狐GitLab；

• 需要多地域部署方案设计支持，预约产品演示，聊聊你的机房分布现状。