江苏龙网

  1. 首页 > 资讯 > 科技 > >

InfoQ|一次近乎完美的PostgreSQL版本大升级实践


作者 | Jose Finotto
译者 | 马可薇
策划 | 万佳
2020 年 5 月 ， 我们与 OnGres 合作 ， 对 GitLab 上的 Postgres 集群进行版本大更新 ， 从 9.6 版本升级到 11 版本 。 升级全部在维护窗口内运行 ， 没有丝毫差错；更新中所有涉及的内容、计划、测试 ， 以及全流程自动化 ， 全部进行拆包 ， 只为实现一次近乎完美的 PostgreSQL 升级 。
本次版本更新 ， 我们面临的最大难题在于如何利用一个规划完善的 pg_upgrade ， 方便且高效地对整体项目进行重要版本升级 。 为此 ， 我们需要制定一个回滚计划 ， 以保证 12 节点集群的 6 TB 数据一致的同时 ， 优化恢复目标时间（RTO）后的容量 ， 为 600 万用户提供每秒 300000 次的聚合交易服务 。
解决工程难题的最佳方案是按照蓝图和设计文档行事 。 在创建蓝图的过程中 ， 我们需要定义目标问题 ， 评估最合适的解决方案 ， 并考虑每个解决方案的优缺点 。
在此 ， 我们附上为这个项目准备的蓝图 。
我们为什么要升级 PostgreSQL
我们决定在 GitLab 13.0 中停止对 PostgreSQL 10.0 的支持 ， 而PostgreSQL 9.6 版本将在 2021 年 11 月 EOL（项目终止） ， 因此 ， 我们需要采取相应的行动 。
以下是 PostgreSQL9.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 选举一致性 。
我们的配置目前使用的是 Patroni HA 解决方案 ， 它会不断收集集群、leader 检测 ， 以及节点可用性的关键信息 。 该解决方案采用 Consul 的 DNS 服务等关键功能来实现 ， 进而更新 PgBouncer 端点 ， 确保读写和只读流量使用不同架构 。
InfoQ|一次近乎完美的PostgreSQL版本大升级实践
本文插图

GitLab.com 架构
因为 HA 的缘故 ， 其中两个复制体不在只读服务器列表池中 ， 而是由 Consul DNS 支持 ， 服务于 API 。 对 GitLab 架构的几次改进后 ， 我们得以将项目整体降到 7 个节点 。
此外 ， 我们的整个集群平均每周要处理大约 181000 个交易每秒 ， 如下图所示 ， 流量会在周一有明显增加 ， 并在周一至周五 / 六内保持该吞吐量 。 我们需要让维护影响到尽量少的用户 ， 因此流量数据的统计对于设置合适的维护窗口至关重要 。
InfoQ|一次近乎完美的PostgreSQL版本大升级实践
本文插图

GitLab.com 上连接数量统计
项目整体在全天中最忙碌的时刻可以到达 25000 交易每秒 。
InfoQ|一次近乎完美的PostgreSQL版本大升级实践
本文插图

GitLab.com 上 commit 数量统计
与此同时 ， 项目处理的交易峰值可以到达每秒 30 万次交易 ， GitLab.com 能到达每秒 6 万次连接 。
我们的升级需求
在生产环境进行升级前 ， 我们首先确定了一些需求：


推荐阅读


上一篇：iQOO手机|不是游戏手机却拥有职业水准，iQOO 5游戏体验分享

下一篇：行业互联网|一加科技联合创始人裴宇确认离职：工作7年后决定告别