背景
1、产品的问题点
- pg_upgrade可以通过迁移元数据来支持大版本升级, 但是不支持增量数据.
2、问题点背后涉及的技术原理
- pg_upgrade升级大版本的主要过程:
- 使用大版本创建实例
- 停库(老、新实例都要停掉) 这里影响业务
- 检查大版本和老版本之间的兼容性
- 导出元数据(结构等)
- 导入元数据到新实例
- 割接数据文件指向
3、这个问题将影响哪些行业以及业务场景
- 通用
- 对停机时间非常敏感的客户, 例如金融,医疗等.
4、会导致什么问题?
- 升级过程需要停库, 直到元数据导入完成, 建议等统计信息重新生成后开启给用户使用,
- 元数据导入耗时取决于元数据多少(一般指表、索引等个数).
- 统计信息重新生成的耗时取决于数据量的多少, 如果不等统计信息重新生成完成, 可能导致sql的执行计划不准确, 有性能问题.
5、业务上应该如何避免这个坑
- 可以使用pglogical这类逻辑增量迁移的工具来实现大版本升级
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- pglogical有前置依赖
- 必须有PK和UK
- 必须开启wal level=logical, 需要重启, 同时会产生更多的wal日志
- pglogical不支持DDL的同步, Sequence的同步等.
- pglogical的使用门槛较高, 一般用户搞不定.
7、数据库未来产品迭代如何修复这个坑
- 建议内核层支持pg_upgrade大版本增量升级
