{{< details >}}
- Tier: 专业版, 旗舰版
- Offering: 私有化部署
{{< /details >}}
自动后台验证确保传输的数据与计算出的校验和匹配。如果 主 站点上的数据校验和与 次 站点上的数据校验和匹配，则数据传输成功。在计划的故障转移之后，任何损坏的数据可能会 丢失，这取决于损坏的程度。
如果在 主 站点上验证失败，这表明 Geo 正在复制损坏的对象。您可以从备份中恢复它或将其从 主 站点删除以解决问题。
如果在 主 站点上验证成功但在 次 站点上验证失败，这表明对象在复制过程中被损坏。Geo 积极尝试纠正验证失败，标记仓库以进行重新同步，并设置退避期。如果您想重置这些失败的验证，应遵循这些说明。
如果验证显著滞后于复制，请考虑在安排计划故障转移之前给予站点更多时间。
仓库验证
在 主 站点上：
- 在左侧边栏底部，选择 管理员。
- 选择 Geo > 站点。
-
展开该站点的 验证信息 标签以查看仓库和维基的自动校验状态。成功显示为绿色，待处理工作为灰色，失败为红色。
在 次 站点上：
- 在左侧边栏底部，选择 管理员。
- 选择 Geo > 站点。
-
展开该站点的 验证信息 标签以查看仓库和维基的自动校验状态。成功显示为绿色，待处理工作为灰色，失败为红色。
使用校验和比较 Geo 站点
为了检查 Geo 次 站点的健康状况，我们使用校验和来检查 Git 引用列表及其值。校验和包含 HEAD、heads、tags、notes 和 极狐GitLab 特定引用，以确保真正的一致性。如果两个站点具有相同的校验和，则它们肯定持有相同的引用。我们在每次更新后为每个站点计算校验和，以确保它们都同步。
仓库重新验证
由于错误或瞬时基础设施故障，Git 仓库可能会意外更改而未被标记为验证。Geo 不断重新验证仓库以确保数据的完整性。默认和推荐的重新验证间隔为 7 天，尽管可以设置为短至 1 天。较短的间隔降低风险但增加负载，反之亦然。
在 主 站点上：
- 在左侧边栏底部，选择 管理员。
- 选择 Geo > 站点。
-
为 主 站点选择 编辑 以自定义最小重新验证间隔：
重置验证失败的项目
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 数据类型。