背景
1、产品的问题点
- PG 大版本升级不支持业务侧兼容性自动评估
2、问题点背后涉及的技术原理
- PG 的大版本升级方式较多: 支持pg_upgrade导出元数据的模式, 逻辑增量定义的模式, 全量导出导入的模式.
- 但是高版本和低版本之间可能存在一些不兼容的点:
- 插件版本是否不兼容
- SQL语法是否不兼容, 是否去掉了某些语法, 是否去掉了某些函数.
3、这个问题将影响哪些行业以及业务场景
- 通用, 大版本升级时
- 业务想使用大版本的新功能或提升性能,
- 业务使用的数据库版本太老, 社区已经不支持, 被迫升级到大版本
4、会导致什么问题?
- 业务需要自己评估版本升级后业务是否兼容.
- 通常比较麻烦, 需要去看PG的release notes, 看里面的大版本升级兼容性部分, 通常只会将与上一个版本的差异, 不会涉及到与更早的版本之间的差异.
- 如果升级跨了很多个大版本, 需要看很多release notes, 比较复杂.
5、业务上应该如何避免这个坑
- 必须搜集所有的SQL、插件、定义等, 根据release notes的大小版本差异逐条比对是否存在不兼容的问题.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 比较复杂, 容易出问题.
7、数据库未来产品迭代如何修复这个坑
- 希望数据库提供可评估业务侧兼容性报告的工具, 类似阿里云adam(采集元数据、应用SQL请求等, 在大版本库中回放, 或根据已有规则判定兼容性), 报告业务运行的SQL , DDL 等在升级到大版本后, 有哪些不兼容, 应该怎么改等.
