概念 on Pigsty v5.0

被动故障切换

Mon, 01 Jan 0001 00:00:00 +0000

infographic list-row-simple-horizontal-arrow
data
  title 租约过期故障切换流程
  desc 当整个节点宕机，Patroni 无法主动释放租约，只能等待 TTL 过期
  items
    - label 租约过期
      desc Patroni 失联，被动等待主库租约 TTL 过期
      icon mingcute/close-circle-fill
    - label 从库检测
      desc 从库从循环中醒来后发现租约过期，开始竞选
      icon mingcute/key-2-fill
    - label 抢锁提拔
      desc 从库相互比较并抢锁，胜利者提升自己的PG
      icon mingcute/radar-fill
    - label 健康检查
      desc HAPROXY 健康检查发现新主上线，分配流量
      icon mingcute/arrow-up-circle-fill
theme light
  palette antv

RTO 时序图

tooltip: { trigger: axis, axisPointer: { type: shadow }, formatter: $fn:fmt }
legend: { top: 0, itemGap: 12, data: [租约过期, 从库检测, 抢锁提拔, 健康检查] }
grid: { left: 64, right: 24, bottom: 32, top: 40 }
xAxis: { type: value, name: 秒, nameLocation: end, max: 160, axisLine: { show: true }, axisTick: { show: true }, splitLine: { show: true, lineStyle: { type: dashed, opacity: 0.5 } }, minorTick: { show: true, splitNumber: 5 }, minorSplitLine: { show: true, lineStyle: { type: dotted, opacity: 0.2 } } }
yAxis: { type: category, axisLine: { show: true }, axisTick: { show: true }, splitLine: { show: false }, axisLabel: { fontSize: 10, fontFamily: monospace }, data: [wide-max, wide-avg, wide-min, "", safe-max, safe-avg, safe-min, "", norm-max, norm-avg, norm-min, "", fast-max, fast-avg, fast-min] }
series:
  - { name: 租约过期, type: bar, stack: main, barWidth: 20, z: 2, emphasis: { focus: series }, itemStyle: { color: "#e15759" }, data: [120, 110, 100, "-", 60, 55, 50, "-", 30, 27, 25, "-", 20, 17, 15] }
  - { name: 从库检测, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#edc949" }, data: [20, 10, 0, "-", 10, 5, 0, "-", 5, 3, 0, "-", 5, 3, 0] }
  - { name: 抢锁提拔, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#59a14f" }, data: [2, 1, 0, "-", 2, 1, 0, "-", 2, 1, 0, "-", 2, 1, 0] }
  - { name: 健康检查, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#4e79a7" }, data: [8, 6, 4, "-", 6, 5, 3, "-", 4, 3, 2, "-", 2, 2, 1] }
  - { name: RTO总计, type: bar, barGap: "-100%", barWidth: 20, z: 1, itemStyle: { color: "#888", opacity: 0 }, emphasis: { itemStyle: { opacity: 0 } }, data: [150, 127, 104, "-", 78, 66, 53, "-", 41, 34, 27, "-", 29, 23, 16] }
  - { name: RTO预算, type: bar, barGap: "-100%", barWidth: 20, z: 0, itemStyle: { color: "rgba(0,0,0,0.08)" }, emphasis: { itemStyle: { color: "rgba(0,0,0,0.12)" } }, data: [150, 150, 150, "-", 90, 90, 90, "-", 45, 45, 45, "-", 30, 30, 30] }

故障模型

项目	最好	最坏	平均	说明
租约过期	`ttl - loop`	`ttl`	`ttl - loop/2`	最好：即将刷新时宕机最坏：刚刷新完就宕机
从库检测	`0`	`loop`	`loop / 2`	最好：恰好在检测点最坏：刚错过检测点
抢锁提拔	`0`	`2`	`1`	最好：直接抢锁提升最坏：API 超时+Promote
健康检查	`(rise-1) × fastinter`	`(rise-1) × fastinter + inter`	`(rise-1) × fastinter + inter/2`	最好：检查前状态变化最坏：检查后瞬间状态变化

被动故障与主动故障的核心区别：

主动故障检测

Mon, 01 Jan 0001 00:00:00 +0000

infographic list-row-simple-horizontal-arrow
data
  title 崩溃故障切换流程
  desc 当 Patroni 健康，但 PostgreSQL 因故崩溃时的故障切换流程
  items
    - label 故障检测
      desc Patroni 在循环中检测到 PG 崩溃
      icon mingcute/close-circle-fill
    - label 重启超时
      desc Patroni 尝试重启 PG，超时后释放租约
      icon mingcute/refresh-2-fill
    - label 从库检测
      desc 从库从循环中醒来发现租约释放，开始竞选
      icon mingcute/key-2-fill
    - label 抢锁提拔
      desc 从库相互比较并抢锁，胜利者提升自己的 PG
      icon mingcute/radar-fill
    - label 健康检查
      desc HAProxy 健康检查发现新主上线，分配流量
      icon mingcute/arrow-up-circle-fill
theme light
  palette antv

RTO 时序图

tooltip: { trigger: axis, axisPointer: { type: shadow }, formatter: $fn:fmt }
legend: { top: 0, itemGap: 12, data: [故障检测, 重启超时, 从库检测, 抢锁提拔, 健康检查] }
grid: { left: 64, right: 24, bottom: 32, top: 40 }
xAxis: { type: value, name: 秒, nameLocation: end, max: 160, axisLine: { show: true }, axisTick: { show: true }, splitLine: { show: true, lineStyle: { type: dashed, opacity: 0.5 } }, minorTick: { show: true, splitNumber: 5 }, minorSplitLine: { show: true, lineStyle: { type: dotted, opacity: 0.2 } } }
yAxis: { type: category, axisLine: { show: true }, axisTick: { show: true }, splitLine: { show: false }, axisLabel: { fontSize: 10, fontFamily: monospace }, data: [wide-max, wide-avg, wide-min, "", safe-max, safe-avg, safe-min, "", norm-max, norm-avg, norm-min, "", fast-max, fast-avg, fast-min] }
series:
  - { name: 故障检测, type: bar, stack: main, barWidth: 20, z: 2, emphasis: { focus: series }, itemStyle: { color: "#b07aa1" }, data: [20, 10, 0, "-", 10, 5, 0, "-", 5, 3, 0, "-", 5, 3, 0] }
  - { name: 重启超时, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#f28e2c" }, data: [95, 95, 0, "-", 45, 45, 0, "-", 25, 25, 0, "-", 15, 15, 0] }
  - { name: 从库检测, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#edc949" }, data: [20, 10, 0, "-", 10, 5, 0, "-", 5, 3, 0, "-", 5, 3, 0] }
  - { name: 抢锁提拔, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#59a14f" }, data: [2, 1, 0, "-", 2, 1, 0, "-", 2, 1, 0, "-", 2, 1, 0] }
  - { name: 健康检查, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#4e79a7" }, data: [8, 6, 4, "-", 6, 5, 3, "-", 4, 3, 2, "-", 2, 2, 1] }
  - { name: RTO总计, type: bar, barGap: "-100%", barWidth: 20, z: 1, itemStyle: { color: "#888", opacity: 0 }, emphasis: { itemStyle: { opacity: 0 } }, data: [145, 122, 4, "-", 73, 61, 3, "-", 41, 35, 2, "-", 29, 24, 1] }
  - { name: RTO预算, type: bar, barGap: "-100%", barWidth: 20, z: 0, itemStyle: { color: "rgba(0,0,0,0.08)" }, emphasis: { itemStyle: { color: "rgba(0,0,0,0.12)" } }, data: [150, 150, 150, "-", 90, 90, 90, "-", 45, 45, 45, "-", 30, 30, 30] }

故障模型

项目	最好	最坏	平均	说明
故障检测	`0`	`loop`	`loop/2`	最好：PG 恰好在检测前崩溃最坏：PG 刚检测完就崩溃
重启超时	`0`	`start`	`start`	最好：PG 瞬间自愈最坏：等满 start 超时才释放租约
从库检测	`0`	`loop`	`loop/2`	最好：恰好在检测点最坏：刚错过检测点
抢锁提拔	`0`	`2`	`1`	最好：直接抢锁提升最坏：API 超时 + Promote
健康检查	`(rise-1) × fastinter`	`(rise-1) × fastinter + inter`	`(rise-1) × fastinter + inter/2`	最好：检查前状态变化最坏：检查后瞬间状态变化

主动故障与被动故障的核心区别：

网络分区

Mon, 01 Jan 0001 00:00:00 +0000

infographic list-row-simple-horizontal-arrow
data
  title 网络分区故障切换流程
  desc 主库与 DCS 网络分区，Patroni 主动降级防止脑裂，等待 TTL 过期后切换
  items
    - label 主库降级
      desc Patroni 重试超时后主动降级 PG
      icon mingcute/shield-fill
    - label 租约过期
      desc Leader Key TTL 过期
      icon mingcute/close-circle-fill
    - label 从库检测
      desc 从库发现租约过期，开始竞选
      icon mingcute/key-2-fill
    - label 抢锁提拔
      desc 从库抢锁并提升为新主库
      icon mingcute/radar-fill
    - label 健康检查
      desc HAProxy 检测新主上线
      icon mingcute/arrow-up-circle-fill
theme light
  palette antv

RTO 时序图

tooltip: { trigger: axis, axisPointer: { type: shadow }, formatter: $fn:fmt }
legend: { top: 0, itemGap: 12, data: [主库降级, 租约过期, 从库检测, 抢锁提拔, 健康检查] }
grid: { left: 64, right: 24, bottom: 32, top: 40 }
xAxis: { type: value, name: 秒, nameLocation: end, max: 160, axisLine: { show: true }, axisTick: { show: true }, splitLine: { show: true, lineStyle: { type: dashed, opacity: 0.5 } }, minorTick: { show: true, splitNumber: 5 }, minorSplitLine: { show: true, lineStyle: { type: dotted, opacity: 0.2 } } }
yAxis: { type: category, axisLine: { show: true }, axisTick: { show: true }, splitLine: { show: false }, axisLabel: { fontSize: 10, fontFamily: monospace }, data: [wide-max, wide-avg, wide-min, "", safe-max, safe-avg, safe-min, "", norm-max, norm-avg, norm-min, "", fast-max, fast-avg, fast-min] }
series:
  - { name: 主库降级, type: bar, stack: main, barWidth: 20, z: 2, emphasis: { focus: series }, itemStyle: { color: "#76b7b2" }, data: [50, 40, 30, "-", 30, 25, 20, "-", 15, 13, 10, "-", 10, 8, 5] }
  - { name: 租约过期, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#e15759" }, data: [70, 70, 70, "-", 30, 30, 30, "-", 15, 15, 15, "-", 10, 10, 10] }
  - { name: 从库检测, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#edc949" }, data: [20, 10, 0, "-", 10, 5, 0, "-", 5, 3, 0, "-", 5, 3, 0] }
  - { name: 抢锁提拔, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#59a14f" }, data: [2, 1, 0, "-", 2, 1, 0, "-", 2, 1, 0, "-", 2, 1, 0] }
  - { name: 健康检查, type: bar, stack: main, z: 2, emphasis: { focus: series }, itemStyle: { color: "#4e79a7" }, data: [8, 6, 4, "-", 6, 5, 3, "-", 4, 3, 2, "-", 2, 2, 1] }
  - { name: RTO总计, type: bar, barGap: "-100%", barWidth: 20, z: 1, itemStyle: { color: "#888", opacity: 0 }, emphasis: { itemStyle: { opacity: 0 } }, data: [150, 127, 104, "-", 78, 66, 53, "-", 41, 34, 27, "-", 29, 23, 16] }
  - { name: RTO预算, type: bar, barGap: "-100%", barWidth: 20, z: 0, itemStyle: { color: "rgba(0,0,0,0.08)" }, emphasis: { itemStyle: { color: "rgba(0,0,0,0.12)" } }, data: [150, 150, 150, "-", 90, 90, 90, "-", 45, 45, 45, "-", 30, 30, 30] }

故障模型

项目	最好	最坏	平均	说明
主库降级	`retry`	`loop + retry`	`loop/2 + retry`	Patroni 检测分区后重试，超时后主动降级
租约过期	`ttl - loop - retry`	`ttl - loop - retry`	`ttl - loop - retry`	降级后剩余的 TTL 时间（近似常数）
从库检测	`0`	`loop`	`loop/2`	最好：恰好在检测点最坏：刚错过检测点
抢锁提拔	`0`	`2`	`1`	最好：直接抢锁提升最坏：API 超时+Promote
健康检查	`(rise-1) × fastinter`	`(rise-1) × fastinter + inter`	`(rise-1) × fastinter + inter/2`	最好：检查前状态变化最坏：检查后瞬间状态变化

网络分区与节点宕机的核心区别：

积木式架构

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 使用 模块化架构 与 声明式接口，您可以像 搭积木一样自由按需组合模块。

Pigsty 采用 模块化设计，可自由组合，按需使用（Use one or all），以适应不同场景的需求。
Pigsty 使用 配置清单 和 配置参数 描述整套部署环境，并通过 Ansible 剧本 实现部署与调整。
Pigsty 在可以在任意节点上运行，无论是物理裸机还是虚拟机，只要运行 兼容的操作系统 即可。

模块

Pigsty 采用模块化设计，有六个主要的默认模块：PGSQL、INFRA、NODE、ETCD、REDIS 和 MINIO。

节点

Mon, 01 Jan 0001 00:00:00 +0000

节点（node） 是对硬件资源/操作系统的抽象，可以是物理机，裸金属、虚拟机、或者容器与 pods。

只要装着 Linux 操作系统（以及 systemd 守护进程），能使用 CPU/内存/磁盘/网络等标准资源，即可视作节点。

集群模型图

Mon, 01 Jan 0001 00:00:00 +0000

在 Pigsty 中最大的实体概念叫做 部署（Deployment），一套部署中的主要实体与关系（E-R 图）如下所示：

一套部署也可以理解为一个 环境（Environment）。例如，生产环境（Prod），用户测试环境（UTA），预发环境（Staging），测试环境（Testing），开发环境（Devbox），等等。每个环境中，都对应着一份 Pigsty 配置清单，描述了环境中的所有实体与属性。

声明式配置 —— 基础设施即代码（IaC）

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 遵循 IaC 与 GitOPS 的理念：使用声明式的 配置清单 描述整个环境，并通过 幂等剧本 来实现。

用户用声明的方式通过参数来描述自己期望的状态，而剧本则以幂等的方式调整目标节点以达到这个状态。这类似于 Kubernetes 的 CRD & Operator，然而 Pigsty 在裸机和虚拟机上，通过 Ansible 实现了这样的功能。

PG 高可用

Mon, 01 Jan 0001 00:00:00 +0000

概览

Pigsty 的 PostgreSQL 集群带有开箱即用的高可用方案，由 Patroni、Etcd 和 HAProxy 提供核心能力。

当您的 PostgreSQL 集群含有两个或更多实例时，您无需任何配置即拥有了硬件故障自愈的数据库高可用能力 —— 只要集群中有任意实例存活，集群就可以对外提供完整的服务，而客户端只要连接至集群中的任意节点，即可获得完整的服务，而无需关心主从拓扑变化。

RPO 利弊权衡

Mon, 01 Jan 0001 00:00:00 +0000

RPO（Recovery Point Objective，恢复点目标）定义了在主库发生故障时，允许丢失的最大数据量。

对于金融交易这类数据完整性至关重要的场景，通常要求 RPO = 0，即不允许任何数据丢失；

INFRA 架构

Mon, 01 Jan 0001 00:00:00 +0000

运行生产级别高可用 PostgreSQL 集群，通常需要一套完善的基础设施服务（底座）来支撑，例如监控告警、日志收集、时间同步、DNS 解析，本地软件仓库等。 Pigsty 提供了 INFRA 模块 来解决这个问题 —— 这是一个 可选模块，但我们强烈推荐启用它。

PGSQL 架构

Mon, 01 Jan 0001 00:00:00 +0000

PGSQL 模块在生产环境中以集群的形式组织，这些集群是由一组通过 主-备 关联的数据库实例组成的 逻辑实体。

概览

PGSQL 模块 包含下列组件，协同提供生产级 PostgreSQL 高可用集群服务：

RTO 利弊权衡

Mon, 01 Jan 0001 00:00:00 +0000

RTO（Recovery Time Objective，恢复时间目标）定义了在主库发生故障时，系统恢复写入能力所需的最长时间。

对于核心交易系统这类可用性至关重要的场景，通常要求 RTO 尽可能短，例如一分钟内。

故障切换模型

Mon, 01 Jan 0001 00:00:00 +0000

Patroni 故障按故障对象分类可以分为以下 10 类，按照检测路径不同，可以进一步归纳为五类，在本节内详细展开。

#	故障场景	描述	最终走哪条路径
1	PG 进程崩溃	crash、OOM killed	主动检测
2	PG 拒绝连接	max_connections	主动检测
3	PG 假活	进程在但无响应	主动检测 (检测超时)
4	Patroni 进程崩溃	kill -9、OOM	被动检测
5	Patroni 假活	进程在但卡住	Watchdog
6	节点宕机	断电、硬件故障	被动检测
7	节点假活	IO hang、CPU 饥饿	Watchdog
8	主库 ↔ DCS 网络中断	防火墙、交换机故障	网络分区
9	存储故障	磁盘坏、磁盘满、挂载失败	主动检测或 Watchdog
10	手动切换	Switchover/Failover	手动触发

但是在 RTO 计算上，最终所有故障都会收敛到两条路径上，本节深入探讨了这两种情况下的 RTO 上下限与均值。

时间点恢复 —— 数据库的时间机器（PITR）

Mon, 01 Jan 0001 00:00:00 +0000

当您不小心删除了数据、表、甚至整个数据库时，时间点恢复（Point-in-Time Recovery，PITR）让您可以回到过去。

—— 这个曾经只有资深 DBA 才能施展的『魔法』，在 Pigsty 的标准配置中零配置开箱即用。

时间点恢复的工作原理

Mon, 01 Jan 0001 00:00:00 +0000

如果把数据库看作一台状态机，那么 WAL（Write-Ahead Log，预写式日志）就是它的完整变更历史 —— PostgreSQL 的每一次写入，都会先以日志记录的形式落盘，然后才应用到数据文件上。这个为崩溃恢复而生的机制带来了一个副产品：只要把某个时刻的数据文件快照保存下来，再持续保留此后产生的 WAL，就可以把数据库重放到这段历史所覆盖的任意时间点。

时间点恢复的实现架构

Mon, 01 Jan 0001 00:00:00 +0000

原理一页就能讲完，工程却没有那么简单：归档不能拖垮主库的写入性能，备份放到对象存储上要加密，主从切换之后备份不能中断，多套集群共用一个仓库时要相互隔离，海量小文件会拖垮备份吞吐……

配置向导

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 提供了一个 configure 脚本作为 配置向导，它能根据当前环境，自动生成合适的 pigsty.yml 配置文件。

这是一个可选的脚本：如果您已经了解了如何配置 Pigsty，大可以直接编辑 pigsty.yml 配置文件，跳过向导。

配置参数

Mon, 01 Jan 0001 00:00:00 +0000

在 配置清单 中，您可以使用各种参数对 Pigsty 进行精细化定制。这些参数涵盖了从基础设施设置到数据库配置的各个方面。

参数列表

按照当前源码与参数参考页对账，Pigsty 的 10 个正式模块共有 373 个公开参数，用于精细控制系统的各个方面；完整列表见 参考-参数列表。原生 MySQL 8.4 试点模块的 13 个公开参数单列，不计入该合计。

时间点恢复的策略权衡

Mon, 01 Jan 0001 00:00:00 +0000

备份本质上是一份保险：保费是存储空间、网络带宽与管理成本，保额是灾难来临时能挽回多少数据、多快恢复服务。和所有保险一样，这里没有免费的午餐 —— 更长的恢复窗口意味着更多的空间，更快的恢复意味着更频繁的备份。

声明式恢复

Mon, 01 Jan 0001 00:00:00 +0000

备份系统的全部价值，都在恢复的那一刻兑现。而恢复几乎总是发生在最糟糕的时刻 —— 生产事故、深夜告警、每一分钟都在损失。传统的 PITR 手工流程在这种时刻是残酷的：停 HA、停库、写恢复配置、执行还原、盯日志、验证位点、重建元数据、拉起集群……十几个步骤环环相扣，任何一步出错都可能雪上加霜。

时间点恢复的典型场景

Mon, 01 Jan 0001 00:00:00 +0000

事故发生时，最贵的不是恢复本身，而是 决策时间。恢复的机械步骤已经被 工具编排 好了，真正需要人来回答的只有三个问题： 恢复到哪一刻？原地恢复还是克隆恢复？如何验证数据是对的？

配置模板

Mon, 01 Jan 0001 00:00:00 +0000

在 Pigsty 中，部署的蓝图细节由 配置清单 所定义，也就是 pigsty.yml 配置文件，您可以通过声明式配置进行定制。

然而，直接编写配置文件可能会让新用户望而生畏。为此，我们提供了一些开箱即用的配置模板，涵盖了常见的使用场景。

元数据库

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 允许您使用 PostgreSQL 元数据库 作为动态配置源，取代静态的 YAML 配置文件，实现更强大的配置管理能力。

概览

CMDB（Configuration Management Database，配置管理数据库）是一种将配置信息存储在数据库中进行管理的方式。

监控系统

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 监控系统由指标、日志与告警三部分组成，默认随部署开箱可用；其中日志与告警也是 审计与追溯 的重要输入。它既可以监控由 Pigsty 托管的数据库集群，也可以监控已有 PostgreSQL 集群与外部 RDS 服务。

安全合规

Mon, 01 Jan 0001 00:00:00 +0000

数据库通常是信息系统中最敏感的组件：它保存着最有价值的数据，也因此是攻击与故障后果最严重的地方。数据库安全并不是某个可以一键开启的功能，而是一系列问题的答案之和：谁能连进来？连进来能做什么？流量会不会被窃听？操作有没有留痕？数据坏了、丢了、被删了，还能不能恢复？

安全模型

Mon, 01 Jan 0001 00:00:00 +0000

在讨论具体的安全特性之前，值得先回答两个更基本的问题：信任的根在哪里，以及 防线有几道。前者决定了你应该重点保护什么，后者决定了当某一道防线失守时，你还剩下什么。

身份认证

Mon, 01 Jan 0001 00:00:00 +0000

PostgreSQL 使用 pg_hba.conf 进行 基于主机的认证（Host-Based Authentication）：谁（用户）、从哪里（来源地址）、访问什么（数据库）、需要以何种方式证明身份（认证方法）。

访问控制

Mon, 01 Jan 0001 00:00:00 +0000

认证回答“你是谁”，授权回答“你能做什么”。

权限失控很少是因为缺少机制 —— PostgreSQL 的 GRANT 与 REVOKE 足够精细。问题在于缺少一套被默认执行的约定：业务上线时直接把账号设为属主；临时排障授予超级用户后没有及时回收；新表创建后遗漏授权，最终在生产环境触发权限错误。

加密通信

Mon, 01 Jan 0001 00:00:00 +0000

TLS 可以提供三类保护：传输加密、服务端身份验证 与 客户端身份验证。这三项能力需要分别配置：启用服务端 TLS 并不等于客户端已经验证了服务端身份，也不等于服务端要求客户端证书。

数据安全

Mon, 01 Jan 0001 00:00:00 +0000

网络边界、身份认证 和 权限控制 用于降低事件发生的概率；当硬件损坏、口令泄露或误操作已经发生时，还需要依靠数据层机制控制影响并完成恢复。

数据安全要回答四个问题：数据是完整的吗？丢了能恢复吗？被拿走了会泄密吗？发生了什么能查清吗？

合规实践

Mon, 01 Jan 0001 00:00:00 +0000

合规不是一个可以购买的产品，而是一种需要持续证明的状态。它由三部分组成：

配置：安全能力是否启用 —— 这部分由 Pigsty 直接提供；
流程：权限审批、变更管理、恢复演练等制度 —— 需要组织自行建立；
证据：能证明前两者持续有效的记录 —— Pigsty 的 配置清单、运行日志和 监控系统 可以提供其中一部分。

本页从上线前的加固清单开始，给出 Pigsty 安全能力与常见合规框架的映射关系。这些映射用于方案设计和差距分析，不构成等保测评结论、SOC 2 审计意见或法律建议。

概念

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 是一个可移植、可扩展的开源 PostgreSQL 发行版，用于在本地环境中构建生产级数据库服务，方便进行声明式配置和自动化。它拥有庞大的生态系统，提供了一整套工具、脚本和最佳实践，让 PostgreSQL 真正达到企业级 RDS 的服务水准。

PostgreSQL Mongo 模式

Mon, 01 Jan 0001 00:00:00 +0000

mongo 配置模板是一个 PostgreSQL 部署模式，而不是独立的 Pigsty 模块。它由以下组件组成：

由标准 PGSQL 模块管理的 PostgreSQL 18
documentdb 扩展及其预加载库
通过 Pigsty Docker APP 工作流部署的无状态 FerretDB 代理

所有数据、高可用、备份、监控与生命周期管理仍由 PostgreSQL 负责；FerretDB 只提供 MongoDB 线协议兼容端点。

PGSQL 集群模型

Mon, 01 Jan 0001 00:00:00 +0000

PGSQL 模块在生产环境中以集群的形式组织，这些集群是由一组由 主-备 关联的数据库实例组成的 逻辑实体。

每个集群都是一个自治的业务单元，由至少一个 主库实例 组成，并通过服务向外暴露能力。

ETCD 集群模型

Mon, 01 Jan 0001 00:00:00 +0000

ETCD 模块在生产环境中以集群的形式组织，这些集群是由一组通过 Raft 共识协议关联的 ETCD 实例组成的 逻辑实体。

每个集群都是一个自治的分布式键值存储单元，由至少一个 ETCD 实例 组成，通过客户端端口向外暴露服务能力。

MINIO 集群模型

Mon, 01 Jan 0001 00:00:00 +0000

MINIO 是 Pigsty 的对象存储兼容模块名。v4.5.0 当前源码通过 minio_type: silo 部署 Silo，并以集群组织一组对象存储实例。

每个集群都是一个自治的 S3 兼容对象存储单元，由至少一个实例组成，通过 S3 API 端口对外提供服务。

REDIS 集群模型

Mon, 01 Jan 0001 00:00:00 +0000

Redis 模块在生产环境中以集群的形式组织，这些集群是由一组 Redis 实例组成的 逻辑实体，部署在一个或多个节点上。

每个集群都是一个自治的高性能缓存/存储单元，由至少一个 Redis 实例 组成，通过端口向外暴露服务能力。

INFRA 集群模型

Mon, 01 Jan 0001 00:00:00 +0000

INFRA 模块在 Pigsty 中承担着特殊的角色：它不是传统意义上的"集群"，而是由一组 基础设施节点 构成的管理中枢，为整个 Pigsty 部署提供核心服务。每个 INFRA 节点都是一个自治的基础设施服务单元，运行着 Nginx、Grafana、VictoriaMetrics 等核心组件，共同为纳管的数据库集群提供可观测性与管理能力。

3坏2应急处理

Sat, 11 Jan 2025 00:00:00 +0000

如果经典3节点高可用部署同时出现两台（多数主体）故障，系统通常无法自动完成故障切换，需要人工介入：

首先判断另外两台服务器的情况，如果短时间内可以拉起，优先选择拉起另外两台服务。否则进入 紧急止血流程

PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

PostgreSQL 是世界上最先进和最受欢迎的开源数据库。

默认安装 PostgreSQL 18，支持 PostgreSQL 14 ~ 18，并提供 575 个 PG 扩展。

快速开始

使用 pgsql 配置模板安装 Pigsty。

Supabase

Sun, 23 Jun 2024 00:00:00 +0000

Supabase —— Build in a weekend, Scale to millions

Supabase 是一个开源的 Firebase 替代，对 PostgreSQL 进行了封装，并提供了认证，开箱即用的 API，边缘函数，实时订阅，对象存储，向量嵌入能力。这是一个低代码的一站式后端平台，能让你几乎告别大部分后端开发的工作，只需要懂数据库设计与前端即可快速出活！

Citus

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 原生支持 Citus。这是一个基于原生 PostgreSQL 内核的分布式水平扩展插件。

安装

Citus 是一个 PostgreSQL 扩展插件，可以按照标准插件安装的流程，在原生 PostgreSQL 集群上加装启用。

./pgsql.yml -t pg_extension -e '{"pg_extensions":["citus"]}'

配置

要定义一个 citus 集群，您需要指定以下参数：

Babelfish

Mon, 01 Jan 0001 00:00:00 +0000

Babelfish 是一个提供 MS SQL Server 线缆协议兼容性的内核分支 + 扩展，由 AWS 开源。

概览

Pigsty 允许您使用 mssql 模式部署 Babelfish 内核，在 PostgreSQL 上提供：

SQL Server 线缆协议兼容（TDS 协议，1433 端口）
T-SQL 语法兼容
与 Pigsty 现有能力（高可用、备份、监控、IaC）统一集成

在 Pigsty v4 中，Babelfish 支持 PostgreSQL 17/18，默认模板使用 pg_version: 17，并已经纳入 Pigsty 标准交付链路。支持所有 Linux 平台。

IvorySQL

Mon, 01 Jan 0001 00:00:00 +0000

IvorySQL 是一个开源的，旨在基于 PG 提供 “Oracle 兼容性” 的 PostgreSQL 内核分支。

概览

Pigsty PGSQL 仓库直接提供 IvorySQL 5.4 软件包，兼容 PostgreSQL 18.4，并覆盖当前支持的 EL、Debian、Ubuntu 与双架构平台。在线安装使用 Pigsty 的 pgsql 仓库；商业版同时提供对应平台的离线交付方案。

PolarDB PG

Mon, 01 Jan 0001 00:00:00 +0000

概览

Pigsty 允许使用 PolarDB 创建带有 “国产化信创资质” 的 PostgreSQL 集群！

PolarDB for PostgreSQL 当前以 PostgreSQL 17 为基线，Pigsty 中的 polar 模板、默认路径与扩展说明也已经同步到 PG17。任何兼容 PostgreSQL 线缆协议的客户端工具都可以访问 PolarDB 集群。

PolarDB Oracle

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 允许使用 PolarDB 创建带有 “国产化信创资质” 的 PolarDB for Oracle 集群！

根据【安全可靠测评结果公告（2023年第1号）】，附表三、集中式数据库。PolarDB v2.0 属于自主可控，安全可靠的国产信创数据库。

PolarDB for Oracle 是基于 PolarDB for PostgreSQL 进行二次开发的 Oracle 兼容版本，两者共用同一套内核，通过 --compatibility-mode 参数进行区分。

Percona

Mon, 01 Jan 0001 00:00:00 +0000

Percona Postgres 是一个带有 pg_tde（透明数据加密）扩展的补丁 Postgres 内核。

Pigsty 从 v4.4.0 起将 Percona PostgreSQL 打包到私有前缀 /usr/pgtde-$v，v4.5.0 延续这一布局（PostgreSQL 18 对应 /usr/pgtde-18）。pgtde 包别名会同时安装内核包与 contrib 包，其中包含 pg_tde、PostGIS、pgvector、wal2json、pg_repack、 pgaudit、pg_stat_monitor 等常用组件。

openHalo

Mon, 01 Jan 0001 00:00:00 +0000

OpenHalo 是一个开源的 PostgreSQL 内核，提供 MySQL 线协议兼容性。

openHalo 基于 PostgreSQL 14.18 内核版本，提供与 MySQL 5.7.32-log / 8.0 版本的线协议兼容性。Pigsty 通过 pg_mode: mysql 与 openhalo 包别名交付。

Pigsty 在所有支持的 Linux 平台上为 OpenHalo 提供部署支持。

Greenplum

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty 支持部署 Greenplum 集群，及其衍生发行版 YMatrixDB，并提供了将现有 Greenplum 部署纳入 Pigsty 监控的能力。

概览

Greenplum / YMatrix 集群部署能力仅在专业版本/企业版本中提供，目前不对外开源。

OrioleDB

Mon, 01 Jan 0001 00:00:00 +0000

OrioleDB 是一个 PostgreSQL 存储引擎扩展，声称能够提供 4 倍 OLTP 性能，没有 xid 环绕和表膨胀问题，并具有"云原生"（数据存储在 S3）能力。

OrioleDB 当前在 Pigsty 中支持 PostgreSQL 16、17、18 三个兼容系，当前基线版本为 OrioleDB 1.8 beta16。

Cloudberry

Mon, 01 Jan 0001 00:00:00 +0000

Cloudberry 是一个源自 Greenplum 社区的开源 MPP 数据仓库内核，适合大规模并行分析场景。

概览

在 Pigsty 中，Cloudberry 沿用 gpsql 模式接入，与 Greenplum / MatrixDB 共享一套身份模型、监控逻辑与目录约定。

Neon

Mon, 01 Jan 0001 00:00:00 +0000

Neon 采用了存储与计算分离架构，提供了丝滑的自动扩缩容，Scale to Zero，以及数据库版本分叉等独家能力。

Neon 官网：https://neon.tech/

AgensGraph

Mon, 01 Jan 0001 00:00:00 +0000

AgensGraph 是基于 PostgreSQL 的属性图数据库内核，支持 openCypher 查询，并允许 Cypher 与 SQL 混合使用。

概览

Pigsty 通过 pg_mode: agens 接入 AgensGraph，并保留标准 PostgreSQL 集群的大部分运维体验。

pgEdge

Mon, 01 Jan 0001 00:00:00 +0000

pgEdge 是面向边缘场景的分布式 PostgreSQL 发行版，核心能力建立在 Spock 多主逻辑复制之上。

概览

Pigsty 通过 pg_mode: pgedge 接入 pgEdge，并用标准 PG 集群编排流程交付其核心组件：

DocumentDB

Mon, 01 Jan 0001 00:00:00 +0000

DocumentDB 是微软开源维护的 PostgreSQL 文档数据库扩展，FerretDB 是构建在其上的无状态协议转换代理。两者组合，让标准 PostgreSQL 内核对外提供 MongoDB 线协议兼容端点——使用 MongoDB 驱动的应用程序可以直接对接，请求被转换为对 PostgreSQL 的操作。

内核分支

Sun, 23 Jun 2024 00:00:00 +0000

在 Pigsty 中，您可以使用不同 “风味” 的 PostgreSQL 分支替换 “原生 PG 内核”，实现特殊的功能与效果。

Pigsty 支持多种 PostgreSQL 内核和兼容分支，让您能够在同一套运维体系中获得兼容性、多主复制、图查询、MPP 数仓、透明加密等不同能力。

服务接入

Mon, 01 Jan 0001 00:00:00 +0000

分离读写操作，正确路由流量，稳定可靠地交付 PostgreSQL 集群提供的能力。

服务是一种抽象：它是数据库集群对外提供能力的形式，并封装了底层集群的细节。

服务对于生产环境中的稳定接入至关重要，在高可用集群自动故障时方显其价值，单机用户通常不需要操心这个概念。