背景

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