3种方式 PG大版本升级 接锅，背锅，不甩锅 以客户为中心做产品

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

随着PostgreSQL的流行，越来越多的人开始使用PostgreSQL，这些使用PG的人群发现一个问题，PostgreSQL的新功能越来越多，尤其与AI有关的部分。一部分功能是需要通过升级PostgreSQL获取的。如果PG的库不多，且业务不关键可以通过pg_upgrade的方案来升级，但如果都这么容易本篇文章就不会出现了。

这里总结PostgreSQL升级的痛点

1 升级的风险高：pg_upgrade是一个高效的升级手段，不过这样的方式也是一个高风险的运维操作。

2 停机时间不可控：数据量和表的数量都是影响升级的时间的因素

3 回滚和recovery plan的难度大，有效的回滚方案基本没有

4 升级成本大，企业无法承担，高安全升级模式下的硬件附加成本大

大白话就是我不能为了升级个数据库，然后多买一堆机器做Recovery Plan,升级成功了这堆机器我卖谁去。

这里简述PostgreSQL阿里云的产品升级PG大版本的方案，通过阿里云的PG RDS产品根据不同的企业的成本和业务需求，PG RDS 产品提供了三种方法，去应对不同的业务和企业需求，为企业运营提供保姆级的升级安全服务。

1  本地升级

2  蓝绿部署升级

3  零停机升级

---

升级方案	适用场景	原理	优点	缺点	只读时间	费用
本地升级	实例一致，短暂只读	原地 pg_upgrade	配置账单全保	无回滚	分钟级	无
蓝绿部署（割接）	保留原实例，短暂只读	新建+pg_upgrade+自动切换	可回滚，自动切换	不继承账单	分钟级	新建实例费
蓝绿部署（不割接）	演练，双跑	新建+pg_upgrade	独立验证	无	无	新建实例费
零停机升级	不接受长停机	pg_upgrade+逻辑复制	秒级切换，支持验证	无数据校验，有限制	秒级	无
DTS迁移	不接受长停机	新建+异步逻辑复制	配置全保，校验	每库单独迁移，手动切换	秒级	实例+DTS费

看到这里，有产品经理会问，搞这么多种升级方式有必要吗？ 搞一到两种就可以了。

方案产生的原因

这恰恰是阿里云RDS PG的高明之处，他们是在成本，风险可控和停机时间中，给了客户最大的可选择性。同时也从另一个面体现了阿里云的PostgreSQL的客户数量多，促使了阿里云RDS PG的产品要开发出多种的升级模式，满足大客，小客，微客的不同使用诉求。

如果客户的主机是测试库，那么完全可以选择本地升级的方式，而如果客户想在生产系统中做一个风险可控最高的等级升级，必选蓝绿升级的方式，这个方式可以给客户产生升级后的PG Clone主机进行全面的测试，而一旦验证成功，确认升级可以大面积进行，那么可以全力开足马力，此时就可以选择零停机升级的方式。

从这点看出，大版本升级产品的设计完全考虑了客户的实际需求，给客户打造了一个完整的可选择的PG升级测试方案、PG生产升级方案。我们把四种升级的方案来进行间断的总结。

本地升级 → 成本最低，但停机时间略长、回滚困难。影响业务（这也是线下的自建的PG主机的方案）

蓝绿部署 → 提供“可验证、可回滚”，停机时间可控，可测试的升级版本。

零停机升级 → 停机秒级，直接选择切换，应用程序无需改动任何链接地址。

DTS迁移 → 灵活，迁移逻辑库的首选方案。

我们不提DTS的方案，这里针对大版本升级的具体三个方案，给大家进行一个操作演示，主要集中在蓝绿升级和零停机升级这两个部分。

1  蓝绿升级大版本

我们找到正在运行的PG12版本的PG数据库，找到大版本升级点击，先进行升级前的检验，这里阿里云微客户负责，必须进行检验，检验不通过是无法进行升级操作的。在整体蓝绿操作中，会产生一个新的语句低版本库一样的 PG 高版本库，这里我们是从PG12升级到PG17，这边测试整体过程在15分钟左右。蓝绿升级模式，产生的新的PG17的数据库可以作为实际升级前的测试库使用，业务还在低版本数据库上云霄，待测试成功，可以选择合适当前企业的升级方式，进行实际生产升级。

除了对蓝绿升级模式进行了测试，这里也对零停机方式进行了测试，同样零停机也需要进行升级前的校验，如果校验失败，则不会让客户进行升级的工作，升级的前置条件是必须校验成功，这点非常贴心，将升级中遇到的问题，潜在的危险都在升级检验报告中告知客户。整体的升级过程会通过逻辑复制的方式产生新库，待整体复制完毕后，客户可以自由通过点击切换的方式，来将老库的域名带过来，配置带过来，让客户在升级过程中什么都不用考虑，只需要等待升级完成，选择切换时间即可，提供了对业务100%的最小影响。

这里针对升级中容易出现的问题我还和研发的老师进行了咨询

1   低版本的PG针对public schema的问题，到了高版本PG产生的排异现象的问题，这里升级的过程会进行处理，无需客户担心

2   低版本上的extension会带过去吗？  答复是不单带过去，还给必要的extension 进行升级

3   用户名密码会带过去吗？  回答是不会让用户操心，源库什么样子，目的库的用户密码就是什么样子。

另外小道消息，阿里云RDS PG客户正在快速扩张，他们已经私下举办了针对某海外进入国内的ERP厂商和某连锁大型商场的 PostgreSQL 数据库联合客户的批量升级活动，同时还和国内的某金融公司线下沟通，来和客户一起交流需求,开圆桌会议，将产品升级的部分做的更贴近金融客户的要求，还线下开课，将新版本的特性和客户的DBA人员进行沟通和交流。真是上面风平浪静，下面暗流滚动，客户哐哐的往里进。

写到最后，开源的产品本身拼的并不完全是技术能力，他们比拼的是更多的服务能力，是为客户的具体需求买单的能力，和能给客户接锅，背锅，不甩锅的能力。