SAP BTP Cloud中PostgreSQL版本升级的有意思的案例

前言

数据库升级是DBA们经常遇到的一种常规操作。在本地部署的环境中，基本上DBA们完全可以自己把握进度和相关过程。而云环境，则大都借助于自动化运行。这中间有时候不免会遇到一些问题。

案例一：表面现象的连接池连接超时

某日,  SAP BTP云环境下，发现某些应用的数据库连接出现短暂的超时现象，查看相关日志，显示如下：

DataSource Connection Timeout: {DBConnectionPoolPendingConnections=22, 
DBConnectionPoolActiveConnections=0, DBConnectionPoolIdleConnections=0, 
DBConnectionPoolMinimumIdle=2, 
StackTrace=java.base/java.lang.Thread.getStackTrace(Thread.java:1619)

.....
com.zaxxer.hikari.pool.PoolBase$MetricsTrackerDelegate.recordConnectionTimeout(PoolBase.ja
va:742) com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:689) 
com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:181) 
com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:146) 
com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100)

.....
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoord
inatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.
java:232) 
org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:83) 
org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialec
t.java:176) 
org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:420)

从这上边dump出来的连接池的统计信息来看，连接数也没有完全用完。因为实际的连接池maxSize，系统配置的大概是：40个。从理论上来讲，至少还有10几个连接可以重新分配。

从这个角度来讲，应该是新申请的连接，都申请不到。于是发生了connection timeout的问题。

从应用开发的角度来讲，反向推测，应该是数据库与应用之间的网络通讯出现“故障”导致的。可以是如何出现？为何出现？

因为报上来的这个超时，出现时间非常短，大概也就持续了不到两分钟。

再针对日志出错的时间段，找到对应的DBOps/SRE相关人员，确认了一下，那段时间好像发生了：upgrade， 是一个小版本的升级。

The following REQUIRED/URGENT maintenance on cf-*** - will take place:

Service Instance: postgres-***************************
Instance Name: xxxxxxxxxxxxxxxxxxxx
Organization: xxx
Space: xxx
Service Plan: xxxxxx

There is an upcoming maintenance for your instance during the following times:

Action: db-upgrade
CurrentApplyDate: 2024-09-29T04:00:00+00:00
AutoAppliedAfterDate: null
ForcedApplyDate: null
Description: Automatic minor version upgrade to postgres 14.12

上边就告诉我们29号4点发生了一次小版本升级，升到14.12. 对照上时间点，果然如此。

再找开发人员，核对一下自己的监控：

上边登记的是每天一次自查的版本号，也就是说，上边登记的是2024.09.30 01:00时查询的版本号，在这之前的24个小时确实有版本变动。至于这项动态版本监控，只需要把时间字段和version值把控好，在应用层就可以做到及时的相关监控。

而升级期间数据库有短暂的连接异常，也是有可能的。

案例二：大版本升级居然卡住了

另一则案例，则是发生在MUW (维护升级的时间窗口)。一般最多也就一个小时左右的时间，但通常会在半个小时里头要求顺利完成。

在某次升级的MUW里头，某一个区域（数据中心）发生了一两起PostgreSQL升级卡住的现象，就是提示一直在升级，然后就是死活不结束。当然，这个也是SRE/DBOps那边的自动处理不够完善造成的。

底层逻辑当然，一般都是直接运行pg_upgrade, 一顿骚操作。出现的问题是某些extension的检查没有做彻底，结果把pg_upgrade操作给影响到了，错误处理部分检查也不太彻底。

结果好像就是一直在那里转圈圈。只好联系那边将对应的upgrade进程停掉，把相关扩展记录下来，暂时卸载掉。再做upgrade检查，重启upgrade，最后再新版本下边重新安装加载扩展。也终于在一个MUW的不超过40分钟的时间内完成所有的upgrade。

这也从侧面反映一个问题，在云平台下，SRE/DBOps的相关自动处理，必须要经过严格的各种情况的测试，不能想当然的认为所有操作都那么平滑。像网上著名的马工所说的SRE的操作能顶替一切DBA的工作，那还是离得相当远。自动化处理，如果运行无障碍，确实能减轻DBA的不少工作量，但是一旦出了故障，该做的工作还是一个不能少，并且让人承担的压力只多不少。

小结

本地部署以及云上的数据库管理与维护，其实不是对立的，两者甚至可以相互弥补。试想一下，云环境，不就是走“规模化”运维吗？如果本地环境的数据库实例是以千计万计，那么过去小作坊式的管理与维护，肯定满足不了实际需求，自动化管理与运维必然要提上日程。