自动后台验证

自动后台验证可确保传输的数据与计算的校验和相匹配。如果主站点上的数据校验和与辅助站点上的数据校验和匹配，则表示数据已成功传输。在计划内故障转移后，任何已损坏的数据都可能丢失，具体取决于损坏的程度。

如果在主站点上验证失败，则表明 Geo 正在复制一个已损坏的对象。您可以从备份恢复它，或将其从主站点上移除以解决问题。

如果在主站点上验证成功，但在辅助站点上失败，则表明该对象在复制过程中已损坏。Geo 会主动尝试修正验证失败，通过标记仓库以在退避期后进行重新同步。如果您想为这些失败的验证重置验证状态，则应遵循这些说明。

如果验证进度明显落后于复制进度，请考虑在安排计划内故障转移前给予站点更多时间。

仓库验证

在主站点上：

1. 在左侧边栏底部，选择管理员。

2. 选择 Geo > 站点。

3. 展开该站点的验证信息选项卡，以查看仓库和 Wiki 的自动校验和状态。成功显示为绿色，待处理工作显示为灰色，失败显示为红色。

   

在辅助站点上：

1. 在左侧边栏底部，选择管理员。

2. 选择 Geo > 站点。

3. 展开该站点的验证信息选项卡，以查看仓库和 Wiki 的自动校验和状态。成功显示为绿色，待处理工作显示为灰色，失败显示为红色。

   

使用校验和比较 Geo 站点

为了检查 Geo 辅助站点的健康状况，我们使用一个基于 Git 引用列表及其值的校验和。该校验和包含 HEAD、heads、tags、notes 和 GitLab 特定的引用，以确保真正的一致性。如果两个站点具有相同的校验和，那么它们肯定持有相同的引用。我们在每次更新后为每个站点计算校验和，以确保它们都保持同步。

仓库重新验证

由于错误或临时的基础设施故障，Git 仓库可能会在未被标记为需要验证的情况下发生意外更改。Geo 会持续重新验证仓库，以确保数据的完整性。默认且推荐的重新验证间隔为 7 天，但也可以设置为短至 1 天的间隔。更短的间隔可以降低风险，但会增加负载，反之亦然。

在主站点上：

1. 在左侧边栏底部，选择管理员。

2. 选择 Geo > 站点。

3. 为主站点选择编辑，以自定义最小重新验证间隔：

   

重置验证失败的项目

Geo 会主动尝试修正验证失败，通过标记仓库以在退避期后进行重新同步。您也可以手动通过用户界面或 Rails 控制台重新同步和重新验证单个组件。

解决校验和不匹配的问题

如果主站点和辅助站点的校验和验证不匹配，其原因可能并不明显。要查找校验和不匹配的原因：

1. 在主站点上：

   1. 在左侧边栏底部，选择管理员。
   2. 在左侧边栏上，选择概览 > 项目。
   3. 找到您要检查校验和差异的项目，并选择其名称。
   4. 在项目管理页面上，获取存储名称和相对路径字段中的值。

2. 在主站点上的 Gitaly 节点和辅助站点上的 Gitaly 节点上，转到项目的仓库目录。如果使用 Gitaly Cluster (Praefect)，请在运行这些命令之前，检查其是否处于健康状态。

   默认路径是 /var/opt/gitlab/git-data/repositories。如果自定义了仓库存储，请检查您服务器上的目录布局以确保准确：

   cd /var/opt/gitlab/git-data/repositories

   1. 在主站点上运行以下命令，并将输出重定向到文件：

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-site-refs

   2. 在辅助站点上运行以下命令，并将输出重定向到文件：

      git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-site-refs

   3. 将前面步骤中生成的文件复制到同一系统上，并对它们的内容进行比较：

      diff primary-site-refs secondary-site-refs

当前限制

有关支持的复制和验证方法的更多信息，请参阅支持的 Geo 数据类型。