一、PostgreSQL行业位置
（一）行业位置
在讨论PostgreSQL（下面简称为PG）在整个数据库行业的位置之前，我们先看一下阿里云数据库在全球的数据库行业里的位置。
Ø 魔力象限领导者
Gartner 2020，阿里云数据库挺进全球数据库魔力象限领导者。
Ø PG年度最佳产品奖
2020 PG亚洲大会上，阿里云数据库专属集群MyBase荣膺“PG年度最佳产品奖”。
接下来,我们看一下PG数据库在行业中的位置。
Ø 全球数据库排行
PostgreSQL连续3年获得最佳数据库，在开源数据库排名TOP 2位置，全球流行度趋势排名TOP 4。
Ø 广泛应用
PG数据库广泛运用于各行各业，包含:计算机软件、信息技术及服务、医疗及健康、金融服务、高等教育、通讯服务等领域。
（二）RDS PG VS 自建PG
在大致了解PG在行业的位置后，接下来再看看阿里云RDS PG和自建PG相比有哪些方面的优点。
如上图所示，相对于自建PG，RDS PG的优势主要体现在可靠性、安全性、智能化和丰富插件四个方面。
1.可靠性
RDS PG提供了Logical Slot Failover能力，在主备模式下，当实例发生HA切换以后，Logical Slot可以继续为用户提供数据同步，这解决了自建PG在HA切换时无法做到数据增量同步的问题。
RDS PG的Standby支持多上游结点，当HA切换以后，依然可以保持只读实例读写分离功能, 不影响只读节点的数据同步。
一键大版本升级使得我们的用户可以产品化的一键升级到更高版本的PG，享受PG更新版本的特性与稳定性。
2.安全性
安全性主要分为三个方面。
首先，RDS PG提供云盘加密功能，用户只需要提供一个Key，RDS PG就可以使用这个用户自定义的Key对数据进行落盘加密。
其次，我们发布了SSL自定义证书功能，提供客户端以及服务端的自定义证书，提供客户端和服务端防伪装,提升数据库安全性。
最后，RDS PG提供SGX全加密，这个功能是基于硬件的加密技术，使数据在全链路上进行加密。
3.智能化
阿里云RDS的整个产品系列都提供了DAS服务。帮助用户在使用数据库的过程提供诊断优化能力，DAS可以帮助用户自发现、自诊断、自优化、自决策地解决用户数据库的问题。
4.丰富插件
RDS PG的Ganos时空引擎插件提供了时空数据的存储、检索、查询以及分析能力。
第二个插件是PASE高效向量检索插件。
第三个插件是oss_fdw，实现数据冷热分离的场景,将冷数据存储在更为低价的OSS上, 在RDS PG上可以对OSS上的数据进行查询分析。
通过以上可以发现，相较自建PG，RDS PG在可靠性、安全性、智能化、插件丰富度方面优势明显。
二、PostgreSQL版本升级背景
PostgreSQL的升级功能源于用户使用中遇到的一些问题，在升级中我们也面临许多挑战。
1.遇到的问题
Ø 老版本：过时不维护
过低的数据库版本, 稳定性挑战, 比如:
1）PG 9.4，版本过老
2）低版本，供应链问题
3）社区不维护，无人兜底
Ø 高版本：新特性
用户对于高版本、新特性的强力需求,比如:
1）增量排序
2）并行索引垃圾回收
3）索引deduplicate能力
4）分区表、聚合性能提升
2.面临的挑战
Ø 弹性能力：极致弹性
PG 9.4和PG 10.0本地盘版本是跑在物理机形态上的,导致弹性能力相对较弱,比如:
1）秒级快照
2）弹性伸缩能力
3）更大存储空间支持
4）备份操作无性能损耗
Ø 平滑割接: 应用感知小
在一键大版本升级过程中,如何使得用户应用尽可能的感知小,平滑的割接是另外一个巨大的挑战, 比如:
1）保证插件兼容性
2）割接、非割接模式
3）可回滚、可验证能力
4）应用零改动、感知小
5）一键大版本升级产品化能力
总结而言，我们期望RDS PG能够产品化一键大版本升级、平滑割接、提供可验证、可回滚能力。
三、PostgreSQL版本升级解密
（一）设计原则
基于以上对产品的思考，我们在设计RDS PG的过程中主要遵循以下四大原则。
1. 验证回滚：可验证、可回滚
- 版本回滚：大版本回滚
- DNS地址：连接字符串回滚
- 可验证: 高版本可验证能力
2. 限制要少：场景全覆盖
- DDL限制
- 表结构限制
- 数据类型限制
- 版本全系覆盖
3. 一键升级：一键升级产品化
- 拒绝升级手册
- 一键产品化能力
- 插件兼容性适配
4. 平滑割接：应用不停服零宕机
- 升级过程应用不停服
- 升级过程速度快
- 连接地址平滑割接
这四大设计原则的出发点在于，我们希望将复杂留给自己，把简单留给用户，为用户带去极致的产品使用体验。
（二）方案选择
基于上方的设计原则，我们对升级方案进行选择。对于PG大版本升级，行业内主要有如下三种方案。
方案一：逻辑复制
Ø 优点：
兼容性好、平滑割接
Ø 缺点：
1）库级别的发布、订阅
2）表必须有PK / UK
3）不支持DDL、大对象
4）外键和触发器禁用
5）可能导致到WAL日志堆积
方案二：pg_upgrade
Ø 优点：
1）不拷贝数据, 仅元数据升级
2）效率高, 2TB数据,升级< 10s
Ø 缺点：
1）升级预检查
2）回滚验证策略
3）参数、插件兼容性
4）复杂度高、工作量大、挑战大
方案三：pg_dump
Ø 优点：
1）兼容性好
2）实现简单、工作量小
Ø 缺点：
1）仅适用全量迁移
2）效率低下
3）应用停服时间长
RDS PG最终选择限制少、兼容性好、效率高、平滑割接的pg_upgrade方案。
（三）升级预检查
用户升级之前需要先对实例进行升级预检查，检查流程可以让用户知道实例是否可以升级，升级会存在什么问题，然后用户再根据错误的信息做相应的修改或适配，使得升级可以顺利完成。升级预检查流程如下:
升级预检查流程图
首先，用户到前端控制台，根据源端实例的版本选择目标实例的版本，然后提交升级预检查流程，我们的后台会创建一个升级检查报告。接着初始化用户选择的高版本数据目录，然后生成高版本参数模板。
然后执行pg_upgrade--check，最终上传检查报告到控制台上，用户在RDS控制台就可以查看报告,如下是一个典型的升级预检查报告。
可以看到，报告包括非常多的检查项，是否可以升级结果一目了然,帮助用户升级前屏蔽升级风险,。
（四）正式升级
升级预检查完成且无误后，就进入了正式升级流程，流程图如下所示。
如上图所示，流程图的每个步骤都包含两个角色，分别是用户升级前的源实例和升级后的目标实例。
升级之前，用户通过DNS连接到源实例。当用户在控制台发起一个大版本升级以后，我们会在后台帮用户创建一个和源实例同版本的目标实例的master节点，并且搭建复制链路。等待复制链路搭建好了，所有的数据同步完毕以后，待用户的切换时间。时间点到了以后，我们就会对源实例做Readonly。
第4步是把源实例和目标实例进行断连，断连后把目标实例提升为主库。
第5步是进行pg_upgrade操作，做元数据的升级,所以效率非常高,然后把用户的DNS地址切到目标实例上，此时用户应用就可以进行读和写。
第6步重搭备库，利用秒级快照能力,可以快速搭建备库,最终将整个实例平滑升级到高版本。
整个升级流程有以下几个关键的地方：
Ø 应用不停服
1）不停服: 用户应用全程可读
2）平滑性: 第5步，通过连接地址交换来实现,用户应用无需修改代码
Ø 可验证可回滚
1）可验证: 非割接模式，源实例零干预
2）可回滚: 第5步之前，零代价回滚，连接地址随时可回滚
Ø 效率高
1）速度快: 第5步pg_upgrade 2T数据在10秒内可以升级完毕
2）重搭快: 秒级快照，10分钟左右重搭备库，与数据量大小无关
Ø 用户影响
第3-5 步，仅分钟级RO时间
总结：应用不停服，零宕机，仅分钟级的RO。
（五）应用不停服零宕机
升级的过程做到应用不停服零宕机，主要是通过以下四点实现。
1.克隆目标实例
目标实例采用类克隆实例方案，源端实例一直可用。
2.可验证、可回滚
非割接模式提供验证能力，连接地址切换之前，均可回滚。
3.DNS地址切换
切换用户连接DNS地址到目标实例上，避免应用改动。
4.pg_upgrade元数据升级
pg_upgrade仅元数据升级，耗时与数据量大小无关，实测2TB数据，少于10秒。
通过以上四点，最终一键平滑地完成大版本升级。
四、PostgreSQL版本升级成果
（一）成果展示
阿里云RDS PG大版本升级在覆盖面、可用性、效率、可验证可回滚能力方面取得显著成果。
（二）行业对比
阿里云RDS PG一键大版本升级在产品化、用户体验、可验证可回滚能力上引领行业。
