背景

1、产品的问题点

• PG 不支持物理Partial Standby

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

• PG 通过全量数据+wal日志增量回放可以创建近乎实时的物理从库, 但是主库和从库的数据文件必须一致, 暂时不支持创建只有部分数据的standby

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

• 集团或中心+子节点的组织架构类业务, 例如全国库(最大), 省份库(其次), 地市库(最小).
• 将单一数据库拆分成多个数据库
• 将多个数据库合并成1个大实例

4、会导致什么问题?

• 不支持parital standby, 那么就只能建立完整的从库, 可能无法满足权限诉求, 例如不同的省份应该同步不同的数据.
• 即使只需要部分数据, 但是也需要建立整个实例的从库, 需要耗费更多的存储空间.

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

• 使用逻辑复制代替物理复制, 逻辑复制可以做到表甚至tuple级别
• 使用外部插件或软件walbouncer

• • 不活跃,也没有验证过

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

• 逻辑复制有前置依赖, 需要PK或UK.
• 逻辑复制的效率低于物理流复制(由于逻辑复制需要在事务结束后才能解析WAL, 对于大事务延迟更高.)

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

• 期待内核层支持物理standby的partial, 以及单个standby能接收多上游的wal合并成大库.