Geo 验证测试
Tier: 专业版，旗舰版
Offering: 私有化部署
Geo 团队对常见的部署配置进行手动测试和验证，以确保在极狐GitLab 次要版本和主要 PostgreSQL 数据库版本之间升级时，Geo 能正常工作。
本节记录了验证测试日志以及相关议题的链接。
极狐GitLab 升级
以下是已进行的极狐GitLab 升级验证测试。
2020 年 7 月
- 描述：测试从 极狐GitLab 12.10.12 软件包升级到 13.0.10 的多节点配置。作为修复 Geo 多节点部署的零停机升级流程/说明 议题的一部分，我们使用循环流水线、HAProxy 统计仪表板和一个在两个站点上记录就绪状态的脚本，监控了停机时间。
- 结果：部分成功，因为在主站点和次要站点升级期间我们观察到了停机时间。
- 后续议题/操作：
在 Geo 主站点上从 repmgr 切换到 Patroni:
- 描述：测试了在多节点 Geo 主站点上从 repmgr 切换到 Patroni 的流程。使用协调器工具 部署了一个包含由 repmgr 管理的 3 个数据库节点的 Geo 安装。通过这种方式，我们还得以解决一个相关问题：使用 Patroni 和 PostgreSQL 11 验证 Geo 安装。
- 结果：部分成功。我们已在主站点启用 Patroni，并在次要站点设置了数据库复制。然而，我们发现每当 Patroni 重启时，它会删除次要站点的复制槽。另一个问题是，当 Patroni 选举集群中的新领导者时，次要站点无法自动跟随新的领导者。在这些问题解决之前，我们无法正式支持并推荐将 Patroni 用于 Geo 安装。
- 后续议题/操作：
2020 年 6 月
- 描述：测试从 极狐GitLab 12.9.10 软件包升级到 12.10.12 的多节点配置。使用循环流水线和 HAProxy 统计仪表板监控停机时间。
- 结果：部分成功，因为在主站点和次要站点升级期间我们观察到了停机时间。
- 后续议题/操作：
- 描述：测试从 极狐GitLab 12.8.1 软件包升级到 12.9.10 的多节点配置。
- 结果：部分成功，因为在演示过程中我们没有运行循环流水线来验证零停机。
- 后续议题：
2020 年 2 月
- 描述：测试从 极狐GitLab 12.7.5 升级到最新的 极狐GitLab 12.8 软件包的多节点配置。
- 结果：部分成功，因为在演示过程中我们没有运行循环流水线来监控停机时间。
2020 年 1 月
- 描述：测试从 极狐GitLab 12.6.x 升级到最新的 极狐GitLab 12.7 软件包的多节点配置。
- 结果：升级测试成功。
- 后续议题：
- 描述：测试从 极狐GitLab 12.5.7 升级到 GitLab 12.6.6 的多节点配置。
- 结果：升级测试成功。
- 后续议题： 更新零停机升级文档以确保部署节点未被使用。
- 描述：测试从 极狐GitLab 12.4.x 升级到最新的 极狐GitLab 12.5 软件包的多节点配置。
- 结果：升级测试成功。
- 后续议题：
2019 年 10 月
- 描述：测试从 极狐GitLab 12.3.5 升级到 GitLab 12.4.1 的多节点配置。
- 结果：升级测试成功。
- 描述：测试从 极狐GitLab 12.2.8 升级到 GitLab 12.3.5。
- 结果：升级测试成功。
- 描述：测试从 极狐GitLab 12.1.9 升级到 GitLab 12.2.8。
- 结果：部分成功，可能是由于配置错误问题。
PostgreSQL 升级
以下是已进行的 PostgreSQL 升级验证测试。
2021 年 9 月
- 描述：随着 PostgreSQL 13 在 极狐GitLab 14.1 中作为可选版本提供，我们测试了在启用 PostgreSQL 13 的情况下全新安装 极狐GitLab 与 Geo。
- 结果：使用 极狐GitLab 环境工具套件 成功搭建了包含 Geo 和 PostgreSQL 13 的环境，并针对该环境执行了 Geo QA 测试，未出现失败。
2020 年 9 月
- 描述：随着 PostgreSQL 12 在 极狐GitLab 13.3 中作为可选版本提供，我们测试了将现有的 Geo 安装从 PostgreSQL 11 升级到 12 的过程。我们还在对支持 PostgreSQL 12 的修复完成后，重新测试了包含 Geo 的 极狐GitLab 全新安装。这些测试均使用 极狐GitLab 13.4 的每日构建版本进行。
- 结果：对于主站点和次要站点上各有一个数据库节点的 Geo 部署，测试成功。我们在主站点上遇到了 repmgr 和 Patroni 管理的 PostgreSQL 集群的已知问题。在问题解决之前，不建议在主站点上使用带有数据库集群的 PostgreSQL 12。
- PostgreSQL 集群的已知问题：
2020 年 8 月
- 描述：在 PostgreSQL 12 作为可选版本在 极狐GitLab 13.3 中提供之前，我们测试了启用 PostgreSQL 12 并安装 Geo 的 极狐GitLab 13.3 全新安装。
- 结果：设置 Geo 次要站点需要手动干预，因为 recovery.conf 文件在 PostgreSQL 12 中不再受支持。我们建议在 Linux 软件包做出相应更改并验证之前，不要部署 PostgreSQL 12 的 Geo。
- 后续议题：
2020 年 4 月
- 描述：在 PostgreSQL 11 成为 极狐GitLab 12.10 默认 PostgreSQL 版本之前，我们测试了在 极狐GitLab 12.9 的 Geo 部署中升级到 PostgreSQL 11。
- 结果：部分成功。在具有单独跟踪数据库的多节点配置中发现了问题，并对启用 Geo 时允许自动升级提出了关切。
- 后续议题：
- 描述：在 PostgreSQL 11 成为 极狐GitLab 12.10 默认 PostgreSQL 版本之前，我们测试了使用 PostgreSQL 11 安装 Geo 的 极狐GitLab 12.9 全新安装。
- 结果：安装测试成功。
2019 年 9 月
测试并验证针对 Geo 的 PostgreSQL 10.0 升级:
- 描述：在 12.0 版本中，极狐GitLab 要求升级到 PostgreSQL 10.0。我们测试了多种升级到 极狐GitLab 12.1.8 的场景。
- 结果：升级过程中发现了多个问题，并在后续议题中予以解决。
- 后续议题：
对象存储复制测试
以下是已执行的额外验证测试。
2022 年 4 月
- 描述：测试了使用基于 AWS 的对象存储复制和基于 极狐GitLab 的对象存储复制时，单个镜像从主对象存储位置复制到次要站点所需的平均时间。测试方法是：每分钟向主站点的项目上传一个 1 MB 的镜像，持续 60 秒。然后测量镜像在次要站点上可用所需的时间。此测试使用一个 Ruby 脚本 完成。
- 结果：使用 AWS 管理的复制时，镜像在站点之间复制的平均时间约为 49 秒，无论站点位于同一区域还是相距更远（欧洲到美洲）都是如此。使用 Geo 管理的复制时，在同一区域内的平均复制时间仅为 5 秒，然而跨区域复制时，平均时间上升至 33 秒。
2022 年 1 月
- 描述：测试了使用基于 Azure 的对象存储复制和基于 极狐GitLab 的对象存储复制时，单个镜像从主对象存储位置复制到次要站点所需的平均时间。测试方法是：每分钟向主站点的项目上传一个 1 MB 的镜像，持续 60 秒。然后测量镜像在次要站点上可用所需的时间。此测试使用一个 Ruby 脚本 完成。
- 结果：使用基于 Azure 的复制时，镜像从主对象存储复制到次要站点的平均时间记录为 40 秒，最长复制时间为 70 秒，最短为 11 秒。使用基于 极狐GitLab 的复制时，完成复制的平均时间为 5 秒，最长复制时间为 10 秒，最短为 3 秒。
- 后续议题：
2021 年 5 月
- 描述：测试时，Geo 的对象存储复制功能处于测试阶段。我们测试了对象存储复制是否按预期工作，并且故障转移后数据是否存在于新的主站点上。
- 结果：测试成功。对象存储中的数据已复制，并在故障转移后存在。
- 后续议题：
其他测试
2020 年 8 月
- 描述：测试了在主 Geo 站点和次要 Geo 站点上均配置了 Gitaly 集群的 Geo 部署。触发了主 Geo 站点上的自动 Gitaly 集群故障转移，并运行了端到端 Geo 测试。随后触发了次要 Geo 站点上的 Gitaly 集群故障转移，并重新运行了端到端 Geo 测试。
- 结果：在主站点发生 Gitaly 集群故障转移前后，以及在次要站点发生 Gitaly 集群故障转移前后，端到端测试均成功。