分类: 概念

如果经典3节点高可用部署同时出现两台（多数主体）故障，系统通常无法自动完成故障切换，需要人工介入： 首先判断另外两台服务器的情况，如果短时间内可以拉起，优先选择拉起另外两台服务。否则进入 紧急止血流程 紧急止血流程假设您的管理节点故障，只有单台普通数据库节点存活，在这种情况下，最快的恢复操作流程为： 调整 HAProxy 配置，将流量指向主库。 关闭 Patroni，手动提升 PostgreSQL 从库为主库。 调整HAProxy配置 如果你通过其他方式绕开 HAProxy 访问集群，那么可以跳 …

在 Pigsty 中，您可以使用不同 “风味” 的 PostgreSQL 分支替换 “原生 PG 内核”，实现特殊的功能与效果。 Pigsty 支持多种 PostgreSQL 内核和兼容分支，让您能够在同一套运维体系中获得兼容性、多主复制、图查询、MPP 数仓、透明加密等不同能力。 需要注意的是，不同内核在 Pigsty 中的交付深度并不完全一致： 像 PostgreSQL、Citus、Babelfish、IvorySQL、PolarDB、AgensGraph、pgEdge 已经有较明确的模板与 …

Supabase —— Build in a weekend, Scale to millions Supabase 是一个开源的 Firebase 替代，对 PostgreSQL 进行了封装，并提供了认证，开箱即用的 API，边缘函数，实时订阅，对象存储，向量嵌入能力。 这是一个低代码的一站式后端平台，能让你几乎告别大部分后端开发的工作，只需要懂数据库设计与前端即可快速出活！ Supabase 的口号是：“花个周末写写，随便扩容至百万”。诚然，在小微规模（4c8g）内的 Supabase 极 …

分离读写操作，正确路由流量，稳定可靠地交付 PostgreSQL 集群提供的能力。 服务 是一种抽象：它是数据库集群对外提供能力的形式，并封装了底层集群的细节。 服务对于生产环境中的 稳定接入 至关重要，在 高可用 集群自动故障时方显其价值，单机用户 通常不需要操心这个概念。 单机用户 “服务” 的概念是给生产环境用的，个人用户/单机集群可以不折腾，直接拿实例名/IP 地址访问数据库。 例如，Pigsty 默认的单节点 pg-meta.meta 数据库，就可以直接用下面三个不同的用户连接上去。 …

DocumentDB 是微软开源维护的 PostgreSQL 文档数据库扩展，FerretDB 是构建在其上的无状态协议转换代理。 两者组合，让标准 PostgreSQL 内核对外提供 MongoDB 线协议兼容端点——使用 MongoDB 驱动的应用程序可以直接对接，请求被转换为对 PostgreSQL 的操作。 与其他内核分支不同，这不是一个独立的 PostgreSQL 分叉：数据层运行原生 PostgreSQL 16 - 18 内核，由标准 PGSQL 模块管理， 持久化、事务、高可用、备 …

pgEdge 是面向边缘场景的分布式 PostgreSQL 发行版，核心能力建立在 Spock 多主逻辑复制之上。 概览 Pigsty 通过 pg_mode: pgedge 接入 pgEdge，并用标准 PG 集群编排流程交付其核心组件： pgedge：PG15、PG16、PG17、PG18 兼容内核，模板默认使用 PG18 spock：多主（active-active）逻辑复制 snowflake：分布式唯一序列 lolor：大对象逻辑复制兼容层 当前 Pigsty 仓库中提供 …

AgensGraph 是基于 PostgreSQL 的属性图数据库内核，支持 openCypher 查询，并允许 Cypher 与 SQL 混合使用。 概览 Pigsty 通过 pg_mode: agens 接入 AgensGraph，并保留标准 PostgreSQL 集群的大部分运维体验。 内核包：agensgraph 模式标识：pg_mode: agens 当前模板版本：AgensGraph 2.17.0 当前版本字符串：PostgreSQL 17.10 (AgensGraph …

Neon 采用了存储与计算分离架构，提供了丝滑的自动扩缩容，Scale to Zero，以及数据库版本分叉等独家能力。 Neon 官网：https://neon.tech/ Neon 编译后的二进制产物过于庞大，目前不对开源版用户提供，目前处于试点阶段，有需求请联系 Pigsty 销售。

Cloudberry 是一个源自 Greenplum 社区的开源 MPP 数据仓库内核，适合大规模并行分析场景。 概览 在 Pigsty 中，Cloudberry 沿用 gpsql 模式接入，与 Greenplum / MatrixDB 共享一套身份模型、监控逻辑与目录约定。 内核包名：cloudberry 模式标识：pg_mode: gpsql 角色标识：gp_role: master | segment 当前仓库版本：Cloudberry 2.1.0 当前主包版本：DEB …

OrioleDB 是一个 PostgreSQL 存储引擎扩展，声称能够提供 4 倍 OLTP 性能，没有 xid 环绕和表膨胀问题，并具有"云原生"（数据存储在 S3）能力。 OrioleDB 当前在 Pigsty 中支持 PostgreSQL 16、17、18 三个兼容系，当前基线版本为 OrioleDB 1.8 beta16。 您可以使用 Pigsty 将 OrioleDB 作为 RDS 运行。pg_mode 仍使用 oriole 选择 /usr/oriole-$v 安装路径， …

Pigsty 支持部署 Greenplum 集群，及其衍生发行版 YMatrixDB，并提供了将现有 Greenplum 部署纳入 Pigsty 监控的能力。 概览 Greenplum / YMatrix 集群部署能力仅在专业版本/企业版本中提供，目前不对外开源。 安装 Pigsty 提供了 Greenplum 6 (@el7) 与 Greenplum 7 (@el8) 的安装包，开源版本用户可以自行安装配置。 # EL 7 Only (Greenplum6) ./node.yml -t …

OpenHalo 是一个开源的 PostgreSQL 内核，提供 MySQL 线协议兼容性。 openHalo 基于 PostgreSQL 14.18 内核版本，提供与 MySQL 5.7.32-log / 8.0 版本的线协议兼容性。Pigsty 通过 pg_mode: mysql 与 openhalo 包别名交付。 Pigsty 在所有支持的 Linux 平台上为 OpenHalo 提供部署支持。 RPM 构建 SPEC: …

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、 …

Pigsty 允许使用 PolarDB 创建带有 “国产化信创资质” 的 PolarDB for Oracle 集群！ 根据 【安全可靠测评结果公告（2023年第1号）】，附表三、集中式数据库。PolarDB v2.0 属于自主可控，安全可靠的国产信创数据库。 PolarDB for Oracle 是基于 PolarDB for PostgreSQL 进行二次开发的 Oracle 兼容版本，两者共用同一套内核，通过 --compatibility-mode 参数进行区分。 我们与阿里云内核团队合 …

概览 Pigsty 允许使用 PolarDB 创建带有 “国产化信创资质” 的 PostgreSQL 集群！ PolarDB for PostgreSQL 当前以 PostgreSQL 17 为基线，Pigsty 中的 polar 模板、默认路径与扩展说明也已经同步到 PG17。任何兼容 PostgreSQL 线缆协议的客户端工具都可以访问 PolarDB 集群。 Pigsty 的 PGSQL 仓库中提供了 PolarDB PG 开源版安装包，但不会在 Pigsty 安装时下载到本地软件仓库。 …

IvorySQL 是一个开源的，旨在基于 PG 提供 “Oracle 兼容性” 的 PostgreSQL 内核分支。 概览 Pigsty PGSQL 仓库直接提供 IvorySQL 5.4 软件包，兼容 PostgreSQL 18.4，并覆盖当前支持的 EL、Debian、Ubuntu 与双架构平台。 在线安装使用 Pigsty 的 pgsql 仓库；商业版同时提供对应平台的离线交付方案。 当前 Pigsty 的 ivorysql 包别名指向 IvorySQL 5，兼容 PostgreSQL …

Babelfish 是一个提供 MS SQL Server 线缆协议兼容性的内核分支 + 扩展，由 AWS 开源。 概览 Pigsty 允许您使用 mssql 模式部署 Babelfish 内核，在 PostgreSQL 上提供： SQL Server 线缆协议兼容（TDS 协议，1433 端口） T-SQL 语法兼容 与 Pigsty 现有能力（高可用、备份、监控、IaC）统一集成 在 Pigsty v4 中，Babelfish 支持 PostgreSQL 17/18，默认模板使用 …

Pigsty 原生支持 Citus。这是一个基于原生 PostgreSQL 内核的分布式水平扩展插件。 安装 Citus 是一个 PostgreSQL 扩展插件，可以按照标准插件安装的流程，在原生 PostgreSQL 集群上加装启用。 ./pgsql.yml -t pg_extension -e '{"pg_extensions":["citus"]}' 配置 要定义一个 citus 集群，您需要指定以下参数： pg_mode 必须设置为 citus，而不是默认的 pgsql 在每个分片集群上 …

PostgreSQL 是世界上最先进和最受欢迎的开源数据库。 默认安装 PostgreSQL 18，支持 PostgreSQL 14 ~ 18，并提供 575 个 PG 扩展。 快速开始 使用 pgsql 配置模板 安装 Pigsty。 ./configure -c pgsql # 使用 postgres 内核 ./deploy.yml # 部署 Pigsty 核心链路与原生 PostgreSQL 大多数 配置模板 默认使用 PostgreSQL 内核，例如： meta : 默认，带有核心扩展 …

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

Redis 模块在生产环境中以 集群 的形式组织，这些 集群 是由一组 Redis 实例 组成的 逻辑实体，部署在一个或多个 节点 上。 每个集群都是一个 自治 的高性能缓存/存储单元，由至少一个 Redis 实例 组成，通过端口向外暴露服务能力。 在 Pigsty 的 Redis 模块中有三种核心实体： 集群（Cluster）：自治的 Redis 服务单元，用作其他实体的顶级命名空间。 实例（Instance）：单个 Redis 服务器进程，在节点上的特定端口运行。 节点（Node）：运行 …

MINIO 是 Pigsty 的对象存储兼容模块名。v4.5.0 当前源码通过 minio_type: silo 部署 Silo，并以 集群 组织一组对象存储 实例。 每个集群都是一个 自治 的 S3 兼容对象存储单元，由至少一个实例组成，通过 S3 API 端口对外提供服务。 MINIO 模块中有三种核心实体： 集群（Cluster）：自治的对象存储服务单元，用作其他实体的顶级命名空间。 实例（Instance）：单个 Silo 服务器进程，在节点上运行并管理本地磁盘。 节点（Node）：运行 …

ETCD 模块在生产环境中以 集群 的形式组织，这些 集群 是由一组通过 Raft 共识协议关联的 ETCD 实例 组成的 逻辑实体。 每个集群都是一个 自治 的分布式键值存储单元，由至少一个 ETCD 实例 组成，通过客户端端口向外暴露服务能力。 在 Pigsty 的 ETCD 模块中有三种核心实体： 集群（Cluster）：自治的 ETCD 服务单元，用作其他实体的顶级命名空间。 实例（Instance）：单个 ETCD 服务器进程，在节点上运行，参与 Raft 共识。 节点（Node）：运 …

PGSQL 模块在生产环境中以 集群 的形式组织，这些 集群 是由一组由 主-备 关联的数据库 实例 组成的 逻辑实体。 每个集群都是一个 自治 的业务单元，由至少一个 主库实例 组成，并通过服务向外暴露能力。 在 Pigsty 的 PGSQL 模块中有四种核心实体： 集群（Cluster）：自治的 PostgreSQL 业务单元，用作其他实体的顶级命名空间。 服务（Service）：对外暴露能力的命名抽象，路由流量，并使用节点端口暴露服务。 实例（Instance）：由在单个节点上的运行进程和 …

mongo 配置模板是一个 PostgreSQL 部署模式，而不是独立的 Pigsty 模块。它由以下组件组成： 由标准 PGSQL 模块管理的 PostgreSQL 18 documentdb 扩展及其预加载库 通过 Pigsty Docker APP 工作流部署的无状态 FerretDB 代理 所有数据、高可用、备份、监控与生命周期管理仍由 PostgreSQL 负责；FerretDB 只提供 MongoDB 线协议兼容端点。 快速开始 模板默认部署在单节点 10.10.10.10 上 …

Pigsty 是一个可移植、可扩展的开源 PostgreSQL 发行版，用于在本地环境中构建生产级数据库服务，方便进行声明式配置和自动化。它拥有庞大的生态系统，提供了一整套工具、脚本和最佳实践，让 PostgreSQL 真正达到企业级 RDS 的服务水准。 Pigsty 名字源自 PostgreSQL In Great STYle，也可理解为 Postgres，Infras，Graphics，Service，Toolbox，it’s all Yours —— 属于您的 PostgreSQL 图形 …

合规不是一个可以购买的产品，而是一种需要持续证明的状态。它由三部分组成： 配置：安全能力是否启用 —— 这部分由 Pigsty 直接提供； 流程：权限审批、变更管理、恢复演练等制度 —— 需要组织自行建立； 证据：能证明前两者持续有效的记录 —— Pigsty 的 配置清单、运行日志和 监控系统 可以提供其中一部分。 本页从上线前的加固清单开始，给出 Pigsty 安全能力与常见合规框架的映射关系。 这些映射用于方案设计和差距分析，不构成等保测评结论、SOC 2 审计意见或法律建议。 默认凭证清 …

网络边界、身份认证 和 权限控制 用于降低事件发生的概率；当硬件损坏、口令泄露或误操作已经发生时，还需要依靠数据层机制控制影响并完成恢复。 数据安全要回答四个问题：数据是 完整 的吗？丢了能 恢复 吗？被拿走了会 泄密 吗？发生了什么能 查清 吗？ 完整性 磁盘坏块、内存位翻转、存储固件缺陷，都可能造成 静默数据损坏：数据坏了，但没有任何报错。 Pigsty 默认启用页级数据校验和（pg_checksum：true）， 集群初始化时以 data-checksums 建库，PostgreSQL 会 …

TLS 可以提供三类保护：传输加密、服务端身份验证 与 客户端身份验证。这三项能力需要分别配置：启用服务端 TLS 并不等于客户端已经验证了服务端身份，也不等于服务端要求客户端证书。 TLS 的主要运维成本不在加密算法本身，而在证书的签发、分发、信任与轮换。缺少统一管理时，内网服务往往只启用加密，却跳过证书验证，或者干脆继续使用明文连接。 Pigsty 的做法是把 PKI 也纳入声明式管理：部署时自动创建本地自签名 CA，为受管组件签发证书并分发信任，让 TLS 在部署完成后即可使用。 本地 …

认证 回答“你是谁”，授权回答“你能做什么”。 权限失控很少是因为缺少机制 —— PostgreSQL 的 GRANT 与 REVOKE 足够精细。问题在于缺少一套被默认执行的约定： 业务上线时直接把账号设为属主；临时排障授予超级用户后没有及时回收；新表创建后遗漏授权，最终在生产环境触发权限错误。 Pigsty 提供了一套开箱即用的基础访问控制模型作为起点：四层角色、默认权限与数据库隔离。 它减少了逐库手工授权，但仍需要部署方按业务边界分配角色，并定期核对实际权限。 角色体系 Pigsty 默认 …

PostgreSQL 使用 pg_hba.conf 进行 基于主机的认证（Host-Based Authentication）：谁（用户）、从哪里（来源地址）、访问什么（数据库）、需要以何种方式证明身份（认证方法）。 这套机制足够强大，但在集群环境中手工维护的成本很高：主库与从库可能需要不同规则，配置文件又分布在每个实例的数据目录中。 如果缺少统一声明和刷新流程，各实例的规则很容易发生漂移。 Pigsty 的答案与 声明式配置 一脉相承：HBA 规则是配置清单的一部分，由剧本统一渲染与下发。 …

在讨论具体的安全特性之前，值得先回答两个更基本的问题：信任的根在哪里，以及 防线有几道。 前者决定了你应该重点保护什么，后者决定了当某一道防线失守时，你还剩下什么。 信任边界 Pigsty 是一套基于 Ansible 的声明式部署系统，它的信任模型与其他控制平面系统类似：管理节点 就是控制平面，也是整个部署中最需要保护的节点。 角色 掌握的资产与权限 管理节点（Admin Node） 配置清单 pigsty.yml（通常包含系统与业务凭据）、CA 私钥、对所有节点的 SSH 管理权限 INFRA …

数据库通常是信息系统中最敏感的组件：它保存着最有价值的数据，也因此是攻击与故障后果最严重的地方。 数据库安全并不是某个可以一键开启的功能，而是一系列问题的答案之和：谁能连进来？连进来能做什么？流量会不会被窃听？操作有没有留痕？数据坏了、丢了、被删了，还能不能恢复？ Pigsty 把这些问题的答案沉淀为一套 开箱即用的安全基线，并用 声明式配置 的方式加以管理： HBA 规则、角色与权限、证书与加密、备份与审计策略，全部以 参数 的形式在 配置清单 中声明，由幂等剧本渲染落地。 这种 安全即代码 …

Pigsty 监控系统由指标、日志与告警三部分组成，默认随部署开箱可用；其中日志与告警也是 审计与追溯 的重要输入。 它既可以监控由 Pigsty 托管的数据库集群，也可以监控已有 PostgreSQL 集群与外部 RDS 服务。 监控目标 Pigsty 监控覆盖的核心对象包括： PostgreSQL 集群与实例（SQL 性能、连接、复制、事务、检查点、WAL） 基础设施组件（Grafana、VictoriaMetrics、Alertmanager、Nginx 等） 宿主机节点（CPU、内存、磁 …

Pigsty 允许您使用 PostgreSQL 元数据库 作为动态配置源，取代静态的 YAML 配置文件，实现更强大的配置管理能力。 概览 CMDB（Configuration Management Database，配置管理数据库）是一种将配置信息存储在数据库中进行管理的方式。 在 Pigsty 中，默认的配置源是一个静态 YAML 文件 pigsty.yml， 它作为 Ansible 的 配置清单 使用。 这种方式简单直接，但当基础设施规模扩大、需要复杂精细的管理与外部集成时，单一的静态文件 …

在 Pigsty 中，部署的蓝图细节由 配置清单 所定义，也就是 pigsty.yml 配置文件，您可以通过声明式配置进行定制。 然而，直接编写配置文件可能会让新用户望而生畏。为此，我们提供了一些开箱即用的配置模板，涵盖了常见的使用场景。 每一个模板都是一个预定义的 pigsty.yml 配置文件，包含了适用于特定场景的合理默认值。 您可以根据自己的需要，选择一个模板作为定制起点，然后根据需要进行修改，以满足您的具体需求。 使用模板 Pigsty 提供了 configure 脚本作为可选的配置向 …

事故发生时，最贵的不是恢复本身，而是 决策时间。 恢复的机械步骤已经被 工具编排 好了，真正需要人来回答的只有三个问题： 恢复到哪一刻？原地恢复还是克隆恢复？如何验证数据是对的？ 本文为最常见的几类事故给出决策框架 —— 最好在事故发生之前读完它。 判断框架 场景 典型问题 推荐方式 恢复目标 误删 / 误更新数据（DML） DELETE / UPDATE 忘加 WHERE 克隆恢复，导回数据 time / xid 误删表 / 库 / Schema（DDL） DROP TABLE / 错误迁移脚 …

备份系统的全部价值，都在恢复的那一刻兑现。而恢复几乎总是发生在最糟糕的时刻 —— 生产事故、深夜告警、每一分钟都在损失。传统的 PITR 手工流程在这种时刻是残酷的： 停 HA、停库、写恢复配置、执行还原、盯日志、验证位点、重建元数据、拉起集群……十几个步骤环环相扣，任何一步出错都可能雪上加霜。 Pigsty 的答案与 声明式配置 一脉相承：恢复也是声明式的。 您描述想回到的时刻，编排工具负责停库、还原、重放与重新接管。 声明恢复目标 恢复目标用 pg_pitr 参数描述，交给 …

备份本质上是一份保险：保费 是存储空间、网络带宽与管理成本，保额 是灾难来临时能挽回多少数据、多快恢复服务。 和所有保险一样，这里没有免费的午餐 —— 更长的恢复窗口意味着更多的空间，更快的恢复意味着更频繁的备份。 设计备份策略，就是回答三个问题：备在哪里？保留多久？多久备一次？ 备在哪里：故障域决定容灾等级 备份仓库的位置是第一个、也是最重要的决定，因为它直接划定了备份能扛住哪个级别的灾难。 本地仓库（pgbackrest_method: local）把备份放在主库本地磁盘上。它简单、快速、没 …

在 配置清单 中，您可以使用各种参数对 Pigsty 进行精细化定制。这些参数涵盖了从基础设施设置到数据库配置的各个方面。 参数列表 按照当前源码与参数参考页对账，Pigsty 的 10 个正式模块共有 373 个公开参数，用于精细控制系统的各个方面；完整列表见 参考-参数列表。原生 MySQL 8.4 试点模块的 13 个公开参数单列，不计入该合计。 模块 参数组 参数数 说明 PGSQL 9 124 PostgreSQL 高可用集群配置 INFRA 10 73 软件仓库与 Victoria …

Pigsty 提供了一个 configure 脚本作为 配置向导，它能根据当前环境，自动生成合适的 pigsty.yml 配置文件。 这是一个 可选 的脚本：如果您已经了解了如何配置 Pigsty，大可以直接编辑 pigsty.yml 配置文件，跳过向导。 快速开始 进入 pigsty 源码家目录中，执行 ./configure 即可自动运行配置向导。不带任何参数时，默认使用 meta 单节点配置模板： cd ~/pigsty ./configure # 交互式配置向导，自动检测环境并生成配置 …

原理 一页就能讲完，工程却没有那么简单： 归档不能拖垮主库的写入性能，备份放到对象存储上要加密，主从切换之后备份不能中断， 多套集群共用一个仓库时要相互隔离，海量小文件会拖垮备份吞吐…… Pigsty 选择 pgBackRest 作为备份引擎，并把这些工程问题的答案预置在了出厂配置中。 本文说明这套架构的组成：引擎、仓库、链路、调度，以及一个关键设计 —— 备份跟随主库。 备份引擎：pgBackRest pgBackRest 是 PostgreSQL 生态中事实上的标准备份工具，Pigsty 用 …

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

当您不小心删除了数据、表、甚至整个数据库时，时间点恢复（Point-in-Time Recovery，PITR）让您可以回到过去。 —— 这个曾经只有资深 DBA 才能施展的『魔法』，在 Pigsty 的标准配置中零配置开箱即用。 复制不是备份 高可用 可以在硬件故障时自动切换主库，让服务免于中断。但它有一个天然的盲区：复制不是备份。 流复制会以毫秒级的延迟，把主库上发生的一切忠实地同步到所有从库 —— 包括那条忘了加 WHERE 的 DELETE， 和那句敲错了目标库的 DROP …

Patroni 故障按故障对象分类可以分为以下 10 类，按照检测路径不同，可以进一步归纳为五类，在本节内详细展开。 # 故障场景 描述 最终走哪条路径 1 PG 进程崩溃 crash、OOM killed 主动检测 2 PG 拒绝连接 max_connections 主动检测 3 PG 假活 进程在但无响应 主动检测 (检测超时) 4 Patroni 进程崩溃 kill -9、OOM 被动检测 5 Patroni 假活 进程在但卡住 Watchdog 6 节点宕机 断电、硬件故障 被动检测 7 …

RTO（Recovery Time Objective，恢复时间目标）定义了在主库发生故障时，系统恢复写入能力所需的最长时间。 对于核心交易系统这类可用性至关重要的场景，通常要求 RTO 尽可能短，例如一分钟内。 然而更短的 RTO 指标是有代价的，它会增加误切风险：网络抖动可能被误判为故障，导致不必要的故障切换。 因此对于跨机房/跨地域部署的场景，通常需要放宽 RTO 要求（例如 1-2 分钟），以降低误切风险。 利弊权衡 故障切换时的不可用时长上限由 pg_rto 参数控制。Pigsty 提 …

PGSQL 模块在生产环境中以 集群 的形式组织，这些 集群 是由一组通过 主-备 关联的数据库 实例 组成的 逻辑实体。 概览 PGSQL 模块 包含下列组件，协同提供生产级 PostgreSQL 高可用集群服务： 组件 简介 描述 postgres 数据库 世界上最先进的开源关系型数据库，PGSQL 模块的核心。 patroni 高可用 托管 PostgreSQL 进程，协调故障转移、选主、配置变更。 pgbouncer 连接池 轻量级连接池中间件，复用连接、降低开销、提供额外灵活性。 …

运行生产级别高可用 PostgreSQL 集群，通常需要一套完善的基础设施服务（底座）来支撑，例如监控告警、日志收集、时间同步、DNS 解析，本地软件仓库等。 Pigsty 提供了 INFRA 模块 来解决这个问题 —— 这是一个 可选模块，但我们强烈推荐启用它。 概览 下图是 单机部署 时的架构示意图，图中右半部分即为 INFRA 模块 所包含的组件，其中包括： 组件 种类 描述 Nginx Web 服务器 Web 界面 的统一入口，本地软件仓库，内部服务的反向代理 Repo 软件仓库 APT …

RPO（Recovery Point Objective，恢复点目标）定义了在主库发生故障时，允许丢失的最大数据量。 对于金融交易这类数据完整性至关重要的场景，通常要求 RPO = 0，即不允许任何数据丢失； 然而更为严格的 RPO 指标是有代价的，它会引入更高的写入延迟，降低系统吞吐量，并且存在从库故障导致主库不可用的风险。 因此对于常规场景，通常可以接受一定量的数据丢失，以换取更高的可用性与性能。 利弊权衡 通常在异步复制场景下，从库和主库之间会存在一定的复制延迟（取决于网络和吞吐量，正常在 …

概览 Pigsty 的 PostgreSQL 集群带有开箱即用的高可用方案，由 Patroni、Etcd 和 HAProxy 提供核心能力。 当您的 PostgreSQL 集群含有两个或更多实例时，您无需任何配置即拥有了硬件故障自愈的数据库高可用能力 —— 只要集群中有任意实例存活，集群就可以对外提供完整的服务，而客户端只要连接至集群中的任意节点，即可获得完整的服务，而无需关心主从拓扑变化。 默认 norm 模式的目标 RTO 为 45 秒内；异步复制的 pg_rpo=1MiB 是 …

Pigsty 遵循 IaC 与 GitOPS 的理念：使用声明式的 配置清单 描述整个环境，并通过 幂等剧本 来实现。 用户用声明的方式通过 参数 来描述自己期望的状态，而剧本则以幂等的方式调整目标节点以达到这个状态。 这类似于 Kubernetes 的 CRD & Operator，然而 Pigsty 在裸机和虚拟机上，通过 Ansible 实现了这样的功能。 Pigsty 诞生之初是为了解决超大规模 PostgreSQL 集群的运维管理问题，背后的想法很简单 —— 我们需要有在十分钟内在就绪 …

在 Pigsty 中最大的实体概念叫做 部署（Deployment），一套部署中的主要实体与关系（E-R 图）如下所示： 一套部署也可以理解为一个 环境（Environment）。例如，生产环境（Prod），用户测试环境（UTA），预发环境（Staging），测试环境（Testing），开发环境（Devbox），等等。 每个环境中，都对应着一份 Pigsty 配置清单，描述了环境中的所有实体与属性。 通常来说，一套环境中也会带有一套共用的基础设施（INFRA），广义的基础设施还包括 ETCD（高 …

节点（node） 是对硬件资源/操作系统的抽象，可以是物理机，裸金属、虚拟机、或者容器与 pods。 只要装着 Linux 操作系统（以及 systemd 守护进程），能使用 CPU/内存/磁盘/网络 等标准资源，即可视作节点。 节点上可以安装 模块，Pigsty 中存在几种不同类型节点，主要区别就在于安装了不同的模块。 类型 说明 普通节点 被 Pigsty 管理的节点 ADMIN 节点 使用 Ansible 发出管理指令的节点 INFRA 节点 安装 INFRA 模块的基础设施节点 ETCD …

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

RTO 时序图 故障模型 项目 最好 最坏 平均 说明 主库降级 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 …

RTO 时序图 故障模型 项目 最好 最坏 平均 说明 故障检测 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 …

RTO 时序图 故障模型 项目 最好 最坏 平均 说明 租约过期 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 最好： …