Geo 验证测试

Geo 团队会对常见部署配置进行手动测试和验证，确保在 GitLab 次要版本升级和 PostgreSQL 数据库主版本升级时，Geo 功能正常工作。

本节记录了验证测试日志及相关问题链接。

GitLab 升级

以下是我们执行的 GitLab 升级验证测试。

2020年7月

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.10.12 升级到 13.0.10 版本包。作为修复多节点 Geo 部署零停机升级流程/说明问题的一部分，我们通过循环流水线、HAProxy 统计面板以及记录两个节点就绪状态的脚本来监控停机情况。
• 结果：部分成功，因为我们在主站点和从站点升级过程中观察到了停机。
• 后续问题/行动：
  • 调查 reconfigure 和 hup 为何会导致多节点 Geo 部署停机
  • Geo 多节点部署升级：调查升级非部署节点时的顺序问题

在 Geo 主站点上从 repmgr 切换到 Patroni：

• 描述：在多节点 Geo 主站点上测试从 repmgr 切换到 Patroni。使用编排工具部署了一个由 repmgr 管理的 3 个数据库节点的 Geo 安装环境。通过此方法，我们还解决了验证使用 Patroni 和 PostgreSQL 11 的 Geo 安装的相关问题。
• 结果：部分成功。我们在主站点启用了 Patroni 并在从站点设置了数据库复制。但发现 Patroni 重启时会删除从站点的复制槽。另一个问题是当 Patroni 在集群中选举新领导者时，从站点无法自动跟随新领导者。在这些问题解决前，我们无法正式支持并推荐在 Geo 安装中使用 Patroni。
• 后续问题/行动：
  • 调查 Patroni 与 Geo 单节点从站点的永久复制槽问题

2020年6月

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.9.10 升级到 12.10.12 版本包。通过循环流水线和 HAProxy 统计面板监控停机情况。
• 结果：部分成功，因为我们在主站点和从站点升级过程中观察到了停机。
• 后续问题/行动：
  • 修复多节点 Geo 部署的零停机升级流程/说明
  • Geo:check Rake 任务：若节点未运行 Puma 则跳过 AuthorizedKeysCommand 检查
  • 在下次升级问题中更新说明，加入监控 HAProxy 面板的要求

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.8.1 升级到 12.9.10 版本包。
• 结果：部分成功，因为演示期间未运行循环流水线来验证零停机。
• 后续问题：
  • 明确 Puma 应如何包含部署节点
  • 调查升级到 12.9.10 后的 MR 创建失败问题（已关闭，确认为误报）。

2020年2月

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.7.5 升级到最新的 GitLab 12.8 版本包。
• 结果：部分成功，因为演示期间未运行循环流水线来监控停机。

2020年1月

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.6.x 升级到最新的 GitLab 12.7 版本包。
• 结果：升级测试成功。
• 后续问题：
  • 调查 Geo 端到端测试失败问题。
  • 为 Geo 端到端测试添加更多日志。
  • 零停机升级期间服务重启过多。

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.5.7 升级到 GitLab 12.6.6。
• 结果：升级测试成功。
• 后续问题： 更新零停机升级文档，确保部署节点未被使用。

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.4.x 升级到最新的 GitLab 12.5 版本包。
• 结果：升级测试成功。
• 后续问题：
  • 调查主节点 HTTP 推送规范失败原因。
  • 调查是否需要修改文档以包含刷新外部表任务。

2019年10月

升级 Geo 多节点安装：

• 描述：在多节点配置中测试从 GitLab 12.3.5 升级到 GitLab 12.4.1。
• 结果：升级测试成功。

升级 Geo 多节点安装：

• 描述：测试从 GitLab 12.2.8 升级到 GitLab 12.3.5。
• 结果：升级测试成功。

升级 Geo 多节点安装：

• 描述：测试从 GitLab 12.1.9 升级到 GitLab 12.2.8。
• 结果：因可能的配置问题，部分成功。

PostgreSQL 升级

以下是我们执行的 PostgreSQL 升级验证测试。

2021年9月

验证使用 PostgreSQL 13 的 Geo 安装：

• 描述：PostgreSQL 13 在 GitLab 14.1 中作为可选版本提供，我们测试了启用 PostgreSQL 13 时 Geo 的新安装环境。
• 结果：使用 GitLab 环境工具包成功构建了 Geo 和 PostgreSQL 13 环境，并对该环境执行 Geo QA 测试，未发现失败。

2020年9月

验证 Geo 安装的 PostgreSQL 12 升级：

• 描述：PostgreSQL 12 在 GitLab 13.3 中作为可选版本提供，我们测试了现有 Geo 安装从 PostgreSQL 11 升级到 12。在修复支持 PostgreSQL 12 的问题后，我们还重新测试了带 Geo 的新 GitLab 安装。这些测试使用 GitLab 13.4 的每日构建版本完成。
• 结果：在主从站点均使用单数据库节点的 Geo 部署测试成功。在 Geo 主站点上遇到了 repmgr 和 Patroni 管理的 PostgreSQL 集群的已知问题。在问题解决前，不建议在主站点使用带数据库集群的 PostgreSQL 12。
• PostgreSQL 集群的已知问题：
  • 确保 Patroni 检测到 PostgreSQL 更新
  • 允许在 Patroni 中配置永久复制槽

2020年8月

验证使用 PostgreSQL 12 的 Geo 安装：

• 描述：在 PostgreSQL 12 成为 GitLab 13.3 可选版本之前，我们测试了启用 PostgreSQL 12 并安装 Geo 的 GitLab 13.3 新安装环境。
• 结果：设置 Geo 从站点需要手动干预，因为 PostgreSQL 12 不再支持 recovery.conf 文件。在 Linux 包完成相关修改并验证前，不建议部署使用 PostgreSQL 12 的 Geo。
• 后续问题：
  • 更新 replicate-geo-database 以支持 PostgreSQL 12
  • 在 14.0 版本中移除 replicate-geo-database 的 PostgreSQL 12 检查

2020年4月

Geo 安装的 PostgreSQL 11 升级流程：

• 描述：在 PostgreSQL 11 成为 GitLab 12.10 默认版本之前，我们在 GitLab 12.9 中测试了 Geo 部署升级到 PostgreSQL 11。
• 结果：部分成功。在带独立跟踪数据库的多节点配置中发现问题，并对启用 Geo 时的自动升级提出担忧。
• 后续问题：
  • replicate-geo-database 错误尝试备份仓库。
  • pg-upgrade 无法升级独立的 Geo 跟踪数据库。
  • revert-pg-upgrade 无法降级 Geo 从站点独立跟踪数据库的 PostgreSQL 数据。
  • gitlab-ctl pg-upgrade 结尾时 Geo 从站点只读副本超时错误。

验证使用 PostgreSQL 11 的 Geo 安装：

• 描述：在 PostgreSQL 11 成为 GitLab 12.10 默认版本之前，我们测试了安装 PostgreSQL 11 和 Geo 的 GitLab 12.9 新安装环境。
• 结果：安装测试成功。

2019年9月

测试并验证 Geo 的 PostgreSQL 10.0 升级：

• 描述：随着 12.0 版本发布，GitLab 要求升级到 PostgreSQL 10.0。我们测试了升级到 GitLab 12.1.8 的各种场景。
• 结果：升级中发现多个问题，并在后续问题中解决。
• 后续问题：
  • 多节点 Geo 设置中 gitlab-ctl 重新配置在 Redis 节点失败。
  • Geo 多节点从 12.0.9 升级到 12.1.9 未升级 PostgreSQL。
  • 升级到 12.1.9 后，多节点设置中应用服务器的刷新外部表失败。

对象存储复制测试

以下是我们执行的额外验证测试。

2022年4月

使用基于 AWS 的对象存储验证对象存储复制：

• 描述：测试使用基于 AWS 的对象存储复制和基于 GitLab 的对象存储复制时，单个图片从主对象存储位置复制到从站点的平均耗时。测试方法为：60秒内每秒向主站点项目上传 1MB 图片，然后测量图片在从站点可用所需时间。通过 Ruby 脚本 实现。
• 结果：使用 AWS 管理的复制时，图片在站点间复制的平均耗时约 49 秒，无论站点位于同一区域还是相距较远（欧洲到美洲）均如此。使用 Geo 管理的复制时，同区域复制平均耗时仅 5 秒，但跨区域复制平均耗时增至 33 秒。

使用基于 GCP 的对象存储验证对象存储复制：

• 描述：测试使用基于 GCP 的对象存储复制和基于 GitLab 的对象存储复制时，单个图片从主对象存储位置复制到从站点的平均耗时。测试方法为：60秒内每秒向主站点项目上传 1MB 图片，然后测量图片在从站点可用所需时间。通过 Ruby 脚本 实现。
• 结果：GCP 处理复制的方式与其他云服务商不同。在 GCP 中，流程是创建单个存储桶，该存储桶可基于多区域、双区域或单区域。这意味着存储桶会根据所选选项自动在区域中存储副本。即使使用多区域，也仅在单个大洲内复制（美洲、欧洲或亚洲）。目前似乎无法使用基于 GCP 的复制实现跨大洲对象复制。对于 Geo 管理的复制，同区域复制平均耗时 6 秒，跨区域复制平均耗时仅 9 秒。

2022年1月

使用基于 Azure 的对象存储验证对象存储复制：

• 描述：测试使用基于 Azure 的对象存储复制和基于 GitLab 的对象存储复制时，单个图片从主对象存储位置复制到从站点的平均耗时。测试方法为：60秒内每秒向主站点项目上传 1MB 图片，然后测量图片在从站点可用所需时间。通过 Ruby 脚本 实现。
• 结果：使用基于 Azure 的复制时，图片从主对象存储复制到从站点的平均耗时记录为 40 秒，最长复制时间 70 秒，最短 11 秒。使用基于 GitLab 的复制时，复制完成的平均耗时 5 秒，最长 10 秒，最短 3 秒。
• 后续问题：
  • 使用基于 Azure 的对象存储验证跨区域对象存储复制

2021年5月

测试启用对象存储复制的故障转移：

• 描述：测试时 Geo 的对象存储复制功能处于测试阶段。我们验证了对象存储复制按预期工作，且故障转移后数据存在于新主站点。
• 结果：测试成功。对象存储中的数据在故障转移后完成复制并存在。
• 后续问题：
  • Geo：无法复制初始 Monitoring 项目

其他测试

2020年8月

在 Geo 部署中测试 Gitaly 集群：

• 描述：测试在 Geo 主从站点均配置 Gitaly 集群的部署环境。在 Geo 主站点触发 Gitaly 集群自动故障转移，并运行 Geo 端到端测试。然后在 Geo 从站点触发 Gitaly 集群故障转移，重新运行 Geo 端到端测试。
• 结果：在 Geo 主站点 Gitaly 集群故障转移前后、Geo 从站点 Gitaly 集群故障转移前后，端到端测试均成功。