第25期吐槽:PG的物理Standby无法Partial导致单元化架构/SaaS使用不灵活

文中参考文档点击阅读原文打开, 同时推荐2个学习环境: 

1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》

2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》

3、PolarDB开源数据库内核、最佳实践等学习图谱:  https://www.aliyun.com/database/openpolardb/activity 

第25期吐槽:PG 不支持物理Partial Standby

1、产品的问题点

• PG 不支持物理Partial Standby. 例如主实例有10个database分别对应10个跨省子数据库, 如果采用物理standby, 不能从中心库分别选择1个同步到不同的省份本地机房实例.

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

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

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

• 集团或中心+子节点的组织架构类业务, 例如全国库(最大), 省份库(其次), 地市库(最小).

• 将单一数据库拆分成多个数据库

• 将多个数据库合并成1个大实例

4、会导致什么问题?

• 不支持parital standby, 那么就只能建立完整的从库, 可能无法满足权限诉求, 例如不同的省份应该同步不同的数据.

• 即使只需要部分数据, 但是也需要建立整个实例的从库, 需要耗费更多的存储空间.

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

• 使用逻辑复制代替物理复制, 逻辑复制可以做到表甚至tuple级别

• 使用外部插件或软件walbouncer

• 不活跃,也没有在生产验证过

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

• 逻辑复制有前置依赖, 需要PK或UK.

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

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

• 期待内核层按database或schema隔离wal，并且支持物理partial standby

• 支持单个standby能接收多上游的wal合并成大库.

• 感觉可能有点像o pdb

本期彩蛋-招商中,有需要的小伙伴可联系嵌入...

文章中的参考文档请点击阅读原文获得. 

欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.  

近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: