gitlab还原到上个版本_一次近乎完美的PostgreSQL版本大升级

怎样实现一次近乎完美的数据库版本大升级？本文详细介绍了 GitLab 将 PostgreSQL 从 9.6 升级到 11 版本的工作。

2020 年 5 月，我们与 OnGres 合作，对 GitLab 上的 Postgres 集群进行版本大更新，从 9.6 版本升级到 11 版本。升级全部在维护窗口内运行，没有丝毫差错；更新中所有涉及的内容、计划、测试，以及全流程自动化，全部进行拆包，只为实现一次近乎完美的 PostgreSQL 升级。

本次版本更新，我们面临的最大难题在于如何利用一个规划完善的 pg_upgrade，方便且高效地对整体项目进行重要版本升级。为此，我们需要制定一个回滚计划，以保证 12 节点集群的 6 TB 数据一致的同时，优化恢复目标时间(RTO)后的容量，为 600 万用户提供每秒 300000 次的聚合交易服务。

解决工程难题的最佳方案是按照蓝图和设计文档行事。在创建蓝图的过程中，我们需要定义目标问题，评估最合适的解决方案，并考虑每个解决方案的优缺点。

在此，我们附上为这个项目准备的蓝图链接。

https://gitlab.com/gitlab-com/gl-infra/readiness/-/tree/master/library/database/postgres/Postgresql-upgrade/blueprint/

一、我们为什么要升级PostgreSQL

我们决定在 GitLab 13.0 中停止对 PostgreSQL 10.0 的支持，而 PostgreSQL 9.6 版本将在 2021 年 11 月 EOL(项目终止)，因此，我们需要采取相应的行动。

下面是 PostgreSQL 9.6 和 11 版本之间的主要区别：

• 表分区支持 LIST、RANGE，以及 HASH；

• 存储过程支持事务；

• 即时编译(JIT)加快查询表达式的运行速度；

• 并行查询，增加并行化数据定义功能；

• 新版本的 PostgreSQL 继承了版本 10 中的“逻辑复制——分发数据的发布 / 订阅框架”，该功能可以使日后的升级更加顺滑，简化了其他相关流程；

• 基于 Quorum 的提交(commit)，确保事务能在集群中指定节点进行提交；

• 提升了通过分区表进行查询的性能。

二、环境与架构

PostgreSQL 集群，其基础架构容量由 12 个服务于 OLTP 以及异步管道的 n1-highmem-96 GCP 示例组成。同时，它还有两个不同规格的 BI 节点，每个节点都有 96 个 CPU 内核以及 614GB 的 RAM。HA 集群通过 Patroni 进行管理和配置，以保证 Consul 集群及其所有复制体在异步流复制中，使用复制槽和 WAL 对 GCS 存储桶进行复制工作时的 leader 选举一致性。

https://github.com/zalando/patroni

我们的配置目前使用的是 Patroni HA 解决方案，它会不断收集集群、leader 检测，以及节点可用性的关键信息。该解决方案采用 Consul 的 DNS 服务等关键功能来实现，进而更新 PgBouncer 端点，确保读写和只读流量使用不同架构。