背景
1、产品的问题点
- PG 不支持共享存储多活(类似oracle rac)架构
2、问题点背后涉及的技术原理
- PG 一个数据库实例一份存储, 无法支持多个活跃实例共用一份存储.
3、这个问题将影响哪些行业以及业务场景
- 通用
4、会导致什么问题?
- 目前PG可以使用共享存储, 但是同时只能1个打开的实例, 不支持多活.
- 无法扩展计算能力.
- 为了提高高可用, 比较流行的架构是主从复制, 或者单计算节点的共享存储.
- 主从复制HA的问题: 1、无法保障0丢失 2、无法支持逻辑复制HA(slot无法failover) 3、HA可能出现脑裂, HA可能需要重建或rewind, 比较复杂 4、HA切换会导致用户连接断开重连
- 三节点的主从架构: 1、可以保障0丢失, 但是成本高 2、无法支持逻辑复制HA(slot无法failover)
- 目前PG为了提高读能力需要创建只读实例,
- 每个只读实例都需要1份与主实例同样的存储, 只读实例多时, 存储成本巨大.
- 由于只读实例需要回放完整的WAL, 高压下延迟可能很高
为了提高写能力, 须拆库.
- 拆库方案导致无法完全兼容单节点的数据库feature, 例如 分析, JOIN, 触发器、序列 等支持可能没有那么友好.
5、业务上应该如何避免这个坑
- 基本无解
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 基本无解
7、数据库未来产品迭代如何修复这个坑
- PolarDB for PostgreSQL 已开源(类似Oracle RAC架构, 共享存储, 多计算节点多活, 目前支持一写多读) - 可用性、可靠性、易用性、扩展性、弹性优于当前PG的主从架构.
- https://github.com/alibaba/PolarDB-for-PostgreSQL
- 希望尽快跟上PG社区14版本, 同时支持Greenplum MPP功能, 列存储, 多写能力. (做到读、写同时可扩展, 同时做到HTAP.)
- 具体看开源项目的roadmap
