DevOps随笔-GitLab灾备方案之Geo

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

GitLab Geo 是 GitLab 的灾难恢复和分布式部署解决方案，它允许您将 GitLab 实例作为只读副本(secondary node)地理分布到多个位置。

---

一、GitLab GEO多地部署架构

一个Primary server,多个Secondary servers.
Primary可读写，Secondary只读，写操作通过Proxy转发给Primary实现.

二、Secondary node 为什么多一个数据库？

因为从节点PostgreSQL是只读的，Tracking DB跟踪主节点变化所产生的event.

三、为什么 secondary node 的代码没有及时同步?

当 secondary node 的代码没有及时同步时，首先要明确GitLab Geo 同步基本原理：

1. 主从架构：一个 primary node 和多个 secondary nodes
2. 异步复制：数据变更从 primary 异步传播到 secondary
3. 两类同步：
   o 数据库复制：使用 PostgreSQL 流复制
   o 文件复制：通过 Geo 日志（Git）和 API 传输（http）

代码未及时同步的常见原因:

1. 同步延迟：
   o 网络带宽不足或延迟高
   o 大型仓库或大量变更需要更长时间处理
   o 系统资源(CPU、内存、IO)不足
2. 同步队列积压：
   o 检查sudo gitlab-rails runner
   “puts Gitlab::Geo.secondary_nodes.first&.projects_count” 查看待同步项目数
   o 使用 sudo gitlab-rails geo:status 检查同步状态
3. 配置问题：
   o Geo 配置不正确
   o 防火墙或网络策略阻止了节点间通信
   o 证书问题导致连接失败
4. 同步服务未运行：
   o Geo 日志复制服务(geo-logcursor)可能停止
   o 后台作业处理器可能有问题
5. 特定项目问题：
   o 项目可能被手动设置为"不同步"
   o 项目可能超过了大小限制

---