GitLab Geo 灾备恢复：将降级的主站点重新上线指南

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 高级版或旗舰版
• 已完成必要的备份工作
• 了解当前数据状态，特别是数据一致性情况

专家建议：如果对降级主站点的数据一致性存疑，强烈建议从零开始设置新站点，而非尝试恢复旧站点。

恢复流程详解

第一步：将原主站点配置为从站点

由于原主站点已与当前主站点不同步，首要任务是使其重新同步。注意，磁盘存储的数据（如仓库和上传文件）在重新同步过程中不会被删除，这可能导致磁盘使用量增加。

操作步骤：

1. SSH 连接到落后的原主站点

2. 清理集群配置文件

   sudo rm -f /etc/gitlab/gitlab-cluster.json
   

   此文件可能存在于 Sidekiq、PostgreSQL、Gitaly 和 Rails 节点上，必须全部删除以确保配置一致性。

3. 启动所有服务

   sudo gitlab-ctl start
   

4. 特殊情况处理：

   • 如果之前永久禁用了主站点，需要撤销这些操作
   • 对于使用 systemd 的系统（如 Ubuntu/CentOS 7+）：

     sudo systemctl enable gitlab-runsvdir
     

   • 对于不使用 systemd 的系统（如 CentOS 6），需要全新安装并设置为从站点

5. 重新配置 Geo：

   • 如果原主站点启用了 PgBouncer，需先禁用
   • 然后在从站点上设置数据库复制

第二步：将从站点提升为主站点

当初次复制完成且主从站点基本同步后，可执行计划内故障转移：

1. 确保所有数据已同步
2. 执行提升操作
3. 验证新主站点的功能完整性

第三步：恢复从站点

如需重建完整的双站点架构，需要将原从站点也重新上线：

1. 重复第一步的配置过程
2. 监控同步状态
3. 验证功能完整性

多从站点恢复

对于多个从站点的情况：

1. 首先恢复主要从站点
2. 然后依次恢复其他从站点
3. 对每个站点初始化与主站点的复制过程

数据重传优化机制

GitLab Geo 提供了智能的数据传输优化功能，避免不必要的数据重传：

通用优化原理

• Git 仓库：通过 git fetch 仅传输缺失的引用
• 容器注册表：仅同步缺失的标签
• Blob 数据：首次同步时跳过已存在的内容

Blob 数据优化（GitLab 16.9+）

针对以下内容的优化：

• CI 工件和流水线产物
• LFS 对象
• 合并请求差异
• 软件包文件
• 页面部署
• 上传内容等

注意：只有当跟踪数据库中不存在相应记录时才会跳过传输。如果数据确实损坏，后台验证最终会失败并触发重新同步。

最佳实践建议

1. 定期测试故障转移流程：确保团队熟悉恢复操作
2. 监控同步状态：及时发现并解决同步问题
3. 容量规划：考虑恢复过程中可能的磁盘使用增长
4. 文档记录：详细记录每次故障转移和恢复的操作步骤

通过遵循本指南，您可以有效地将降级的 GitLab Geo 主站点重新引入生产环境，确保系统的高可用性和数据一致性。

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