背景
1、产品的问题点
- PG 缺乏更简单的数据热插拔能力
2、问题点背后涉及的技术原理
- 当谈到迁移数据时, 往往想到的是
- 停业务, 逻辑的导出、导入
- 逻辑增量迁移
- 全量, 流复制迁移
3、这个问题将影响哪些行业以及业务场景
- SaaS场景, 租户级的迁移、rebalance、PITR备份、PITR恢复
- 企业内部, 业务级别的数据迁移、rebalance、PITR备份、PITR恢复
- 使用生产环境快速构建测试环境, 而且一个实例包括多个业务时, 采用standby克隆的话不相干的数据也要被同步
关联吐槽：
4、会导致什么问题?
- 停业务, 逻辑的导出、导入.
- 影响业务, 停业务的时间取决于数据量大小.
- 逻辑增量迁移
- 有前置依赖, 而且有一定的场景无法满足. 后面提到
- 全量, 流复制迁移
- 不适合partial(表、schema、database级)的备份、迁移.
5、业务上应该如何避免这个坑
- 为了满足这些业务场景, 当前可以使用logical replication
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 前置依赖: 表必须有PK或UK
- 不支持DDL, sequence变化
- wal_level=logical, 如果要修改的话, 需要重启实例
- 增加了配置复杂度
- 逻辑的增量同步性能不如物理的拷贝文件, 并且实时性不如物理流复制(特别是在被同步的表发生了大事务时, 需要等上游大事务结束才能同步到下游.)
7、数据库未来产品迭代如何修复这个坑
- 希望内核层面物理流复制支持partial的物理流复制、备份、恢复、迁移能力. 热插拔数据的能力. 可以对标Oracle PDB .
- 例如: PostgreSQL，每个DB有单独的REDO，DB支持热插拔。支持DB级的物理流复制。一个集群的数据库可以物理流复制的模式拷贝、增量传输到另一个集群。 另一个集群能打开这个DB进行只读操作, 能够激活这个DB进行读写操作.
- 支持transfer table、transfer schema特性, 能够支持物理级别的增量迁移、备份table、schema.
- 在存储计算分离架构中, 能支持卸载、挂载table、schema、database的数据文件的能力. 一份存储可以给a实例挂载、也可以给b实例挂载, 只要他们不同时挂载, 大幅度提高rebalance、迁移等场景的效率.
- 《PostgreSQL 部分数据库复制、wal代理、wal过滤器 插件 walbouncer》
- 《PostgreSQL 表传输功能 - pg_transport pgtransfer》