• 用例
  • Gitaly 集群
• 工作原理
  • 架构
• 运行 Geo 的要求
  • 防火墙规则
    • 内部 URL
  • Geo 跟踪数据库
  • Geo Log Cursor
• 限制
• 设置说明
• 安装后文档
  • 配置 Geo
  • 升级 Geo
  • 暂停和恢复复制
  • 为多个节点配置 Geo
  • 配置 Geo 使用对象存储
  • 灾难恢复
  • 复制 Container Registry
  • 调试 Geo
  • 回填
• 删除 Geo 站点
• 禁用 Geo
• 日志文件

Geo

Geo 是广泛分布的开发团队的解决方案，可作为灾难恢复策略的一部分提供热备份。

Geo 提供极狐GitLab 实例的本地只读站点。这可以减少克隆和获取大型仓库所需的时间，从而加快开发速度。

为了确保您使用正确版本的文档，请访问 JihuLab.com 上的 Geo 页面，并从 切换分支/标签 下拉列表中选择适当的版本。例如，v13.7.6-ee。

Geo 使用 Geo 术语文档中描述的一组已定义的术语。 请务必熟悉这些术语。

用例

实施 Geo 有以下优势：

• 将分布式开发人员克隆和获取大型仓库和项目的时间从几分钟缩短到几秒钟。
• 让您的所有开发人员都能贡献想法，并且并行工作，无论他们身在何处。
• 平衡您的主要和次要站点之间的只读负载。

此外：

• 除了读取极狐GitLab Web 界面中可用的任何数据外，还可用于克隆和获取项目（请参阅限制）。
• 克服远程办公室之间的缓慢连接，通过提高分布式团队的速度来节省时间。
• 有助于减少自动化任务、自定义集成和内部工作流程的加载时间。
• 可以在灾难恢复场景中快速故障转移到次要站点。
• 允许到次要站点的计划故障转移。

Geo 提供：

• 只读次要站点：维护一个主要极狐GitLab 站点，同时仍为每个分布式团队启用只读次要站点。
• 身份验证系统挂钩：次要站点从主要实例接收所有身份验证数据（如用户账户和登录名）。
• 直观的用户界面：次要站点使用您的团队已经习惯的相同 Web 界面。此外，还有视觉通知可以阻止写入操作，并清楚地表明用户在次要站点上。

Gitaly 集群

Geo 不应与 Gitaly 集群混淆。有关 Geo 和 Gitaly 集群之间差异的更多信息，请参阅与 Geo 对比。

工作原理

除了读取任何数据之外，您的 Geo 实例还可用于克隆和获取项目。这使得远距离处理大型仓库的速度更快。

启用 Geo 后：

• 原始实例称为主要站点。
• 复制的只读站点称为次要站点。

请记住：

• 次要站点与主要站点对话：
  • 获取登录用户数据 (API)。
  • 复制仓库、LFS 对象和附件 (HTTPS + JWT)。
• 主要站点不与次要站点通信以通知更改 (API)。
• 您可以直接推送到次要站点（对于 HTTP 和 SSH，包括 Git LFS）。
• 使用 Geo 时有限制。

架构

下图说明了 Geo 的底层架构。

在此图中：

• 有主要站点和一个次要站点的详细信息。
• 只能在主要站点上执行对数据库的写入。 次要站点通过 PostgreSQL 流复制接收数据库更新。
• 如果存在，LDAP 服务器 应配置为针对 灾难恢复 方案进行复制。
• 次要站点使用受 JWT 保护的特殊授权对主要站点执行不同类型的同步：
  • 通过 HTTPS 通过 Git 克隆/更新仓库。
  • 附件、LFS 对象和其他文件使用私有 API 端点通过 HTTPS 下载。

从执行 Git 操作的用户的角度来看：

• 主要站点表现为一个完整的读写极狐GitLab 实例。
• 次要站点是只读的，但代理 Git 推送操作到主要站点。这使得次要站点本身似乎支持推送操作。

为了简化图表，省略了一些必要的组件。

• Git over SSH 需要 gitlab-shell 和 OpenSSH。
• 需要通过 HTTPS 的 Git gitlab-workhorse。

次要站点需要两个不同的 PostgreSQL 数据库：

• 从极狐GitLab 主数据库流式传输数据的只读数据库实例。
• 另一个数据库实例由次要站点内部用于记录已复制的数据。

在次要站点中，有一个额外的守护进程：Geo Log Cursor。

运行 Geo 的要求

运行 Geo 需要以下条件：

• 支持 OpenSSH 6.9 或更高版本的操作系统（需要快速查找数据库中授权的 SSH 密钥）。已知以下操作系统附带当前版本的 OpenSSH：
  • CentOS 7.4 或更高版本
  • Ubuntu 16.04 或更高版本
• PostgreSQL 12 或 13 与流复制
  • 请注意，PostgreSQL 12 已弃用，将在 16.0 版本中删除
• Git 2.9 或更高版本
• 使用 LFS 时用户端的 Git-lfs 2.4.2 或更高版本
• 所有站点都必须运行相同的极狐GitLab 版本。
• 所有站点都必须运行相同的 PostgreSQL 版本。
  • 如果在 Geo 站点之间使用不同的操作系统版本，请检查 OS 区域设置数据的跨 Geo 站点兼容性以避免数据库索引的静默损坏。
• 所有站点必须定义相同的仓库存储。

此外，请查看极狐GitLab 最低要求，我们建议您使用最新版本的极狐GitLab 以获得更好的体验。

防火墙规则

下表列出了必须在主要和次要站点之间为 Geo 开放的基本端口。为了简化故障转移，我们建议在两个方向上打开端口。

在软件包默认值文档中查看极狐GitLab 使用的端口的完整列表。

内部 URL

从任何 Geo 次要站点到主 Geo 站点的 HTTP 请求使用主 Geo 站点的内部 URL。如果在管理中心的主 Geo 站点设置中未明确定义，则使用主要站点公开 URL。

要更新主 Geo 站点的内部 URL：

1. 在左侧边栏中，选择 搜索或转到。
2. 选择 管理中心。
3. 选择 Geo > 站点。
4. 在主要站点上选择 编辑。
5. 更改 内部 URL，然后选择 保存更改。

Geo 跟踪数据库

跟踪数据库实例用作元数据来控制本地实例磁盘上需要更新的内容。例如：

• 下载新 assets。
• 获取新的 LFS 对象。
• 从最近更新的仓库中获取更改。

因为复制的数据库实例是只读的，所以我们需要为每个次要站点添加这个额外的数据库实例。

Geo Log Cursor

这个守护进程：

• 读取由主要站点复制到次要数据库实例的事件日志。
• 使用必须执行的更改更新地理跟踪数据库实例。

当跟踪数据库实例中的某些内容被标记为要更新时，次要站点上运行的异步作业会执行所需的操作并更新状态。

这种新架构使极狐GitLab 能够灵活应对站点之间的连接问题。次要站点与主要站点断开连接的时间无关紧要，因为它能够以正确的顺序重播所有事件并再次与主要站点同步。

限制

• 直接推送到次要站点会将请求重定向（对于 HTTP）或代理（对于 SSH）到主要站点的请求，而不是直接处理它，除非在 URI 中使用嵌入了凭据的 HTTP 上的 Git。例如，https://user:password@secondary.tld。
• 主要站点必须在线才能进行 OAuth 登录。现有会话和 Git 不受影响。
• 安装需要多个手动步骤，视情况而定，总共可能需要大约一个小时。
• 议题/合并请求的实时更新（例如，通过长轮询）在次要站点上不起作用。
• 极狐GitLab Runners 无法在次要站点注册。
• 选择性同步仅限制复制哪些仓库和文件。整个 PostgreSQL 数据仍然被复制。选择性同步不是为了适应合规性/出口控制用例而构建的。
• Pages 访问控制在次要节点上无效。
• 极狐GitLab chart 的 Geo 不支持统一 URL。
• 由于所有未升级的次要站点的完全重新同步和重新配置，多次要站点的灾难恢复会导致停机。
• 对于 Git over SSH，为了使项目克隆 URL 正确显示，无论您正在浏览哪个站点，次要站点都必须使用与主站点相同的端口。
• 对于通过 SSH 对次要站点进行 Git 的推送，不适用于超过 1.86 GB 的推送。
• 备份无法在次要站点上运行。

设置说明

有关设置说明，请参阅设置 Geo。

安装后文档

在次要站点上安装极狐GitLab 并执行初始配置后，请参阅以下文档获取安装后信息。

配置 Geo

有关配置 Geo 的信息，请参阅 Geo 配置。

升级 Geo

有关如何将您的 Geo 站点更新到最新极狐GitLab 版本的信息，请参阅升级 Geo 站点。

暂停和恢复复制

引入于 13.2 版本。

在某些情况下，例如在升级或计划故障转移期间，需要暂停主节点和次要节点之间的复制。

暂停和恢复复制是通过命令行工具从启用了 postgresql 服务的次要站点中的节点完成的。

如果 postgresql 位于独立数据库节点上，请确保该节点上的 gitlab.rb 包含配置行 gitlab_rails['geo_node_name'] = 'node_name'，其中 node_name 与 geo_name_name 在应用程序节点上相同。

暂停：（从次要节点）

gitlab-ctl geo-replication-pause

恢复：（从次要节点）

gitlab-ctl geo-replication-resume

为多个节点配置 Geo

有关为多个节点配置 Geo 的信息，请参阅用于多个服务器的 Geo。

配置 Geo 使用对象存储

有关配置 Geo 使用对象存储的信息，请参阅使用对象存储的 Geo。

灾难恢复

有关在灾难恢复情况下，使用 Geo 来减轻数据丢失和恢复服务的信息，请参阅灾难恢复。

复制 Container Registry

有关如何复制 Container Registry 的更多信息，请参阅次要站点的 Container Registry。

调试 Geo

有关调整 Geo 的更多信息，请参阅调试 Geo。

回填

设置次要站点后，它会开始在称为回填的过程中从主要站点复制丢失的数据。您可以从浏览器中的主要站点的 Geo 节点仪表盘监控每个 Geo 站点上的同步过程。

回填期间发生的失败计划在回填结束时重试。

删除 Geo 站点

有关删除 Geo 站点的详细信息，请参阅删除次要 Geo 站点。

禁用 Geo

要了解如何禁用 Geo，请参阅禁用 Geo。

日志文件

Geo 将结构化日志消息存储在 geo.log 文件中。对于 Linux 软件包安装实例，此文件位于 /var/log/gitlab/gitlab-rails/geo.log。

此文件包含有关 Geo 何时尝试同步仓库和文件的信息。文件中的每一行都包含一个可以提取的单独 JSON 条目。例如，Elasticsearch 或 Splunk。

例如：

{"severity":"INFO","time":"2017-08-06T05:40:16.104Z","message":"Repository update","project_id":1,"source":"repository","resync_repository":true,"resync_wiki":true,"class":"Gitlab::Geo::LogCursor::Daemon","cursor_delay_s":0.038}

此消息显示 Geo 检测到项目 1 需要更新仓库。