背景

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大版本增量升级