PostgreSQL 架构

Pigsty所采用的高可用PostgreSQL数据库集群架构

高可用

主库故障RTO ≈ 30s~1min，RPO < 10MB，从库故障RTO≈0（仅故障实例连接中断）

Pigsty默认创建创建高可用PostgreSQL数据库集群。只要集群中有任意实例存活，集群就可以对外提供完整的读写服务与只读服务。Pigsty可以自动进行故障切换，业务方只读流量不受影响；读写流量的影响视具体配置与负载，通常在几秒到几十秒的范围。

默认情况下， Pigsty部署的集群采用 可用性优先 模式，主库宕机时，未及时复制至从库部分的数据可能会丢失（正常约几百KB，不超过10MB），您可以参考 同步从库 的说明，使用 一致性优先 模式，此模式下 RPO = 0 。

架构 - 图1

Pigsty的高可用使用 Patroni + HAProxy实现，前者负责故障切换，后者负责流量切换。Patroni会利用DCS服务进行心跳保活，集群主库默认会注册一个时长为15秒的租约并定期续租。当主库故障无法续租时，租约释放，触发新一轮集群选举。通常，复制延迟最小者（数据损失最小化）会被选举为新的集群领导者。集群进入新的时间线，包括旧主库在内的其他成员都会重新追随新的领导者。

Pigsty提供了多种流量接入方式，如果您使用默认的HAProxy接入，则无需担心集群故障切换对业务流量产生影响。HAProxy会自动检测集群中的实例状态，并正确分发流量。例如，5433端口上的 Primary服务，会使用HTTP GET ip:8008/primary 健康检查，从集群中所有的Patroni处获取信息，找出集群主库，并将流量分发至主库上。HAProxy本身是无状态的，均匀部署在每个节点/实例上。任意或所有HAProxy都可以作为集群的服务接入点。

组件交互

在单个数据库节点/实例上，各组件通过以下联系相互配合：

架构 - 图2

  • vip-manager通过查询Consul获取集群主库信息，将集群专用L2 VIP绑定至主库节点（默认沙箱接入方案）。
  • Haproxy是数据库流量入口，用于对外暴露服务，使用不同端口（543x）区分不同的服务。
    • Haproxy的9101端口暴露Haproxy的内部监控指标，同时提供Admin界面控制流量。
    • Haproxy 5433端口默认指向集群主库连接池6432端口
    • Haproxy 5434端口默认指向集群从库连接池6432端口
    • Haproxy 5436端口默认直接指向集群主库5432端口
    • Haproxy 5438端口默认直接指向集群离线实例5432端口
  • Pgbouncer用于池化数据库连接，缓冲故障冲击，暴露额外指标。
    • 生产服务（高频非交互，5433/5434）必须通过Pgbouncer访问。
    • 直连服务（管理与ETL，5436/5438）必须绕开Pgbouncer直连。
  • Postgres提供实际数据库服务，通过流复制构成主从数据库集群。
  • Patroni用于监管Postgres服务，负责主从选举与切换，健康检查，配置管理。
    • Patroni使用Consul达成共识，作为集群领导者选举的依据。
  • Consul Agent用于下发配置，接受服务注册，服务发现，提供DNS查询。
    • 所有使用端口的进程服务都会注册至Consul中
  • PGB Exporter，PG Exporter， Node Exporter分别用于暴露数据库，连接池，节点的监控指标
  • Promtail是日志收集组件，用于向基础设施Loki发送采集到的PG，PGB，Patroni与节点日志

最后修改 2022-05-27: init commit (1e3e284)