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/
1. 我们为什么要晋级 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），确保事务能在集群中指定节点停止提交。
提升了经过火区表停止查询的功用
2. 环境与架构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 端点，确保读写和只读流量运用不同架构。
GitLab.com 架构
由于 HA 的缘故，其中两个复制体不在只读效劳器列表池中，而是由 Consul DNS 支持，效劳于 API。对 GitLab 架构几次改良后，我们得以将项目全体降到 7 个节点。
此外，我们的整个集群平均每周要处置大约 181000 个买卖每秒，如下图所示，流量会在周一有清楚添加，并在周一至周五 / 六内保持该吞吐量。我们需求让维护影响到尽量少的用户，因此流量数据的统计关于设置适宜的维护窗口至关重要。
GitLab.com 上衔接数量统计
项目全体在全天中最忙碌的时辰可以抵达 25000 买卖每秒。
GitLab.com 上 commit 数量统计
与此同时，项目处置的买卖峰值可以抵达每秒 30 万次买卖，GitLab.com 能抵达每秒 6 万次衔接。
3. 我们的晋级需求在消费环境停止晋级前，我们首先确定了一些需求：
PostgreSQL 11 上不能有回归。我们开发了一个自定义基准测试来运转更普遍的回归测试，目的是辨认 PostgreSQL 11 中潜在的查询功用下降。
晋级应当针对全体项目，并在维护窗口内完成。
运用 pg_upgrade 晋级，其依赖于物理层面，而非逻辑或许复制。
保留一个 9.6 版本的集群样本。并非一切节点都需求晋级，我们应保留一些 9.6 版本的节点以备回滚。
晋级应全自动化，以降低人类失误的能够性。
全部数据库晋级的维护窗口只要 30 分钟。
晋级应留有记载并将其发布。
4. 项目为使消费晋级能顺利运转，我们将项目划分为以下四个阶段：
第一阶段：在封锁环境中开发自动化
开发 ansible-playbook，并在 staging 上备份的 PostgreSQL 环境中停止测试。
https://gitlab.com/gitlab-com/gl-infra/db-migration/-/tree/master/pg-upgrade
独立环境的运用让我们可以随时中止、启动，或许恢复备份，也让我们专注开发，并得以将环境随时回滚到晋级前。
我们运用 staging 上的备份在环境中停止项目晋级。在这个进程中，我们也遇到一些诸如在迁移数据库的进程中如何监视不同顺序之类的应战。
第二阶段：在 staging 中将晋级开发与配置管理停止分段式融合
在 Chef 中集成配置管理，并运转数据库磁盘中的一个快照（可用于恢复更新前形状）。
通知用户，本次维护窗口将力争对他们任务的影响降到最低，并在没有数据损失风险的状况下停止安全晋级。
在对配置管理停止迭代和集成测试后，我们末尾在 staging 上运转端到端测试。这些测试内容是在外部地下的，所以其他共享这个环境的团队会知道 staging 在这段时间暂时不可用。
第三阶段：在 staging 上测试端到端晋级
正式运转前对环境的反省。我们有时分会在这一步发现认证的成绩，有时分也会做一些能提升测试效率的小调整。
中止 GitLab 上一切运用和流量，在 CloudFlare 和 HA-proxy 上添加维护形式，中止包括数据库、sidekiq、workhorse、WEB-API 等一切能拜访数据库的运用。
晋级集群中六个节点中的三个。与消费中部分场景的策略相似，我们异样预备了回滚方案。
为 PostgreSQL 的更新运转 ansible-playbook。首先是数据库 leader 节点，之后是一些二级节点。
晋级之后：我们在 ansible-playbook 中运转了一些自动化测试，用以检测复制数据与原数据能否相符。
接上去，启动运用顺序，让我们的 QA 团队能运转一些测试。他们在晋级后的数据库上运转了本地单元测试，我们对负面结果停止了调查。
(责任编辑：admin)