{{< details >}}
- Tier: 专业版, 旗舰版
- Offering: 私有化部署
{{< /details >}}
自动后台验证确保传输的数据与计算出的校验和匹配。如果 主 站点上的数据校验和与 次 站点上的数据校验和匹配,则数据传输成功。在计划的故障转移之后,任何损坏的数据可能会 丢失,这取决于损坏的程度。
如果在 主 站点上验证失败,这表明 Geo 正在复制损坏的对象。您可以从备份中恢复它或将其从 主 站点删除以解决问题。
如果在 主 站点上验证成功但在 次 站点上验证失败,这表明对象在复制过程中被损坏。Geo 积极尝试纠正验证失败,标记仓库以进行重新同步,并设置退避期。如果您想重置这些失败的验证,应遵循这些说明。
如果验证显著滞后于复制,请考虑在安排计划故障转移之前给予站点更多时间。
仓库验证
在 主 站点上:
在 次 站点上:
使用校验和比较 Geo 站点
为了检查 Geo 次 站点的健康状况,我们使用校验和来检查 Git 引用列表及其值。校验和包含 HEAD
、heads
、tags
、notes
和 极狐GitLab 特定引用,以确保真正的一致性。如果两个站点具有相同的校验和,则它们肯定持有相同的引用。我们在每次更新后为每个站点计算校验和,以确保它们都同步。
仓库重新验证
由于错误或瞬时基础设施故障,Git 仓库可能会意外更改而未被标记为验证。Geo 不断重新验证仓库以确保数据的完整性。默认和推荐的重新验证间隔为 7 天,尽管可以设置为短至 1 天。较短的间隔降低风险但增加负载,反之亦然。
在 主 站点上:
重置验证失败的项目
Geo 积极尝试纠正验证失败,标记仓库以进行重新同步并设置退避期。您还可以通过 UI 或 Rails 控制台手动重新同步和重新验证个别组件。
解决校验和不匹配的问题
如果 主 站点和 次 站点的校验和验证不匹配,原因可能不明显。要找出校验和不匹配的原因:
- 在 主 站点上:
- 在左侧边栏底部,选择 管理员。
- 在左侧边栏,选择 概览 > 项目。
- 找到您想要检查校验和差异的项目并选择其名称。
- 在项目管理页面上,获取 存储名称 和 相对路径 字段中的值。
-
在 主 站点上的 Gitaly 节点 和 次 站点上的 Gitaly 节点 上,进入项目的仓库目录。如果使用 Gitaly 集群,在运行这些命令之前,检查它是否处于健康状态。
默认路径为
/var/opt/gitlab/git-data/repositories
。如果仓库存储被自定义,请检查服务器上的目录布局以确认:cd /var/opt/gitlab/git-data/repositories
-
在 主 站点上运行以下命令,将输出重定向到文件:
git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-site-refs
-
在 次 站点上运行以下命令,将输出重定向到文件:
git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-site-refs
-
将前一步的文件复制到同一系统,并对内容进行差异比较:
diff primary-site-refs secondary-site-refs
-
当前限制
有关支持的复制和验证方法的更多信息,请参见支持的 Geo 数据类型。