module: PGSQL

Citus 是一个 PostgreSQL 扩展，可以将 PostgreSQL 原地转换为一个分布式数据库，并实现在多个节点上水平扩展，以处理大量数据和大量查询。 Patroni 在 v3.0 后，提供了对 Citus 原生高可用的支持，简化了 Citus 集群的搭建，Pigsty 也对此提供了原生支持。 Citus 是什么 Patroni Citus 支持 注意：Citus 13.x 支持 PostgreSQL 18、17、16、15、14 五个大版本。Pigsty 扩展仓库提供了 Citus …

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

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

Pigsty 提供补充扩展仓库，在 PGDG 官方仓库基础上提供额外的扩展包。 YUM 仓库 适用于 EL 8/9/10 及其兼容系统（RHEL、Rocky、AlmaLinux、CentOS 等）。 添加仓库 BASH # 添加 GPG 公钥 curl -fsSL https://repo.pigsty.io/key | sudo tee /etc/pki/rpm-gpg/RPM-GPG-KEY-pigsty >/dev/null # 添加仓库配置 curl -fsSL …

Pigsty 在初始化 PostgreSQL 集群时，会默认安装和启用一些核心扩展。 默认安装的扩展 通过 pg_packages 默认安装的扩展： 扩展 说明 pg_repack 在线处理表膨胀，重要的维护工具 wal2json 逻辑解码输出 JSON 格式变更，CDC 场景常用 pgvector 向量数据类型与索引，默认随 pgsql-main 安装 pg_extensions 的默认值为空数组 []。如需安装其他扩展，可以按需声明，例如： 扩展 说明 postgis 地理空间数据库扩展 …

我当前执行安装的用户为何不能使用 pg 管理别名？ 从 Pigsty v4.0 开始，使用 pg 管理别名管理全局的 Patroni / PostgreSQL 集群的权限被收紧到了管理节点上的管理员分组（admin）。 node.yml 剧本创建的管理员（dba）默认具有此权限，而其他用户如果想要获得这个权限，需要你显式地将该用户加入到 admin 组中。 BASH sudo usermod -aG admin <username> PGSQL初始化失败：Fail to wait for …

移除扩展涉及两个层面：删除扩展对象（数据库层面）和 卸载软件包（操作系统层面）。 删除扩展对象 使用 DROP EXTENSION 从数据库中删除扩展： SQL -- 删除扩展 DROP EXTENSION pgvector; -- 如果有依赖对象，需要级联删除 DROP EXTENSION pgvector CASCADE; 警告：CASCADE 会删除所有依赖于该扩展的对象（表、函数、视图等），请谨慎使用。 查看扩展依赖 删除前建议先检查依赖关系： SQL -- 查看依赖于某扩展的对象 …

扩展更新涉及两个层面：软件包更新（操作系统层面）和 扩展对象更新（数据库层面）。 更新软件包 使用包管理器更新扩展的软件包： BASH # EL 系统 sudo yum update pgvector_18* # Debian/Ubuntu 系统 sudo apt update && sudo apt upgrade postgresql-18-pgvector 使用 Pigsty 批量更新： BASH # 更新指定集群的扩展包 ./pgsql.yml -l pg-meta -t …

安装扩展软件包后，需要在数据库中执行 CREATE EXTENSION 才能使用扩展功能。 查看可用扩展 安装扩展软件包后，可以查看可用的扩展： SQL -- 查看所有可用扩展 SELECT * FROM pg_available_extensions; -- 查看特定扩展 SELECT * FROM pg_available_extensions WHERE name = 'vector'; -- 查看已启用的扩展 SELECT * FROM pg_extension; 创建扩展 使用 …

部分扩展需要预加载动态库或配置参数后才能使用，本节介绍如何配置扩展。 预加载扩展 大多数扩展安装后可直接使用 CREATE EXTENSION 启用，但部分使用 PostgreSQL Hook 机制的扩展需要 预加载。 预加载通过 shared_preload_libraries 参数指定，修改后需 重启数据库 生效。 需要预加载的扩展 以下是常见的需要预加载的扩展： 扩展 说明 timescaledb 时序数据库扩展，必须放在最前面 citus 分布式数据库扩展，必须放在最前面 …

Pigsty 使用操作系统的包管理器（yum/apt）安装扩展软件包。 相关参数 两个参数用于指定要安装的扩展： 参数 用途 默认行为 pg_packages 全局通用软件包 确保存在（不升级） pg_extensions 集群特定扩展 安装最新版本 pg_packages 通常用于指定所有集群都需要的基础组件（PostgreSQL 内核、Patroni、pgBouncer 等）和必选扩展。 pg_extensions 用于指定特定集群需要的扩展。 YAML pg_packages: # 全局基 …

在安装扩展前，需要确保扩展软件包已下载到本地仓库或可从上游获取。 默认行为 Pigsty 默认会把基础 PostgreSQL 18 内核包下载到本地软件仓库。默认额外下载集为 repo_extra_packages_default: [ pgsql-main ]，包含 PostgreSQL 内核、客户端、过程语言，以及 pg_repack、wal2json、pgvector 等基础扩展包。 如果需要 575 个扩展目录中的其他扩展，请显式加入 repo_extra_packages；Pigsty …

Pigsty 使用 包别名 机制简化扩展的安装与管理。 包别名机制 管理扩展涉及多个层面的名称映射： 层面 示例 pgvector 示例 postgis 扩展名 vector postgis, postgis_topology, … 包别名 pgvector postgis RPM 包名 pgvector_18 postgis36_18* DEB 包名 postgresql-18-pgvector postgresql-18-postgis-3* Pigsty 提供 包别名 抽象层，让用户无需关 …

扩展是 PostgreSQL 的灵魂所在。Pigsty 收录了 575 个预编译、开箱即用的扩展插件，充分释放 PostgreSQL 的潜能。 扩展是什么 PostgreSQL 扩展（Extension）是一种模块化机制，允许在不修改核心代码的情况下增强数据库功能。 一个扩展通常包含三部分： 控制文件（.control）：必需，包含扩展元数据 SQL 脚本（.sql）：可选，定义函数、类型、操作符等数据库对象 动态库（.so）：可选，提供 C 语言实现的高性能功能 扩展可以为 …

在 Pigsty 中使用扩展需要四个步骤：下载、安装、配置、启用。 下载：将扩展软件包下载到本地仓库（默认本地仓库只保证基础内核与 pgsql-main 包集） 安装：在集群节点上安装扩展软件包 配置：部分扩展需要预加载或配置参数 启用：在数据库中执行 CREATE EXTENSION 创建扩展 声明式配置 在 Pigsty 配置清单中声明扩展，集群初始化时自动完成安装与启用： YAML pg-meta: hosts: { 10.10.10.10: { pg_seq: 1, pg_role: …

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

Pigsty 提供四种预置的 Patroni/PostgreSQL 配置模板，针对不同的使用场景进行了参数优化： 模板 CPU 核心 适用场景 特点 /docs/pgsql/template/oltp.yml 4-128C OLTP 事务处理 高并发、低延迟、高吞吐 /docs/pgsql/template/olap.yml 4-128C OLAP 分析处理 大查询、高并行、长事务 /docs/pgsql/template/crit.yml 4-128C 一致性优先业务 一致性优先、详细审计 …

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) 的安装包，开源版本用户可以自行安装配置。 BASH # EL 7 Only (Greenplum6) ./node.yml …

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 集群上加装启用。 BASH ./pgsql.yml -t pg_extension -e '{"pg_extensions":["citus"]}' 配置 要定义一个 citus 集群，您需要指定以下参数： pg_mode 必须设置为 citus，而不是默认的 pgsql 在每个 …

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

Pigsty 提供 575 个已打包扩展，覆盖时序、地理、向量、全文检索、分析、特性增强等 16 大类别，开箱即用。 在 Pigsty 中使用扩展涉及四个核心步骤：下载、安装、配置/加载 与 启用。 YAML pg-meta: hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } } vars: pg_cluster: pg-meta pg_databases: - name: meta extensions: [ postgis, …

Pigsty 提供了一系列剧本，用于集群上下线扩缩容，用户/数据库管理，监控、备份恢复或迁移已有实例。 剧本 功能 pgsql.yml 初始化 PostgreSQL 集群或添加新的从库 pgsql-rm.yml 移除 PostgreSQL 集群，或移除某个实例 pgsql-user.yml 在现有的 PostgreSQL 集群中添加新的业务用户 pgsql-db.yml 在现有的 PostgreSQL 集群中添加新的业务数据库 pgsql-monitor.yml 将远程 PostgreSQL …

您可以在 PostgreSQL 集群上绑定一个可选的 L2 VIP —— 前提条件是：集群中的所有节点都在一个二层网络中。 这个 L2 VIP 强制使用 Master - Backup 模式，Master 始终指向在数据库集群主库实例所在的节点。 这个 VIP 由 VIP-Manager 组件管理，它会从 DCS （etcd） 中直接读取由 Patroni 写入的 Leader Key，从而判断自己是否是 Master。 启用VIP 在 PostgreSQL 集群上定义 …

PGSQL 模块包含有 638 类可用监控指标。 Metric Name Type Labels Description ALERTS Unknown category, job, level, ins, severity, ip, alertname, alertstate, instance, cls N/A ALERTS_FOR_STATE Unknown category, job, level, ins, severity, ip, alertname, instance, cls …

Pigsty 为 PostgreSQL 提供了诸多开箱即用的 Grafana 监控仪表盘： Demo & Gallery。 当前源码共提供 31 个 PostgreSQL 相关面板：files/grafana/pgsql 中有 29 个 PostgreSQL / PGCAT 面板，files/grafana/app 中另有 2 个 PGLOG 面板。它们按层次分为总览、集群、实例、数据库四大类，按数据来源分为 PGSQL、PGCAT、PGLOG 三类。 总览 总览 集群 实例 数据库 …

本文介绍了 Pigsty 的监控系统架构，包括监控指标，日志，与目标管理的方式。以及如何 监控现有PG集群 与远程 RDS服务。 监控概览 Pigsty 使用现代的可观测技术栈对 PostgreSQL 进行监控： 使用 Grafana 进行指标可视化和 PostgreSQL 数据源。 使用 VictoriaMetrics 来采集 PostgreSQL / Pgbouncer / Patroni / HAProxy / Node 的指标 使用 VictoriaLogs 来记录 PostgreSQL …

参数配置与参考文档

Pigsty 内置了一个剧本 pgsql-migration.yml，基于逻辑复制来实现在线数据库迁移。 通过预生成的自动化脚本，应用停机时间可以缩减到几秒内。但请注意，逻辑复制需要 PostgreSQL 10 以上的版本才能工作。 当然如果您有充足的停机时间预算，那么总是可以使用 pg_dump | psql 的方式进行停机迁移。 定义迁移任务 想要使用 Pigsty 提供的在线迁移剧本，您需要创建一个定义文件，来描述迁移任务的细节。 请查看任务定义文件示例作为参考： …

误删数据 如果是小批量 DELETE 误操作，可以考虑使用 pg_surgery 或者 pg_dirtyread 扩展进行原地手术恢复。 SQL -- 立即关闭此表上的 Auto Vacuum 并中止 Auto Vacuum 本表的 worker 进程 ALTER TABLE public.some_table SET (autovacuum_enabled = off, toast.autovacuum_enabled = off); CREATE EXTENSION …

本文档列举了 PostgreSQL 和 Pigsty 中可能出现的故障，以及定位、处理、分析问题的 SOP。 磁盘空间写满 磁盘空间写满是最常见的故障类型。 现象 当数据库所在磁盘空间耗尽时，PostgreSQL 将无法正常工作，可能出现以下现象：数据库日志反复报错"no space left on device"（磁盘空间不足）， 新数据无法写入，甚至 PostgreSQL 可能触发 PANIC 强制关闭。 Pigsty 带有 NodeFsSpaceFull 告警规则，当文件系统可用空间不足 …

数据库管理与运维任务

Pigsty 的访问控制文档已按用途拆分： 访问控制概念：角色模型、默认权限、数据库 ACL 和实例隔离边界。 访问控制配置：pg_default_roles、pg_users、pg_default_privileges 等参数。 身份认证：HBA、SCRAM、证书认证与凭据管理。 HBA 配置：PostgreSQL 与 PgBouncer 规则语法。 用户管理：在现有集群中创建、更新和删除用户。 dbrole_offline 只提供独立的只读对象权限，不会自动限制实例范围。若要仅允许其访问离线 …

Pigsty 中基于主机的身份认证 HBA（Host-Based Authentication）详解。 认证是 访问控制 与 默认权限 的基础，PostgreSQL 支持多种 认证 方法。 这里主要介绍 HBA：Host Based Authentication，HBA 规则定义了哪些用户能够通过哪些方式从哪些地方访问哪些数据库。 客户端认证 要连接到 PostgreSQL 数据库，用户必须先经过认证（默认使用密码）。 您可以在连接字符串中提供密码（不安全）或使用 PGPASSWORD 环境变 …

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

在这里的上下文中，数据库指的是使用 SQL 命令 CREATE DATABASE 创建的，数据库集簇内的逻辑对象。 一组 PostgreSQL 服务器可以同时服务于多个 数据库 （Database）。在 Pigsty 中，你可以在集群配置中 定义 好所需的数据库。 Pigsty 会对默认模板数据库 template1 进行修改与定制，创建默认模式，安装默认扩展，配置默认权限，新创建的数据库默认会从 template1 继承这些设置。 默认情况下，所有业务数据库都会被1:1添加到 …

在这里的上下文中，用户指的是使用 SQL 命令 CREATE USER/ROLE 创建的，数据库集簇内的逻辑对象。 在 PostgreSQL 中，用户直接隶属于数据库集簇而非某个具体的数据库。因此在创建业务数据库和业务用户时，应当遵循"先用户，后数据库"的原则。 定义用户 Pigsty 通过两个配置参数定义数据库集群中的角色与用户： pg_default_roles：定义全局统一使用的角色和用户 pg_users：在数据库集群层面定义业务用户和角色 前者用于定义了整套环境中共用的角色与用户，后 …

PostgreSQL 安全由身份认证、权限控制、网络边界、加密通信、数据保护和运维流程共同构成。Pigsty 提供这些机制的配置入口，但部署方仍需根据环境完成加固、验证和持续审计。 概念与边界 主题 内容 安全与合规 默认状态、能力边界与加固路径 身份认证 HBA、SCRAM、证书认证与凭据管理 访问控制 内置角色、默认权限、数据库 ACL 与实例访问边界 加密通信 CA、TLS、服务端身份验证与证书轮换 数据安全 页校验和、复制、备份、PITR、审计与日志 合规实践 上线检查、控制映射与证据要 …

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

Pigsty 是一个“配置驱动”的 PostgreSQL 平台：所有行为都来自 ~/pigsty/conf/*.yml 清单与 PGSQL 参数 的组合。 只要写好配置，你就能在几分钟内复刻出一套包含实例、用户、数据库、访问控制、扩展与调优策略的定制集群。 配置入口 准备清单：复制 pigsty/conf/*.yml 模板或从零开始编写 Ansible Inventory，将集群分组（all.children.<cls>.hosts）与全局变量（all.vars）写入同一个文件。 定义参数：在 …

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

PGSQL 是 Pigsty 的核心模块：通过 Ansible 清单声明 PostgreSQL 集群，以 Patroni 与 etcd 提供高可用编排，以 pgBackRest 提供备份/PITR，并通过 HAProxy、VIP、DNS、PgBouncer 与完整可观测性栈提供数据库服务。 本页按 Pigsty v4.5.0 源码组织入口。具体默认值只在 参数参考 中维护，避免在模块首页复制一份会漂移的参数快照。 建模与配置 集群模型：集群、实例、身份与角色。 架构：Patroni、etcd、服 …

上手路线 顺序 要解决的问题 入口 1 Pigsty 由哪些模块组成？ 积木式架构，PGSQL 架构，PGSQL 集群模型 2 怎么先跑起来？ 快速上手，图形界面，快速上手 PostgreSQL 3 配置文件该怎么看？ 声明式配置，配置清单，配置参数 4 生产部署要准备什么？ 架构规划，资源准备，管理机制 5 怎么部署多节点集群？ 生产部署，执行剧本，PGSQL 剧本 6 日常怎么管库？ PGSQL 日常管理，集群管理，用户管理，数据库管理 7 怎么验证可靠性？ PG 高可用，Patroni 管 …

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

PostgreSQL（简称 PG）是世界上最先进、最流行的开源关系型数据库，你可以用它来存储和检索多模态数据。 本指南面向有基础 Linux 基本命令行操作经验、但对 PostgreSQL 不太熟悉的开发者，带你快速上手 Pigsty 中的 PG。 我们假设您是个人用户，使用默认单机模式进行部署。关于生产环境多节点高可用集群的使用，请参考 生产服务接入。 基本知识 默认 单机安装 模板下，您将在当前节点上创建一个名为 pg-meta 的 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 规则、角色与权限、证书与加密、备份与审计策略，全部以 参数 的形式在 配置清单 中声明，由幂等剧本渲染落地。 这种 安全即代码 …

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

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

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

原理 一页就能讲完，工程却没有那么简单： 归档不能拖垮主库的写入性能，备份放到对象存储上要加密，主从切换之后备份不能中断， 多套集群共用一个仓库时要相互隔离，海量小文件会拖垮备份吞吐…… 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 连接池 轻量级连接池中间件，复用连接、降低开销、提供额外灵活性。 …

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

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

快速上手 Pigsty 提供 575 扩展，使用扩展涉及四个步骤：下载、安装、配置、启用。 YAML pg-meta: hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } } vars: pg_cluster: pg-meta pg_extensions: [ postgis, timescaledb, pgvector ] # <--- 安装扩展软件包 pg_libs: 'timescaledb, pg_stat_statements, …

快速上手 PostgreSQL 版本升级分为两种类型：小版本升级 和 大版本升级，两者的风险和复杂度差异很大。 类型 示例 停机时间 数据兼容性 风险等级 小版本升级 17.2 → 17.3 秒级（滚动重启） 完全兼容 低 大版本升级 17 → 18 分钟级 需要升级数据目录 中 小版本大版本扩展 小版本 BASH # 滚动升级：先从库后主库 ansible <cls> -b -a 'yum upgrade -y postgresql17*' pg restart --role replica …

Pigsty 使用 crontab 来管理定时任务，用于执行例行备份，冻结老化事务，重整膨胀表索引等维护工作。 速查手册 操作 快捷命令 说明 配置定时任务 ./pgsql.yml -t pg_crontab -l <cls> 应用 pg_crontab 配置 查看定时任务 crontab -l 以 postgres 用户查看 物理备份 pg-backup [full|diff|incr] 使用 pgBackRest 执行备份 事务冻结 pg-vacuum [database...] 冻结老化事 …

概述 Pigsty 的 PGSQL 模块由多个组件构成，每个组件都以 systemd 服务的形式运行在节点上。（pgbackrest 除外） 了解这些组件及其管理方式，对于维护生产环境中的 PostgreSQL 集群非常重要。 组件 端口 服务名 说明 Patroni 8008 patroni 高可用管理器，负责 PostgreSQL 的生命周期管理 PostgreSQL 5432 postgres 占位服务，默认不使用，应急使用 Pgbouncer 6432 pgbouncer 连接池中间件， …

访问控制由角色、对象权限、数据库 ACL 与 HBA 共同决定。本节聚焦配置参数；设计与边界见 访问控制概念。 Pigsty 预置了一套精简的 ACL 模型，通过以下参数描述： pg_default_roles：系统角色与系统用户。 pg_users：业务用户与角色。 pg_default_privileges：管理员/属主新建对象时的默认权限。 pg_revoke_public、pg_default_schemas、pg_default_extensions：控制 template1 的默认 …

PostgreSQL 参数可以在多个层级进行配置，不同层级的参数设置具有不同的作用范围和优先级。 Pigsty 支持在四个层级配置 PostgreSQL 参数，从全局到局部依次为： 层级 作用范围 配置方式 存储位置 集群级 整个集群所有实例 Patroni DCS / 调优模板 etcd + postgresql.conf 实例级 单个 PostgreSQL 实例 pg_parameters / ALTER SYSTEM postgresql.auto.conf 数据库级 特定数据库的所有会话 …

概述 HBA（Host-Based Authentication）控制“谁可以从哪里、以什么方式连接到数据库”。认证模型和默认规则说明见 身份认证。 Pigsty 通过 pg_default_hba_rules 与 pg_hba_rules 让 HBA 规则也能以声明式配置形式管理。 Pigsty 在集群初始化或 HBA 刷新时渲染以下配置文件： 配置文件 路径 说明 PostgreSQL HBA /pg/data/pg_hba.conf PostgreSQL 服务器的 HBA 规则 …

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 …

在本文中，“数据库”（Database） 指的是使用 SQL 命令 CREATE DATABASE 创建的，数据库集簇内的逻辑对象。 一组 PostgreSQL 服务器可以同时服务于多个 数据库 （Database）。在 Pigsty 中，你可以在集群配置中 定义 好所需的数据库。 Pigsty 会对默认模板数据库 template1 进行修改与定制，创建默认模式，安装默认扩展，配置默认权限，新创建的数据库默认会从 template1 继承这些设置。 您也可以通过 template 参数指定其 …

概览 Pigsty 使用 Pgbouncer 作为 PostgreSQL 的连接池中间件，默认监听 6432 端口，代理访问本机 5432 端口上的 PostgreSQL 实例。 这是一个 可选组件，如果您并没有海量连接，也不需要事务池化与查询监控指标，可以关闭连接池，直连数据库，或者保留但不使用。 用户与数据库管理 Pgbouncer 中的用户和数据库由 Pigsty 自动管理，并在 创建数据库 与 创建用户 时自动应用 数据库配置 与 用户配置。 数据库管理：在 pg_databases 中 …

tiny.yml 是针对 微型实例 和资源受限环境优化的配置模板。适用于 1-3 核 CPU 的服务器，特点是最小化资源占用、保守的内存分配、禁用并行查询。 建议同时使用 node_tune = tiny 进行操作系统级别的配套调优。 适用场景 TINY 模板适用于以下场景： 开发测试：本地开发环境、CI/CD 测试 低配虚拟机：1-2 核 CPU、1-4GB 内存的云主机 边缘计算：树莓派、嵌入式设备 Demo 演示：快速体验 Pigsty 功能 个人项目：资源有限的个人博客、小型应用 资源限 …

快速上手 Pigsty 使用声明式管理方式，首先在 配置清单 中 定义 HBA 规则，然后使用 bin/pgsql-hba <cls> 刷新规则。 YAML pg-meta: hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } } vars: pg_cluster: pg-meta pg_hba_rules: # <--- 在这里定义 HBA 规则列表！ - {user: dbuser_app, db: app, addr: intra, …

在本文中，“用户”（User） 指的是使用 SQL 命令 CREATE USER/ROLE 创建的，数据库集簇内的逻辑对象。 在 PostgreSQL 中，用户直接隶属于数据库集簇而非某个具体的数据库。因此在创建业务数据库和业务用户时，应当遵循"先用户，后数据库"的原则。 Pigsty 通过两个配置参数定义数据库集群中的角色与用户： pg_default_roles：定义全局统一使用的角色和用户 pg_users：在数据库集群层面定义业务用户和角色 前者用于定义整套环境中共用的角色与用户，后者 …

概览 Pigsty 使用 Patroni 管理 PostgreSQL 集群，它可以用来修改集群配置，查看集群状态，执行主从切换，重启集群，重做从库等操作。 要使用 Patroni 进行管理，您需要有以下两种身份之一： 从 INFRA 节点 上使用 管理员用户，可以管理环境中的所有集群。 从 PGSQL节点 上使用 pg_dbsu （默认为 postgres），可以管理当前集群。 Patroni 提供了 patronictl 命令行工具用于管理，Pigsty 提供了封装的快捷命令 pg 来简化其操 …

crit.yml 面向一致性和审计要求较高的事务型业务。它强制启用数据校验和与 Patroni 严格同步模式，增加连接日志，并调整部分 WAL、超时和并行查询参数。 该模板会增加写入延迟，并可能在没有可用同步副本时阻塞写入。使用前应确认一致性目标、故障域、客户端提交设置和可用性要求。 建议同时评估 node_tune: crit，但主机调优与数据库参数可以独立选择。 使用方法 YAML pg-critical: hosts: 10.10.10.11: { pg_seq: 1, pg_role: …

快速上手 Pigsty 使用声明式管理方式，首先在 配置清单 中 定义数据库，然后使用 bin/pgsql-db <cls> <dbname> 创建或修改数据库。 YAML pg-meta: hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } } vars: pg_cluster: pg-meta pg_databases: [{ name: some_db }] # <--- 在这里定义数据库列表！ 脚本剧本示例 脚本 BASH …

PostgreSQL 在不同操作系统上的软件包命名规则存在显著差异： EL 系统（RHEL/Rocky/Alma/…）使用 pgvector_18，postgis36_18* 这样的格式 Debian/Ubuntu 系统 使用 postgresql-18-pgvector，postgresql-18-postgis-3 这样的格式 这种差异给用户带来了额外的认知负担：您需要记住不同系统的包名规则，还要处理 PostgreSQL 版本号嵌入的问题。 软件包别名 Pigsty 通过 软件包别名 …

olap.yml 是针对 在线分析处理（OLAP）负载优化的配置模板。适用于 4-128 核 CPU 的服务器，特点是支持大查询、高并行度、宽松的超时设置和激进的 Vacuum 策略。 建议同时使用 node_tune = olap 进行操作系统级别的配套调优。 适用场景 OLAP 模板适用于以下场景： 数据仓库：历史数据存储、多维分析 BI 报表：复杂报表查询、仪表盘数据源 ETL 处理：数据抽取、转换、加载 数据分析：Ad-hoc 查询、数据探索 HTAP 混合负载：分析型从库 特征负载： …

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 …

快速上手 Pigsty 使用声明式管理方式，首先在 配置清单 中 定义用户，然后使用 bin/pgsql-user <cls> <username> 创建或修改用户。 YAML pg-meta: hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } } vars: pg_cluster: pg-meta pg_users: [{ name: dbuser_app, password: 'DBUser.App', pgbouncer: true …

在 Pigsty 中选择"内核"意味着确定 PostgreSQL 大版本、模式/发行版、需要安装的包以及要加载的调优模板。 Pigsty v4.5 当前源码支持 PostgreSQL 14 - 18，默认使用 18。下方内容展示如何通过配置文件完成这些选择。 大版本与软件包 pg_version：指定 PostgreSQL 主版本（默认 18）。Pigsty 会根据版本自动映射到正确的包名前缀。 pg_packages：定义需要安装的核心包集合，支持使用 包别名（默认 pgsql-main …

oltp.yml 是 Pigsty 的默认配置模板，针对 在线事务处理（OLTP）负载进行了优化。适用于 4-128 核 CPU 的服务器，特点是高并发连接、低延迟响应、高事务吞吐量。 建议同时使用 node_tune = oltp 进行操作系统级别的配套调优。 适用场景 OLTP 模板适用于以下场景： 电商系统：订单处理、库存管理、用户交易 社交应用：用户动态、消息推送、关注关系 游戏后端：玩家数据、排行榜、游戏状态 SaaS 应用：多租户业务系统 Web 应用：常规的 CRUD 操作密集型应 …

根据需求场景选择合适的实例与集群类型，配置出满足需求的 PostgreSQL 数据库集群。 您可以定义不同类型的实例和集群，下面是 Pigsty 中常见的几种 PostgreSQL 实例/集群类型： 读写主库：定义单一实例集群。 只读从库：定义具有一个主库和一个副本的基本 HA 集群。 离线从库：定义专用于 OLAP/ETL/交互式查询的实例 同步备库：启用同步提交以确保没有数据丢失。 法定人数提交：使用多数同步提交获得更高的一致性级别。 备份集群：克隆现有集群并跟随它 延迟集群：克隆现有集群 …

速查手册 操作 快捷命令 说明 创建集群 bin/pgsql-add <cls> 创建新的 PostgreSQL 集群 扩容集群 bin/pgsql-add <cls> <ip...> 为现有集群添加从库副本 缩容集群 bin/pgsql-rm <cls> <ip...> 从集群中移除指定实例 销毁集群 bin/pgsql-rm <cls> 销毁整个 PostgreSQL 集群 刷新服务 bin/pgsql-svc <cls> [ip...] 重载集群的负载均衡配置 刷新HBA …

Pigsty 默认提供了四套场景化参数模板，可以通过 pg_conf 参数指定并使用。 tiny.yml：为小节点、虚拟机、小型演示优化（模板标注为 1-3 核） oltp.yml：为 OLTP 工作负载和延迟敏感应用优化（4C8GB+）（默认模板） olap.yml：为 OLAP 工作负载和吞吐量优化（4C8G+） crit.yml：为数据一致性和关键应用优化（4C8G+） Pigsty 会针对这四种默认场景，采取不同的参数优化策略，如下所示： 内存参数调整 Pigsty 默认会检测系统的内存 …

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 最好： …