背景

1、产品的问题点

• PG 大版本升级不支持业务侧兼容性自动评估

2、问题点背后涉及的技术原理

• PG 的大版本升级方式较多: 支持pg_upgrade导出元数据的模式, 逻辑增量定义的模式, 全量导出导入的模式.
• 但是高版本和低版本之间可能存在一些不兼容的点:

• • 插件版本是否不兼容
  • SQL语法是否不兼容, 是否去掉了某些语法, 是否去掉了某些函数.

3、这个问题将影响哪些行业以及业务场景

• 通用, 大版本升级时

• • 业务想使用大版本的新功能或提升性能,
  • 业务使用的数据库版本太老, 社区已经不支持, *升级到大版本

4、会导致什么问题?

• 业务需要自己评估版本升级后业务是否兼容.

• • 通常比较麻烦, 需要去看PG的release notes, 看里面的大版本升级兼容性部分, 通常只会将与上一个版本的差异, 不会涉及到与更早的版本之间的差异.
  • 如果升级跨了很多个大版本, 需要看很多release notes, 比较复杂.

5、业务上应该如何避免这个坑

• 必须搜集所有的SQL、插件、定义等, 根据release notes的大小版本差异逐条比对是否存在不兼容的问题.

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 比较复杂, 容易出问题.

7、数据库未来产品迭代如何修复这个坑

• 希望数据库提供可评估业务侧兼容性报告的工具, 类似阿里云adam(采集元数据、应用SQL请求等, 在大版本库中回放, 或根据已有规则判定兼容性), 报告业务运行的SQL , DDL 等在升级到大版本后, 有哪些不兼容, 应该怎么改等.