跳转到主要内容

这是本节的多页打印视图。 .

返回本页常规视图.

博客

Pigsty 文章、工程设计说明与完整版本发布档案。
文章

从 VONNG 汇集的观点、教程、实践记录与项目故事。

设计

Pigsty 工程中的架构决策与实现说明。

发布

按完整 x.y.z 版本号维护的 Pigsty 发布档案。

1 - Release

Pigsty 完整 x.y.z 版本发布档案。

截至 v4.5.0 的每一个稳定数字标签都有独立的 x.y.z 页面，小版本与补丁版本也全部收录。每条记录交叉核对 Pigsty 发布文章、历史 About / 发布注记 档案以及对应的 GitHub Release 或标签，并附上精确的源码对比链接。尚未产生真实标签的规划版本继续保持草稿状态。

1.1 - Pigsty v1.5.1

Grafana 安全性修复

v1.5.1 ·

亮点

重要：修复了 PG14.0-14.3 中 CREATE INDEX|REINDEX CONCURRENTLY 可能导致索引数据损坏的问题。

Pigsty v1.5.1 升级默认 PostgreSQL 版本至 14.4 强烈建议尽快更新。

软件升级

  • postgres 升级至 to 14.4
  • haproxy 升级至 to 2.6.0
  • grafana 升级至 to 9.0.0
  • prometheus 升级至 2.36.0
  • patroni 升级至 2.1.4

问题修复

  • 修复了 pgsql-migration.yml 中的 TYPO
  • 移除了 HAProxy 配置文件中的 PID 配置项
  • 移除了默认软件包中的 i686 软件包
  • 默认启用所有 Systemd Redis Service
  • 默认启用所有 Systemd Patroni Service

API 变更

  • grafana_database 与 grafana_pgurl 被标记为过时 API，将从后续版本移除

New Apps

  • wiki.js : 使用 Postgres 搭建本地维基百科
  • FerretDB： 使用 Postgres 提供 MongoDB API

信息来源

1.2 - Pigsty v1.5.0

Docker 应用程序支持

v1.5.0 ·

亮点概述

  • 完善的 Docker 支持：在管理节点上默认启用并提供诸多开箱即用的软件模板：bytebase, pgadmin, pgweb, postgrest, minio 等。
  • 基础设施自我监控：Nginx， ETCD， Consul， Prometheus， Grafana， Loki 自我监控
  • CMDB 升级：兼容性改善，支持 Redis 集群/Greenplum 集群元数据，配置文件可视化。
  • 服务发现改进：可以使用 Consul 自动发现所有待监控对象，并纳入 Prometheus 中。
  • 更好的冷备份支持：默认定时备份任务，添加 pg_probackup 备份工具，一键创建延时从库。
  • ETCD 现在可以用作 PostgreSQL/Patroni 的 DCS 服务，作为 Consul 的备选项。
  • Redis 剧本/角色改善：现在允许对单个 Redis 实例，而非整个 Redis 节点进行初始化与移除。

详细变更列表

监控面板

  • CMDB Overview：可视化 Pigsty CMDB Inventory。
  • DCS Overview：查阅 Consul 与 ETCD 集群的监控指标。
  • Nginx Overview：查阅 Pigsty Web 访问指标与访问日志。
  • Grafana Overview：Grafana 自我监控
  • Prometheus Overview：Prometheus 自我监控
  • INFRA Dashboard 进行重制，反映基础设施整体状态

监控架构

  • 现在允许使用 Consul 进行服务发现（当所有服务注册至 Consul 时）
  • 现在所有的 Infra 组件会启用自我监控，并通过 infra_register 角色注册至 Prometheus 与 Consul 中。
  • 指标收集器 pg_exporter 更新至 v0.5.0，添加新功能，scale 与 default，允许为指标指定一个倍乘因子，以及指定默认值。
  • pg_bgwriter, pg_wal, pg_query, pg_db, pgbouncer_stat 关于时间的指标，单位由默认的毫秒或微秒统一缩放至秒。
  • pg_table 中的相关计数器指标，现在配置有默认值 0，替代原有的 NaN。
  • pg_class 指标收集器默认移除，相关指标添加至 pg_table 与 pg_index 收集器中。
  • pg_table_size 指标收集器现在默认启用，默认设置有300秒的缓存时间。

部署方案

  • 新增可选软件包 docker.tgz，带有常用应用镜像：Pgadmin, Pgweb, Postgrest, ByteBase, Kong, Minio 等。
  • 新增角色 ETCD，可以在 DCS Servers 指定的节点上自动部署 ETCD 服务，并自动纳入监控。
  • 允许通过 pg_dcs_type 指定 PG 高可用使用的 DCS 服务，Consul（默认），ETCD（备选）
  • 允许通过 node_crontab 参数，为节点配置定时任务，例如数据库备份、VACUUM，统计收集等。
  • 新增了 pg_checksum 选项，启用时，数据库集群将启用数据校验和（此前只有 crit 模板默认启用）
  • 新增了 pg_delay 选项，当实例为 Standby Cluster Leader 时，此参数可以用于配置一个 延迟从库
  • 新增了软件包 pg_probackup，默认角色 replicator 现在默认赋予了备份相关函数所需的权限。
  • Redis 部署现在拆分为两个部分：Redis 节点与 Redis 实例，通过 redis_port 参数可以精确控制一个具体实例。
  • Loki 与 Promtail 现在使用 frpm 制作的 RPM 软件包进行安装。
  • DCS3 配置模板现在使用一个3节点的 pg-meta 集群，与一个单节点的延迟从库。

软件升级

  • 升级 PostgreSQL 至 14.3
  • 升级 Redis 至 6.2.7
  • 升级 PG Exporter 至 0.5.0
  • 升级 Consul 至 1.12.0
  • 升级 vip-manager 至 v1.0.2
  • 升级 Grafana 至 v8.5.2
  • 升级 Loki & Promtail 至 v2.5.0，使用 frpm 打包。

问题修复

  • 修复了 Loki 与 Promtail 默认配置文件名的问题
  • 修复了 Loki 与 Promtail 环境变量无法正确展开的问题
  • 对英文文档进行了一次完整的翻译与修缮，文档依赖的 JS 资源现在直接从本地获取，无需互联网访问。

API 变化

新参数

  • node_data_dir：主要的数据挂载路径，如果不存在会被创建。
  • node_crontab_overwrite：覆盖 /etc/crontab 而非追加内容。
  • node_crontab：要被追加或覆盖的 node crontab 内容。
  • nameserver_enabled：在这个基础设施节节点上启用 nameserver 吗？
  • prometheus_enabled：在这个基础设施节节点上启用 prometheus 吗？
  • grafana_enabled：在这个基础设施节节点上启用 grafana 吗？
  • loki_enabled：在这个基础设施节节点上启用 loki 吗？
  • docker_enable：在这个基础设施节点上启用 docker 吗？
  • consul_enable：启用 consul 服务器/代理吗？
  • etcd_enable：启用 etcd 服务器/客户端吗？
  • pg_checksum：启用 pg 集群数据校验和吗？
  • pg_delay：备份集群主库复制重放时的应用延迟。

参数重制

现在 *_clean 是布尔类型的参数，用于在初始化期间清除现有实例。

*_safeguard 也是布尔类型的参数，用于在执行任何剧本时，避免清除正在运行的实例。

  • pg_exists_action -> pg_clean
  • pg_disable_purge -> pg_safeguard
  • dcs_exists_action -> dcs_clean
  • dcs_disable_purge -> dcs_safeguard

参数重命名

  • node_ntp_config -> node_ntp_enabled
  • node_admin_setup -> node_admin_enabled
  • node_admin_pks -> node_admin_pk_list
  • node_dns_hosts -> node_etc_hosts_default
  • node_dns_hosts_extra -> node_etc_hosts
  • node_dns_server -> node_dns_method
  • node_local_repo_url -> node_repo_local_urls
  • node_packages -> node_packages_default
  • node_extra_packages -> node_packages
  • node_packages_meta -> node_packages_meta
  • node_meta_pip_install -> node_packages_meta_pip
  • node_sysctl_params -> node_tune_params
  • app_list -> nginx_indexes
  • grafana_plugin -> grafana_plugin_method
  • grafana_cache -> grafana_plugin_cache
  • grafana_plugins -> grafana_plugin_list
  • grafana_git_plugin_git -> grafana_plugin_git
  • haproxy_admin_auth_enabled -> haproxy_auth_enabled
  • pg_shared_libraries -> pg_libs
  • dcs_type -> pg_dcs_type

信息来源

1.3 - Pigsty v1.4.1

错误修复 & 英文文档完整翻译

v1.4.1 ·

日常错误修复 / Docker 支持 / 英文文档

现在，默认在元节点上启用 docker。您可以使用它启动海量的各类软件

现在提供英文文档。

Bug 修复

信息来源

1.4 - Pigsty v1.4.0

MatrixDB 支持，分离 INFRA/NODES/PGSQL/REDIS 模块

v1.4.0 ·

架构

  • 将系统解耦为4大类别：INFRA、NODES、PGSQL、REDIS，这使得 pigsty 更加清晰、更易于扩展。
  • 单节点部署 = INFRA + NODES + PGSQL
  • 部署 pgsql 集群 = NODES + PGSQL
  • 部署 redis 集群 = NODES + REDIS
  • 部署其他数据库 = NODES + xxx（例如 MONGO、KAFKA…待定）

可访问性

  • 为中国大陆提供 CDN。
  • 使用 bash -c "$(curl -fsSL http://get.pigsty.cc/latest)" 获取最新源代码。
  • 使用新的 download 脚本下载并提取包。

监控增强

  • 将监控系统分为5大类别：INFRA、NODES、REDIS、PGSQL、APP
  • 默认启用日志记录
    • 现在默认启用 loki 和 promtail，带有预构建的 loki-rpm。
  • 模型和标签
    • 为所有仪表板添加了一个隐藏的 ds prometheus 数据源变量，因此您只需选择一个新的数据源而不是修改 Grafana 数据源和仪表板。
    • 为所有指标添加了一个 ip 标签，并将其用作数据库指标和节点指标之间的连接键。
  • INFRA 监控
    • Infra 主仪表板：INFRA 概览
    • 添加日志仪表板：日志实例
    • PGLOG 分析和 PGLOG 会话现在被视为一个示例 Pigsty APP。
  • NODES 监控应用
    • 如果您完全不关心数据库，现在可以单独使用 Pigsty 作为主机监控软件！
    • 包括4个核心仪表板：节点概览 & 节点集群 & 节点实例 & 节点警报
    • 为节点引入新的身份变量：node_cluster 和 nodename
    • 变量 pg_hostname 现在意味着将主机名设置为与 postgres 实例名相同，以保持向后兼容性
    • 变量 nodename_overwrite 控制是否用 nodename 覆盖节点的主机名
    • 变量 nodename_exchange 将 nodename 写入彼此的 /etc/hosts
    • 所有节点指标引用都经过修订，通过 ip 连接
    • 节点监控目标在 /etc/prometheus/targets/nodes 下单独管理
  • PGSQL 监控增强
    • 完全新的 PGSQL 集群，简化并专注于集群中的重要内容。
    • 新仪表板 PGSQL 数据库是集群级对象监控。例如整个集群而不是单个实例的表和查询。
    • PGSQL 警报仪表板现在只关注 pgsql 警报。
    • PGSQL Shard 已添加到 PGSQL 中。
  • Redis 监控增强
    • 为所有 redis 仪表板添加节点监控。

MatrixDB 支持

  • 通过 pigsty-matrix.yml playbook 可以部署 MatrixDB（Greenplum 7）
  • MatrixDB 监控仪表板：PGSQL MatrixDB
  • 添加示例配置：pigsty-mxdb.yml

监控增强

  • 将监控系统分为5大类别：INFRA、NODES、REDIS、PGSQL、APP
  • 默认启用日志记录
    • 现在默认启用 loki 和 promtail，带有预构建的 loki-rpm。
  • 模型和标签
    • 为所有仪表板添加了一个隐藏的 ds prometheus 数据源变量，因此您只需选择一个新的数据源而不是修改 Grafana 数据源和仪表板。
    • 为所有指标添加了一个 ip 标签，并将其用作数据库指标和节点指标之间的连接键。
  • INFRA 监控
    • Infra 主仪表板：INFRA 概览
    • 添加日志仪表板：日志实例
    • PGLOG 分析和 PGLOG 会话现在被视为一个示例 Pigsty APP。
  • NODES 监控应用
    • 如果您完全不关心数据库，现在可以单独使用 Pigsty 作为主机监控软件！
    • 包括4个核心仪表板：节点概览 & 节点集群 & 节点实例 & 节点警报
    • 为节点引入新的身份变量：node_cluster 和 nodename
    • 变量 pg_hostname 现在意味着将主机名设置为与 postgres 实例名相同，以保持向后兼容性
    • 变量 nodename_overwrite 控制是否用 nodename 覆盖节点的主机名
    • 变量 nodename_exchange 将 nodename 写入彼此的 /etc/hosts
    • 所有节点指标引用都经过修订，通过 ip 连接
    • 节点监控目标在 /etc/prometheus/targets/nodes 下单独管理
  • PGSQL 监控增强
    • 完全新的 PGSQL 集群，简化并专注于集群中的重要内容。
    • 新仪表板 PGSQL 数据库是集群级对象监控。例如整个集群而不是单个实例的表和查询。
    • PGSQL 警报仪表板现在只关注 pgsql 警报。
    • PGSQL Shard 已添加到 PGSQL 中。
  • Redis 监控增强
    • 为所有 redis 仪表板添加节点监控。

MatrixDB 支持

  • 通过 pigsty-matrix.yml playbook 可以部署 MatrixDB（Greenplum 7）
  • MatrixDB 监控仪表板：PGSQL MatrixDB
  • 添加示例配置：pigsty-mxdb.yml

置备改进

现在 pigsty 的工作流如下：

 infra.yml ---> 在单一的元节点上安装 pigsty
      |          然后将更多节点加入 pigsty 的管理下
      |
 nodes.yml ---> 为 pigsty 准备节点（节点设置、dcs、node_exporter、promtail）
      |          然后选择一个 playbook 在这些节点上部署数据库集群
      |
      ^--> pgsql.yml   在已准备好的节点上安装 postgres
      ^--> redis.yml   在已准备好的节点上安装 redis

infra-demo.yml = 
           infra.yml -l meta     +
           nodes.yml -l pg-test  +
           pgsql.yml -l pg-test +
           infra-loki.yml + infra-jupyter.yml + infra-pgweb.yml
  • nodes.yml：用于设置和准备 pigsty 的节点，
  • 在节点上设置 node、node_exporter、consul agent
  • node-remove.yml 用于节点注销
  • pgsql.yml：现在只在已准备好的节点上工作
  • pgsql-remove 现在只负责 postgres 本身（dcs 和节点监控由 node.yml 负责）
  • 添加一系列新选项以在 greenplum/matrixdb 中重用 postgres 角色
  • redis.yml：现在在已准备好的节点上工作
  • 而 redis-remove.yml 现在从节点上移除 redis。
  • pgsql-matrix.yml 现在在已准备好的节点上安装 matrixdb（Greenplum 7）。

软件升级

  • PostgreSQL 14.2
  • PostGIS 3.2
  • TimescaleDB 2.6
  • Patroni 2.1.3 (Prometheus 指标 + 故障转移插槽)
  • HAProxy 2.5.5 (修复统计错误，更多指标)
  • PG 导出器 0.4.1 (超时参数等)
  • Grafana 8.4.4
  • Prometheus 2.33.4
  • Greenplum 6.19.4 / MatrixDB 4.4.0
  • Loki 现在作为 rpm 包提供，而不是 zip 存档。

错误修复

  • 删除 patroni 的 consul 依赖，这使其更容易迁移到新的 consul 集群
  • 修复 prometheus bin/new 脚本的默认数据目录路径：从 /export/prometheus 更改为 /data/prometheus
  • 在 vip-manager systemd 服务中添加重新启动秒数
  • 修复错别字和任务

API 变更

新增变量

  • node_cluster：节点集群的身份变量
  • nodename_overwrite：如果设置，则 nodename 将设置为节点的主机名
  • nodename_exchange：交换 play 主机之间的节点主机名（在 /etc/hosts 中）
  • node_dns_hosts_extra：可以通过单个实例/集群轻松覆盖的额外静态 dns 记录
  • patroni_enabled：如果禁用，postgres & patroni 的引导过程不会在 postgres 角色期间执行
  • pgbouncer_enabled：如果禁用，pgbouncer 在 postgres 角色期间不会启动
  • pg_exporter_params：生成监控目标 url 时为 pg_exporter 提供的额外 url 参数。
  • pg_provision：布尔值变量，表示是否执行 postgres 角色的资源配置部分（模板，数据库，用户）
  • no_cmdb：用于 infra.yml 和 infra-demo.yml 播放书，不会在元节点上创建 cmdb。
MD5 (app.tgz) = f887313767982b31a2b094e5589a75ea
MD5 (matrix.tgz) = 3d063437c482d94bd7e35df1a08bbc84
MD5 (pigsty.tgz) = e143b88ebea1474f9ebaffddc6072c49
MD5 (pkg.tgz) = 73e8f5ce995b1f1760cb63c1904fb91b

信息来源

1.5 - Pigsty v1.3.1

仪表盘打磨、安全修复与软件升级

v1.3.1 ·

监控

  • PGSQL & PGCAT 仪表盘改进
  • 优化 pgcat 实例 & pgcat 数据库的布局
  • 在 pgsql 实例仪表盘中添加关键指标面板，与 pgsql 集群保持一致
  • 在 pgcat 数据库中添加表/索引膨胀面板，移除 pgcat 膨胀仪表盘
  • 在 pgcat 数据库仪表盘中添加索引信息
  • 修复在 grafana 8.3 中的损坏面板
  • 在 nginx 主页中添加 redis 索引

部署

  • 新的 infra-demo.yml 剧本用于一次性引导
  • 使用 infra-jupyter.yml 剧本部署可选的 jupyter lab 服务器
  • 使用 infra-pgweb.yml 剧本部署可选的 pgweb 服务器
  • 在 meta 节点上新的 pg 别名，可以从 admin 用户启动 postgres 集群（除了 postgres）
  • 根据 timescaledb-tune 的建议调整所有 patroni 配置模板中的 max_locks_per_transactions
  • 在配置模板中添加 citus.node_conninfo: 'sslmode=prefer' 以便在没有 SSL 的情况下使用 citus
  • 在 pgdg14 包列表中添加所有扩展（除了 pgrouting）
  • 将 node_exporter 升级到 v1.3.1
  • 将 PostgREST v9.0.0 添加到包列表。从 postgres 模式生成 API。

错误修复

  • Grafana 的安全漏洞（升级到 v8.3.1 问题)
  • 修复 pg_instance & pg_service 在 register 角色中从剧本的中间开始时的问题
  • 修复在没有 pg_cluster 变量存在的主机上 nginx 主页渲染问题
  • 在升级到 grafana 8.3.1 时修复样式问题

信息来源

1.6 - Pigsty v1.3.0

PGCAT 重整 & PGSQL 增强 & Redis Beta 支持

v1.3.0 ·

  • 【功能增强】Redis 部署（集群、哨兵、主从）
  • 【功能增强】Redis 监控
    • Redis 总览仪表盘
    • Redis 集群仪表盘
    • Redis 实例仪表盘 -【功能增强】 监控：PGCAT 大修
    • 新仪表盘：PGCAT 实例
    • 新仪表盘：PGCAT 数据库仪表盘
    • 重做仪表盘：PGCAT 表格
  • 【功能增强】 监控：PGSQL 增强
    • 新面板：PGSQL 集群，添加 10 个关键指标面板（默认切换）
    • 新面板：PGSQL 实例，添加 10 个关键指标面板（默认切换）
    • 简化 & 重新设计：PGSQL 服务
    • 在 PGCAT & PGSL 仪表盘之间添加交叉引用 -【功能增强】 监控部署
    • 现在 grafana 数据源在仅监控部署期间自动注册 -【功能增强】 软件升级
    • 将 PostgreSQL 13 添加到默认包列表
    • 默认升级到 PostgreSQL 14.1
    • 添加 greenplum rpm 和依赖项
    • 添加 redis rpm & 源代码包
    • 将 perf 添加为默认包

信息来源

1.7 - Pigsty v1.2.0

默认 PGSQL 版本升级至 14

v1.2.0 ·

  • 【功能增强】默认使用 PostgreSQL 14 版本
  • 【功能增强】默认使用 TimescaleDB 2.5 扩展
    • 现在 timescaledb 和 postgis 默认在 cmdb 中启用
  • 【功能增强】 新增仅监控模式：
    • 仅通过可连接的 URL，您可以使用 pigsty 监控现有的 pg 实例
    • pg_exporter 将在本地的 meta 节点上部署
    • 新仪表板 PGSQL Cluster Monly 用于远程集群
  • 【功能增强】软件升级
    • grafana 升级到 8.2.2
    • pev2 升级到 v0.11.9
    • promscale 升级到 0.6.2
    • pgweb 升级到 0.11.9
    • 新增扩展：pglogical、pg_stat_monitor、orafce -【功能增强】自动检测机器规格并使用适当的 node_tune 和 pg_conf 模板 -【功能增强】重做与膨胀相关的视图，现在公开更多信息 -【功能增强】删除 timescale 和 citus 的内部监控 -【功能增强】新剧本 pgsql-audit.yml 用于创建审计报告 -【BUG 修复】现在 pgbouncer_exporter 资源所有者是 {{ pg_dbsu }} 而不是 postgres -【BUG 修复】 修复在执行 REINDEX TABLE CONCURRENTLY 时 pg_exporter 在 pg_table pg_index 上的重复指标 -【功能增强】现在所有配置模板都减少到两个：auto 和 demo。(已删除：pub4, pg14, demo4, tiny, oltp)
    • 如果 vagrant 是默认用户，则配置 pigsty-demo，否则使用 pigsty-auto。

如何从 v1.1.1 升级

在 1.2.0 中没有 API 变更。您仍然可以使用旧的 pigsty.yml 配置文件 (PG13)。 对于基础设施部分，重新执行 repo 将完成大部分工作。

至于数据库，您仍然可以使用现有的 PG13 实例。就地升级在涉及到像 PostGIS 和 Timescale 这样的扩展时非常棘手。我强烈推荐使用逻辑复制进行数据库迁移。 新的剧本 pgsql-migration.yml 将使这一过程变得容易得多。它将创建一系列的脚本，帮助您近乎零停机时间地迁移您的集群。

信息来源

1.8 - Pigsty v1.1.1

TimescaleDB 升级与新 Patroni 配置模板

v1.1.1 ·

  • 【功能增强】 用 timescale 版本替换 timescaledb 的 apache 版本
  • 【功能增强】 升级 prometheus 到 2.30
  • 【BUG 修复】 现在 pg_exporter 配置目录的属主是 {{ pg_dbsu }}，而不再是 prometheus

如何从 v1.1.0 升级？

这个版本的主要变动是 TimescaleDB，使用 TimescaleDB License （TSL）的官方版本替代了 PGDG 仓库中的 Apache License v2 的版本。

stop/pause postgres instance with timescaledb
yum remove -y timescaledb_13

[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/7/$basearch
repo_gpgcheck=0
gpgcheck=0
enabled=1

yum install timescaledb-2-postgresql13

信息来源

1.9 - Pigsty v1.1.0

主页，JupyterLab, PGWEB, Pev2 & pgbadger

v1.1 ·

  • 【增强功能】 增加 pg_dummy_filesize 以创建文件系统空间占位符
  • 【增强功能】 主页大改版
  • 【增强功能】 增加 Jupyter Lab 整合
  • 【增强功能】 增加 pgweb 控制台整合
  • 【增强功能】 增加 pgbadger 支持
  • 【增强功能】 增加 pev2 支持，解释可视化工具
  • 【增强功能】 增加 pglog 工具
  • 【增强功能】 更新默认的 pkg.tgz 软件版本：
    • PostgreSQL 升级至 v13.4（支持官方的 pg14）
    • pgbouncer 升级至 v1.16（指标定义更新）
    • Grafana 升级至 v8.1.4
    • Prometheus 升级至 v2.2.29
    • node_exporter 升级至 v1.2.2
    • haproxy 升级至 v2.1.1
    • consul 升级至 v1.10.2
    • vip-manager 升级至 v1.0.1

API 变更

  • nginx_upstream 现在持有不同的结构。（不兼容）
  • 新的配置条目：app_list，渲染至主页的导航条目
  • 新的配置条目：docs_enabled，在默认服务器上设置本地文档
  • 新的配置条目：pev2_enabled，设置本地的 pev2 工具
  • 新的配置条目：pgbadger_enabled，创建日志概要/报告目录
  • 新的配置条目：jupyter_enabled，在元节点上启用 Jupyter Lab 服务器
  • 新的配置条目：jupyter_username，指定运行 Jupyter Lab 的用户
  • 新的配置条目：jupyter_password，指定 Jupyter Lab 的默认密码
  • 新的配置条目：pgweb_enabled，在元节点上启用 pgweb 服务器
  • 新的配置条目：pgweb_username，指定运行 pgweb 的用户
  • 将内部标记 repo_exist 重命名为 repo_exists
  • 现在 repo_address 的默认值为 pigsty 而非 yum.pigsty
  • 现在 haproxy 的访问点为 http://pigsty 而非 http://h.pigsty

信息来源

1.10 - Pigsty v1.0.1

问题修复与文档改进

v1.0.1 ·

2021-09-14

  • 文档更新
    • 现已支持中文文档
    • 现已支持机器翻译的英文文档
  • 错误修复：pgsql-remove 不会移除主实例
  • 错误修复：用 pg_cluster + pg_seq 替换 pg_instance
    • Start-At-Task 可能因为 pg_instance 未定义而失败
  • 错误修复：从默认共享预加载库中移除 citus
    • citus 会强制 max_prepared_transaction 的值为非零
  • 错误修复：在 configure 中进行 ssh sudo 检查：
    • 现在使用 ssh -t sudo -n ls 进行权限检查
  • 笔误修复：pg-backup 脚本的笔误
  • 警报调整：移除 NTP 合理性检查警报（与 ClockSkew 重复）
  • 导出器调整：移除 collector.systemd 以减少开销

信息来源

1.11 - Pigsty v1.0.0

v1 正式版，监控系统重整

v1.0.0 ·

v1 正式发布，监控系统全面改进

亮点

  • 监控系统全面改进
    • 在 Grafana 8.0 上新增仪表盘
    • 新的度量定义，增加 PG14 支持
    • 简化的标签系统：静态标签集：(job, cls, ins)
    • 新的警报规则与衍生度量
    • 同时监控多个数据库
    • 实时日志搜索 & csvlog 分析
    • 链接丰富的仪表盘，点击图形元素进行深入|汇总
  • 架构变更
    • 将 citus 和 timescaledb 加入默认安装部分
    • 增加对 PostgreSQL 14beta2 的支持
    • 简化 haproxy 管理页面索引
    • 通过添加新的角色 register 来解耦基础设施和 pgsql
    • 添加新角色 loki 和 promtail 用于日志记录
    • 为管理员节点上的管理员用户添加新角色 environ 以设置环境
    • 默认使用 static 服务发现用于 prometheus（而不是 consul）
    • 添加新角色 remove 以优雅地移除集群和实例
    • 升级 prometheus 和 grafana 的配置逻辑
    • 升级到 vip-manager 1.0，node_exporter 1.2，pg_exporter 0.4，grafana 8.0
    • 现在，每个实例上的每个数据库都可以自动注册为 grafana 数据源
    • 将 consul 注册任务移到 register 角色，更改 consul 服务标签
    • 添加 cmdb.sql 作为 pg-meta 基线定义（CMDB & PGLOG）
  • 应用框架
    • 可扩展框架用于新功能
    • 核心应用：PostgreSQL 监控系统：pgsql
    • 核心应用：PostgreSQL 目录浏览器：pgcat
    • 核心应用：PostgreSQL Csvlog 分析器：pglog
    • 添加示例应用 covid 用于可视化 covid-19 数据
    • 添加示例应用 isd 用于可视化 isd 数据
  • 其他
    • 添加 jupyterlab，为数据科学提供完整的 python 环境
    • 添加 vonng-echarts-panel 以恢复对 Echarts 的支持
    • 添加 wrap 脚本 createpg，createdb，createuser
    • 添加 cmdb 动态库存脚本：load_conf.py，inventory_cmdb，inventory_conf
    • 移除过时的剧本：pgsql-monitor，pgsql-service，node-remove 等….

API 变更

  • 新变量: node_meta_pip_install
  • 新变量: grafana_admin_username
  • 新变量: grafana_database
  • 新变量: grafana_pgurl
  • 新变量: pg_shared_libraries
  • 新变量: pg_exporter_auto_discovery
  • 新变量: pg_exporter_exclude_database
  • 新变量: pg_exporter_include_database
  • 变量重命名: grafana_url 为 grafana_endpoint

Bug 修复

  • 修复默认时区 Asia/Shanghai (CST) 问题
  • 修复 pgbouncer & patroni 的 nofile 限制
  • 当执行标签 pgbouncer 时，pgbouncer 的用户列表和数据库列表将会被生成

信息来源

1.12 - Pigsty v0.9.1

三步安装流程、PostgreSQL 13.3 与 Grafana 7.5.6

v0.9.1 ·

发布亮点

  • PostgreSQL 更新至 13.3，Grafana 更新至 7.5.6。
  • 新增 configure 配置向导。
  • 安装流程收敛为下载、配置、安装三步：
curl -fsSL https://github.com/pgsty/pigsty/releases/download/v0.9.1/pigsty.tgz | gzip -d | tar -xC ~
cd ~/pigsty
./configure
make install

信息来源

1.13 - Pigsty v0.9.0

Pigsty 图形界面，命令行界面，日志集成

v0.9.0 ·

v0.9 极大简化了安装流程，进行了大量日志相关改进，开发了命令行工具（Beta），并修复了一系列问题。

详情

新功能

  • 一键安装模式：

    /bin/bash -c "$(curl -fsSL https://pigsty.cc/install)"

  • 开发命令行工具 pigsty-cli 封装常用 Ansible 命令，目前 pigsty-cli 处于 Beta 状态

  • 使用 Loki 与 Promtail 收集日志：

    • 默认收集 Postgres，Pgbouncer，Patroni 日志
    • 新增部署脚本 infra-loki.yml 与 pgsql-promtail.yml
    • 定义基于日志的监控指标
    • 使用 Grafana 制作日志相关可视化面板。

  • 监控组件可以使用二进制安装，使用 files/get_bin.sh 下载监控二进制组件。

  • 飞升模式： 当集群元节点初始化完成后，可以使用 bin/upgrade 升级为动态 Inventory 使用 pg-meta 上的数据库代替 YAML 配置文件。

问题修复

  • 集中修复日志相关问题：
    • 修复了 HAProxy 健康检查造成 PG 日志中大量 connection reset by peer 的问题。
    • 修复了 HAProxy 健康检查造成 Patroni 日志中大量出现 Connect Reset Exception 的问题
    • 修复了 Patroni 日志时间戳格式，去除毫秒时间戳，附加完整时区信息。
    • 为 dbuser_monitor 配置1秒的 log_min_duration_statement，避免监控查询出现在日志中。
  • 重构 Grafana 角色
    • 在保持 API 不变的前提下重构 Grafana 角色。
    • 使用 CDN 下载预打包的 Grafana 插件，加速插件下载
  • 其他问题修复
    • 修复了 pgbouncer-create-user 未能正确处理 md5 密码的问题。
    • 完善了数据库与用户创建 SQL 模版中参数空置检查。
    • 修复了 NODE DNS 配置时如果手工中断执行，DNS 配置可能出错的问题。
    • 重构了 Makefile 快捷方式 Makefile 中的错别字

参数变更

  • node_disable_swap 默认为 False，默认不会关闭 SWAP。
  • node_sysctl_params 不再有默认修改的系统参数。
  • grafana_plugin 的默认值 install 现在意味着当插件缓存不存在时，从 CDN 下载。
  • repo_url_packages 现在从 Pigsty CDN 下载额外的 RPM 包，解决墙内无法访问的问题。
  • proxy_env.no_proxy 现在将 Pigsty CDN 加入到 NOPROXY 列表中。
  • grafana_customize 现在默认为 false，启用意味着安装 Pigsty Pro 版 UI（默认不开源所以不要启用）
  • node_admin_pk_current，新增选项，启用后会将当前用户的 ~/.ssh/id_rsa.pub 添加至管理员的 Key 中
  • loki_clean：新增选项，安装 Loki 时是否清除现有数据
  • loki_data_dir：新增选项，指明安装 Loki 时的数据目录
  • promtail_enabled 是否启用 Promtail 日志收集服务？
  • promtail_clean 是否在安装 promtail 时移除已有状态信息？
  • promtail_port promtail 使用的默认端口，默认为9080
  • promtail_status_file 保存 Promtail 状态信息的文件位置
  • promtail_send_url 用于接收日志的 loki 服务 endpoint

信息来源

1.14 - Pigsty v0.8.0

服务置备，定制对外暴露的数据库服务

v0.8.0 ·

v0.8 针对 服务（Service） 接入部分进行了彻底的重做。现在除了默认的 primary, replica 服务外，用户可以自行定义新的服务。服务的接口可以支持多种不同的实现，例如 L4 DPKG VIP 可作为 Haproxy 的替代品与 Pigsty 集成。同时，针对用户反馈的一些问题进行了集中处理与改进。

详情

改动内容

v0.8 是供给方案定稿版本，此后供给系统的 API 将保持稳定。

API 变更

原有 vip 与 haproxy 角色的所有配置项，现在迁移至 service 角色中。

#------------------------------------------------------------------------------
# SERVICE PROVISION
#------------------------------------------------------------------------------
pg_weight: 100              # default load balance weight (instance level)

# - service - #
pg_services:                                  # how to expose postgres service in cluster?
  # primary service will route {ip|name}:5433 to primary pgbouncer (5433->6432 rw)
  - name: primary           # service name {{ pg_cluster }}_primary
    src_ip: "*"
    src_port: 5433
    dst_port: pgbouncer     # 5433 route to pgbouncer
    check_url: /primary     # primary health check, success when instance is primary
    selector: "[]"          # select all instance as primary service candidate

  # replica service will route {ip|name}:5434 to replica pgbouncer (5434->6432 ro)
  - name: replica           # service name {{ pg_cluster }}_replica
    src_ip: "*"
    src_port: 5434
    dst_port: pgbouncer
    check_url: /read-only   # read-only health check. (including primary)
    selector: "[]"          # select all instance as replica service candidate
    selector_backup: "[? pg_role == `primary`]"   # primary are used as backup server in replica service

  # default service will route {ip|name}:5436 to primary postgres (5436->5432 primary)
  - name: default           # service's actual name is {{ pg_cluster }}-{{ service.name }}
    src_ip: "*"             # service bind ip address, * for all, vip for cluster virtual ip address
    src_port: 5436          # bind port, mandatory
    dst_port: postgres      # target port: postgres|pgbouncer|port_number , pgbouncer(6432) by default
    check_method: http      # health check method: only http is available for now
    check_port: patroni     # health check port:  patroni|pg_exporter|port_number , patroni by default
    check_url: /primary     # health check url path, / as default
    check_code: 200         # health check http code, 200 as default
    selector: "[]"          # instance selector
    haproxy:                # haproxy specific fields
      maxconn: 3000         # default front-end connection
      balance: roundrobin   # load balance algorithm (roundrobin by default)
      default_server_options: 'inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100'

  # offline service will route {ip|name}:5438 to offline postgres (5438->5432 offline)
  - name: offline           # service name {{ pg_cluster }}_replica
    src_ip: "*"
    src_port: 5438
    dst_port: postgres
    check_url: /replica     # offline MUST be a replica
    selector: "[? pg_role == `offline` || pg_offline_query ]"         # instances with pg_role == 'offline' or instance marked with 'pg_offline_query == true'
    selector_backup: "[? pg_role == `replica` && !pg_offline_query]"  # replica are used as backup server in offline service

pg_services_extra: []        # extra services to be added

# - haproxy - #
haproxy_enabled: true                         # enable haproxy among every cluster members
haproxy_reload: true                          # reload haproxy after config
haproxy_policy: roundrobin                    # roundrobin, leastconn
haproxy_admin_auth_enabled: false             # enable authentication for haproxy admin?
haproxy_admin_username: admin                 # default haproxy admin username
haproxy_admin_password: admin                 # default haproxy admin password
haproxy_exporter_port: 9101                   # default admin/exporter port
haproxy_client_timeout: 3h                    # client side connection timeout
haproxy_server_timeout: 3h                    # server side connection timeout

# - vip - #
vip_mode: none                                # none | l2 | l4
vip_reload: true                              # whether reload service after config
# vip_address: 127.0.0.1                      # virtual ip address ip (l2 or l4)
# vip_cidrmask: 24                            # virtual ip address cidr mask (l2 only)
# vip_interface: eth0                         # virtual ip network interface (l2 only)

新增选项

# - localization - #
pg_encoding: UTF8                             # default to UTF8
pg_locale: C                                  # default to C
pg_lc_collate: C                              # default to C
pg_lc_ctype: en_US.UTF8                       # default to en_US.UTF8

pg_reload: true                               # reload postgres after hba changes
vip_mode: none                                # none | l2 | l4
vip_reload: true                              # whether reload service after config

移除选项

haproxy_check_port                            # Haproxy相关参数已经被Service定义覆盖
haproxy_primary_port
haproxy_replica_port
haproxy_backend_port
haproxy_weight
haproxy_weight_fallback
vip_enabled                                   # vip_enabled参数被vip_mode覆盖

服务管理

pg_services 与 pg_services_extra 定义了集群中的 服务，每一个服务的定义结构如下例所示：

一个服务必须指定以下内容：

  • 名称：服务的完整名称以数据库集群名为前缀，以 service.name 为后缀，通过 - 连接。例如在 pg-test 集群中 name=primary 的服务，其完整服务名称为 pg-test-primary。

  • 端口：在 Pigsty 中，服务默认采用 NodePort 的形式对外暴露，因此暴露端口为必选项。但如果使用外部负载均衡服务接入方案，您也可以通过其他的方式区分服务。

  • 选择器：选择器指定了服务的成员，采用 JMESPath 的形式，从所有集群实例成员中筛选变量。默认的 [] 选择器会选取所有的集群成员。

    此外 selector_backup 会选择或标记用于 backup 的实例列表（当集群中所有其他成员失效时方才接管服务）

  # default service will route {ip|name}:5436 to primary postgres (5436->5432 primary)
  - name: default           # service's actual name is {{ pg_cluster }}-{{ service.name }}
    src_ip: "*"             # service bind ip address, * for all, vip for cluster virtual ip address
    src_port: 5436          # bind port, mandatory
    dst_port: postgres      # target port: postgres|pgbouncer|port_number , pgbouncer(6432) by default
    check_method: http      # health check method: only http is available for now
    check_port: patroni     # health check port:  patroni|pg_exporter|port_number , patroni by default
    check_url: /primary     # health check url path, / as default
    check_code: 200         # health check http code, 200 as default
    selector: "[]"          # instance selector
    haproxy:                # haproxy specific fields
      maxconn: 3000         # default front-end connection
      balance: roundrobin   # load balance algorithm (roundrobin by default)
      default_server_options: 'inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100'

数据库管理

数据库现在可以对 locale 的细分选项：lc_ctype 与 lc_collate 分别进行指定。支持这一功能的主要原因是 PG 的扩展插件 pg_trgm 需要在 lc_ctype!=C 的环境中才能正常支持中文。

旧接口定义

pg_databases:
  - name: meta                      # name is the only required field for a database
    owner: postgres                 # optional, database owner
    template: template1             # optional, template1 by default
    encoding: UTF8                  # optional, UTF8 by default
    locale: C                       # optional, C by default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

新的接口定义

pg_databases:
  - name: meta                      # name is the only required field for a database
    # owner: postgres                 # optional, database owner
    # template: template1             # optional, template1 by default
    # encoding: UTF8                # optional, UTF8 by default , must same as template database, leave blank to set to db default
    # locale: C                     # optional, C by default , must same as template database, leave blank to set to db default
    # lc_collate: C                 # optional, C by default , must same as template database, leave blank to set to db default
    # lc_ctype: C                   # optional, C by default , must same as template database, leave blank to set to db default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    # tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

信息来源

1.15 - Pigsty v0.7.0

仅监控部署，监控现有 PostgreSQL 实例

v0.7.0 ·

v0.7 针对 接入已有数据库实例 进行了改进，现在用户可以采用 仅监控部署（Monly Deployment） 模式使用 Pigsty。同时新增了专用于管理数据库与用户、以及单独部署监控的剧本，并对数据库与用户的定义进行改进。

详情

Features

Bug Fix

API 变更

新增选项

prometheus_sd_target: batch                   # batch|single    监控目标定义文件采用单体还是每个实例一个
exporter_install: none                        # none|yum|binary 监控Exporter的安装模式
exporter_repo_url: ''                         # 如果设置，这里的REPO连接会加入目标的Yum源中
node_exporter_options: '--no-collector.softnet --collector.systemd --collector.ntp --collector.tcpstat --collector.processes'                          # Node Exporter默认的命令行选项
pg_exporter_url: ''                           # 可选，PG Exporter监控对象的URL
pgbouncer_exporter_url: ''                    # 可选，PGBOUNCER EXPORTER监控对象的URL

移除选项

exporter_binary_install: false                 # 功能被 exporter_install 覆盖

定义结构变更

pg_default_roles                               # 变化细节参考 用户管理。
pg_users                                       # 变化细节参考 用户管理。
pg_databases                                   # 变化细节参考 数据库管理。

重命名选项

pg_default_privilegs -> pg_default_privileges # 很明显这是一个错别字

仅监控模式

有时用户不希望使用 Pigsty 供给方案，只希望使用 Pigsty 监控系统管理现有 PostgreSQL 实例。

Pigsty 提供了仅监控部署（monly, monitor-only 模式，剥离供给方案部分，可用于监控现有 PostgreSQL 集群。

仅监控模式的部署流程与标准模式大体上保持一致，但省略了很多步骤

  • 在 元节点 上完成基础设施初始化的部分与标准流程保持一致，仍然通过 ./infra.yml 完成。
  • 不需要在 数据库节点 上完成 基础设施初始化。
  • 不需要在 数据库节点 上执行数据库初始化的绝大多数任务，而是通过专用的 ./pgsql-monitor.yml 完成仅监控系统部署。
  • 实际使用的配置项大大减少，只保留基础设施相关变量，与 监控系统相关的少量变量。

数据库管理

Database provisioning interface enhancement #33

旧接口定义

pg_databases:                       # create a business database 'meta'
  - name: meta
    schemas: [meta]                 # create extra schema named 'meta'
    extensions: [{name: postgis}]   # create extra extension postgis
    parameters:                     # overwrite database meta's default search_path
      search_path: public, monitor

新的接口定义

pg_databases:
  - name: meta                      # name is the only required field for a database
    owner: postgres                 # optional, database owner
    template: template1             # optional, template1 by default
    encoding: UTF8                  # optional, UTF8 by default
    locale: C                       # optional, C by default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

接口变更

  • Add new options: template , encoding, locale, allowconn, tablespace, connlimit
  • Add new option revokeconn, which revoke connect privileges from public for this database
  • Add comment field for database

数据库变更

在运行中集群中创建新数据库可以使用 pgsql-createdb.yml 剧本，在配置中定义完新数据库后，执行以下剧本。

./pgsql-createdb.yml -e pg_database=<your_new_database_name>

通过 -e pg_datbase= 告知需要创建的数据库名称，则该数据库即会被创建（或修改）。具体执行的命令参见集群主库 /pg/tmp/pg-db-{{ database.name}}.sql 文件。

用户管理

User provisioning interface enhancement #34

旧接口定义

pg_users:
  - username: test                  # example production user have read-write access
    password: test                  # example user's password
    options: LOGIN                  # extra options
    groups: [ dbrole_readwrite ]    # dborole_admin|dbrole_readwrite|dbrole_readonly
    comment: default test user for production usage
    pgbouncer: true                 # add to pgbouncer

新接口定义

pg_users:
  # complete example of user/role definition for production user
  - name: dbuser_meta               # example production user have read-write access
    password: DBUser.Meta           # example user's password, can be encrypted
    login: true                     # can login, true by default (should be false for role)
    superuser: false                # is superuser? false by default
    createdb: false                 # can create database? false by default
    createrole: false               # can create role? false by default
    inherit: true                   # can this role use inherited privileges?
    replication: false              # can this role do replication? false by default
    bypassrls: false                # can this role bypass row level security? false by default
    connlimit: -1                   # connection limit, -1 disable limit
    expire_at: '2030-12-31'         # 'timestamp' when this role is expired
    expire_in: 365                  # now + n days when this role is expired (OVERWRITE expire_at)
    roles: [dbrole_readwrite]       # dborole_admin|dbrole_readwrite|dbrole_readonly
    pgbouncer: true                 # add this user to pgbouncer? false by default (true for production user)
    parameters:                     # user's default search path
      search_path: public
    comment: test user

接口变更

  • username field rename to name
  • groups field rename to roles
  • options now split into separated configration entries: login, superuser, createdb, createrole, inherit, replication,bypassrls,connlimit
  • expire_at and expire_in options
  • pgbouncer option for user is now false by default

用户管理

在运行中集群中创建新数据库可以使用 pgsql-createuser.yml 剧本，在配置中定义完新数据库后，执行以下剧本。

./pgsql-createuser.yml -e pg_user=<your_new_user_name>

通过 -e pg_user= 告知需要创建的数据库名称，则该数据库即会被创建（或修改）。具体执行的命令参见集群主库 /pg/tmp/pg-user-{{ user.name}}.sql 文件。

信息来源

1.16 - Pigsty v0.6.0

架构增强，将 PG 与 Consul 解耦

v0.6.0 ·

v0.6 对数据库供给方案进行了修改与调整，根据用户的反馈添加了一系列实用功能与修正。针对监控系统的移植性进行优化，便于与其他外部数据库供给方案对接。

详情

BUG 修复

  • 修复了新版本 Patroni 重启后会重置 PG HBA 的问题
  • 修复了 PG Overview Dashboard 标题中的别字
  • 修复了沙箱集群 pg-test 的默认主库，原来为 pg-test-2，应当为 pg-test-1
  • 修复了过时代码注释

功能改进

  • 改造 Prometheus 与监控供给方式
    • 允许在无基础设施的情况下对已有 PG 集群进行监控部署，便于监控系统与其他供给方案集成。#11
    • 基于 Inventory 渲染所有监控对象的静态列表，用于静态服务发现。#11
    • Prometheus 添加了静态对象模式，用于替代动态服务发现，集中进行身份管理 #11
    • 监控 Exporter 现在添加了 service_registry 选项，Consul 服务注册变为可选项 #13
    • Exporter 现在可以通过拷贝二进制的方式直接安装：exporter_binary_install，#14
    • Exporter 现在具有 xxx_enabled 选项，控制是否启用该组件。
  • Haproxy 供给重构与改进 #8
    • 新增了全局 HAProxy 管理界面导航，默认域名 h.pigsty
    • 允许将主库加入只读服务集中，当集群中所有从库宕机时自动承接读流量。 #8
    • 允许位 Haproxy 实例管理界面启用认证 haproxy_admin_auth_enabled
    • 允许通过配置项调整每个服务对应后端的流量权重. #10
  • 访问控制模型改进。#7
    • 添加了默认角色 dbrole_offline，用于慢查询，ETL，交互式查询场景。
    • 修改默认 HBA 规则，允许 dbrole_offline 分组的用户访问 pg_role == 'offline' 及 pg_offline_query == true 的实例。
  • 软件更新 Release v0.6
    • PostgreSQL 13.2
    • Prometheus 2.25
    • PG Exporter 0.3.2
    • Node Exporter 1.1
    • Consul 1.9.3
    • 更新默认 PG 源：PostgreSQL 现在默认使用浙江大学的镜像，加速下载安装

接口变更

新增选项

service_registry: consul                      # 服务注册机制：none | consul | etcd | both
prometheus_options: '--storage.tsdb.retention=30d'  # prometheus命令行选项
prometheus_sd_method: consul                  # Prometheus使用的服务发现机制：static|consul
prometheus_sd_interval: 2s                    # Prometheus服务发现刷新间隔
pg_offline_query: false                       # 设置后将允许dbrole_offline角色连接与查询该实例
node_exporter_enabled: true                   # 设置后将安装配置Node Exporter
pg_exporter_enabled: true                     # 设置后将安装配置PG Exporter
pgbouncer_exporter_enabled: true              # 设置后将安装配置Pgbouncer Exporter
dcs_disable_purge: false                      # 双保险，强制 dcs_exists_action = abort 避免误删除DCS实例
pg_disable_purge: false                       # 双保险，强制 pg_exists_action = abort 避免误删除数据库实例
haproxy_weight: 100                           # 配置实例的相对负载均衡权重
haproxy_weight_fallback: 1                    # 配置集群主库在只读服务中的相对权重

移除选项

prometheus_metrics_path                       # 与 exporter_metrics_path 重复
prometheus_retention                          # 功能被 prometheus_options 覆盖

信息来源

1.17 - Pigsty v0.5.2

剧本重构、VIP/HAProxy 控制与配置整理

[!INFO]

这个历史版本只有 Git 标签与源码树，没有单独发布 GitHub Release。

发布亮点

  • 将 pigsty.yml 设为默认配置，并重组标准的 sandbox.yml、infra.yml 与 pgsql.yml 工作流。
  • 将 VIP 管理从 HAProxy 中拆分，新增管理员认证、流量权重与主库兜底控制。
  • 在主剧本中加入域名服务器步骤，并同步更新相关文档。

v0.5.2 是没有独立 GitHub Release 正文的维护标签，本说明依据标签提交整理。

信息来源

1.18 - Pigsty v0.5.1

仪表盘修复、浙大镜像与文档更新

[!INFO]

这个历史版本只有 Git 标签与源码树，没有单独发布 GitHub Release。

发布亮点

  • 修复 v0.5.0 之后发现的 PostgreSQL 集群与实例仪表盘问题。
  • 默认 PostgreSQL 镜像切换至浙江大学镜像，改善区域内安装速度。
  • 更新 README，并整理 v0.5 系列文档快照。

v0.5.1 是没有独立 GitHub Release 正文的维护标签，本说明依据标签提交整理。

信息来源

1.19 - Pigsty v0.5.0

支持在配置中定义业务数据库/用户

v0.5.0 ·

Pigsty 现在有了官方网站啦：pigsty.cc 🎉 !

详情

亮点特性

  • Pigsty 官方 文档站 正式上线！
  • 添加了数据库模板的定制支持，用户可以通过配置文件定制所需的数据库内部对象。
  • 对默认 访问控制 模型进行了改进
  • 重构了 HBA 管理的逻辑，现在将由 Pigsty 替代 Patroni 直接负责生成 HBA
  • 将 Grafana 监控系统的供给方案从 sqlite 改为 JSON 文件静态 Provision
  • 将 pg-cluster-replication 面板加入 Pigsty 开源免费套餐。
  • 最新的经过测试的离线安装包：pkg.tgz (v0.5)

定制数据库

您是否烦恼过单实例多租户的问题？比如总有研发拿着 PostgreSQL 当 MySQL 使，明明是一个 Schema 就能解决的问题，非要创建一个新的数据库出来，在一个实例中创建出几十个不同的 DB。 不要忧伤，不要心急。Pigsty 已经提供数据库内部对象的 Provision 方案，您可以轻松地在配置文件中指定所需的数据库内对象，包括：

  • 角色
    • 用户/角色名
    • 密码
    • 用户属性
    • 用户备注
    • 用户所属的权限组
  • 数据库
    • 属主
    • 额外的模式
    • 额外的扩展插件
    • 数据库级的自定义配置参数
  • 数据库
    • 属主
    • 额外的模式
    • 额外的扩展插件
    • 数据库级的自定义配置参数
  • 默认权限
    • 默认情况下这里配置的权限会应用至所有由 超级用户 和 管理员用户创建的对象上。
  • 默认扩展
    • 所有新创建的业务数据库都会安装有这些默认扩展
  • 默认模式
    • 所有新创建的业务数据库都会创建有这些默认的模式

配置样例

# 通常是每个DB集群配置的变量
pg_users:
  - username: test
    password: test
    comment: default test user
    groups: [ dbrole_readwrite ]    # dborole_admin|dbrole_readwrite|dbrole_readonly
pg_databases:                       # create a business database 'test'
  - name: test
    extensions: [{name: postgis}]   # create extra extension postgis
    parameters:                     # overwrite database meta's default search_path
      search_path: public,monitor

# 通常是整个环境统一配置的全局变量
# - system roles - #
pg_replication_username: replicator           # system replication user
pg_replication_password: DBUser.Replicator    # system replication password
pg_monitor_username: dbuser_monitor           # system monitor user
pg_monitor_password: DBUser.Monitor           # system monitor password
pg_admin_username: dbuser_admin               # system admin user
pg_admin_password: DBUser.Admin               # system admin password

# - default roles - #
pg_default_roles:
  - username: dbrole_readonly                 # sample user:
    options: NOLOGIN                          # role can not login
    comment: role for readonly access         # comment string

  - username: dbrole_readwrite                # sample user: one object for each user
    options: NOLOGIN
    comment: role for read-write access
    groups: [ dbrole_readonly ]               # read-write includes read-only access

  - username: dbrole_admin                    # sample user: one object for each user
    options: NOLOGIN BYPASSRLS                # admin can bypass row level security
    comment: role for object creation
    groups: [dbrole_readwrite,pg_monitor,pg_signal_backend]

  # NOTE: replicator, monitor, admin password are overwritten by separated config entry
  - username: postgres                        # reset dbsu password to NULL (if dbsu is not postgres)
    options: SUPERUSER LOGIN
    comment: system superuser

  - username: replicator
    options: REPLICATION LOGIN
    groups: [pg_monitor, dbrole_readonly]
    comment: system replicator

  - username: dbuser_monitor
    options: LOGIN CONNECTION LIMIT 10
    comment: system monitor user
    groups: [pg_monitor, dbrole_readonly]

  - username: dbuser_admin
    options: LOGIN BYPASSRLS
    comment: system admin user
    groups: [dbrole_admin]

  - username: dbuser_stats
    password: DBUser.Stats
    options: LOGIN
    comment: business read-only user for statistics
    groups: [dbrole_readonly]


# object created by dbsu and admin will have their privileges properly set
pg_default_privilegs:
  - GRANT USAGE                         ON SCHEMAS   TO dbrole_readonly
  - GRANT SELECT                        ON TABLES    TO dbrole_readonly
  - GRANT SELECT                        ON SEQUENCES TO dbrole_readonly
  - GRANT EXECUTE                       ON FUNCTIONS TO dbrole_readonly
  - GRANT INSERT, UPDATE, DELETE        ON TABLES    TO dbrole_readwrite
  - GRANT USAGE,  UPDATE                ON SEQUENCES TO dbrole_readwrite
  - GRANT TRUNCATE, REFERENCES, TRIGGER ON TABLES    TO dbrole_admin
  - GRANT CREATE                        ON SCHEMAS   TO dbrole_admin
  - GRANT USAGE                         ON TYPES     TO dbrole_admin

# schemas
pg_default_schemas: [monitor]

# extension
pg_default_extensions:
  - { name: 'pg_stat_statements',  schema: 'monitor' }
  - { name: 'pgstattuple',         schema: 'monitor' }
  - { name: 'pg_qualstats',        schema: 'monitor' }
  - { name: 'pg_buffercache',      schema: 'monitor' }
  - { name: 'pageinspect',         schema: 'monitor' }
  - { name: 'pg_prewarm',          schema: 'monitor' }
  - { name: 'pg_visibility',       schema: 'monitor' }
  - { name: 'pg_freespacemap',     schema: 'monitor' }
  - { name: 'pg_repack',           schema: 'monitor' }
  - name: postgres_fdw
  - name: file_fdw
  - name: btree_gist
  - name: btree_gin
  - name: pg_trgm
  - name: intagg
  - name: intarray

# postgres host-based authentication rules
pg_hba_rules:
  - title: allow meta node password access
    role: common
    rules:
      - host    all     all                         10.10.10.10/32      md5

  - title: allow intranet admin password access
    role: common
    rules:
      - host    all     +dbrole_admin               10.0.0.0/8          md5
      - host    all     +dbrole_admin               172.16.0.0/12       md5
      - host    all     +dbrole_admin               192.168.0.0/16      md5

  - title: allow intranet password access
    role: common
    rules:
      - host    all             all                 10.0.0.0/8          md5
      - host    all             all                 172.16.0.0/12       md5
      - host    all             all                 192.168.0.0/16      md5

  - title: allow local read-write access (local production user via pgbouncer)
    role: common
    rules:
      - local   all     +dbrole_readwrite                               md5
      - host    all     +dbrole_readwrite           127.0.0.1/32        md5

  - title: allow read-only user (stats, personal) password directly access
    role: replica
    rules:
      - local   all     +dbrole_readonly                               md5
      - host    all     +dbrole_readonly           127.0.0.1/32        md5
pg_hba_rules_extra: []

# pgbouncer host-based authentication rules
pgbouncer_hba_rules:
  - title: local password access
    role: common
    rules:
      - local  all          all                                     md5
      - host   all          all                     127.0.0.1/32    md5

  - title: intranet password access
    role: common
    rules:
      - host   all          all                     10.0.0.0/8      md5
      - host   all          all                     172.16.0.0/12   md5
      - host   all          all                     192.168.0.0/16  md5
pgbouncer_hba_rules_extra: []

数据库模板

权限模型

v0.5 改善了默认的权限模型，主要是针对单实例多租户的场景进行优化，并收紧权限控制。

  • 撤回了普通业务用户对非所属数据库的默认 CONNECT 权限
  • 撤回了非管理员用户对所属数据库的默认 CREATE 权限
  • 撤回了所有用户在 public 模式下的默认创建权限。

供给方式

原先 Pigsty 采用直接拷贝 Grafana 自带的 grafana.db 的方式完成监控系统的初始化。 这种方式虽然简单粗暴管用，但不适合进行精细化的版本控制管理。在 v0.5 中，Pigsty 采用了 Grafana API 完成了监控系统面板供给的工作。 您所需的就是在 grafana_url 中填入带有用户名密码的 Grafana URL。 因此，监控系统可以背方便地添加至已有的 Grafana 中。

信息来源

1.20 - Pigsty v0.4.0

支持 PostgreSQL 13，添加官方文档

v0.4.0 ·

第二个公开测试版 v0.4 现已正式发行！

详情

监控系统

Pigsty v0.4 对监控系统进行了整体升级改造，精心挑选了10个面板作为标准的 Pigsty 开源内容。同时，针对 Grafana 7.3的不兼容升级进行了大量适配改造工作。使用升级的 pg_exporter v0.3.1 作为默认指标导出器，调整了监控报警规则的监控面板连接。

Pigsty 开源版

Pigsty 开源版选定了以下10个 Dashboard 作为开源内容。其他 Dashboard 作为可选的商业支持内容提供。

  • PG Overview
  • PG Cluster
  • PG Service
  • PG Instance
  • PG Database
  • PG Query
  • PG Table
  • PG Table Catalog
  • PG Table Detail
  • Node

尽管进行了少量阉割，这10个监控面板所涵盖的内容仍然可以吊打所有同类软件。

软件升级

Pigsty v0.4 进行了大量软件适配工作，包括：

  • Upgrade to PostgreSQL 13.1, Patroni 2.0.1-4, add citus to repo.
  • Upgrade to pg_exporter 0.3.1
  • Upgrade to Grafana 7.3, Ton’s of compatibility work
  • Upgrade to prometheus 2.23, with new UI as default
  • Upgrade to consul 1.9

其他改进

  • Update prometheus alert rules
  • Fix alertmanager info links
  • Fix bugs and typos.
  • add a simple backup script

离线安装包

  • v0.4 的离线安装包（CentOS 7.8）已经可以从 Github 下载：pkg.tgz

信息来源

1.21 - Pigsty v0.3.0

虚拟机置备方案正式定稿

v0.3.0 ·

首个 Pigsty 公开测试版本现在已经释出！

详情

监控系统

Pigsty v0.3 包含以下8个监控面板作为开源内容：

  • PG Overview
  • PG Cluster
  • PG Service
  • PG Instance
  • PG Database
  • PG Table Overview
  • PG Table Catalog
  • Node

离线安装包

  • v0.3 离线安装包（CentOS 7.8）已经可以从 Github 下载：pkg.tgz

信息来源

1.22 - Pigsty v0.0.5

离线安装、Consul 角色与 HAProxy 修复

[!INFO]

这个历史版本只有 Git 标签与源码树，没有单独发布 GitHub Release。

发布亮点

  • 新增离线安装模式，支持在无法访问互联网的环境中完成交付。
  • 引入独立 Consul 角色，并更新软件仓库引导逻辑。
  • 加入 psql 启动辅助脚本，拆分 PostgreSQL 脚本任务，并修复 HAProxy 连接重置噪声。

本历史记录依据 v0.0.5 标签及其与 v0.0.4 的源码差异整理。

信息来源

1.23 - Pigsty v0.0.4

Ansible 角色拆分、网络与软件仓库重构

[!INFO]

这个历史版本只有 Git 标签与源码树，没有单独发布 GitHub Release。

发布亮点

  • 将原有单体自动化拆分为 Meta、Grafana、DNS、Nginx 与 Prometheus 等独立角色。
  • 新增静态网络处理，并调整本地软件仓库的上游策略。
  • 补充角色文档，使服务注册模板与新的目录布局保持一致。

本历史记录依据 v0.0.4 标签及其与 v0.0.3 的源码差异整理。

信息来源

1.24 - Pigsty v0.0.3

接口与监控模式改进

[!INFO]

这个历史版本只有 Git 标签与源码树，没有单独发布 GitHub Release。

发布亮点

  • 改进早期 Pigsty 配置接口，并加入监控模式。
  • 新增 Kubernetes 剧本，调整 PostgreSQL 初始化默认值。
  • 简化 Vagrant 引导流程，修复 HAProxy、Patroni 与监控注册中的若干问题。

这是公开发布系列之前的历史标签；本记录依据 v0.0.3 标签源码与对应提交历史整理。

信息来源

1.25 - Pigsty v0.2.0

置备流程重构、etcd DCS 与 HAProxy 2.2 支持

[!INFO]

这个历史版本只有 Git 标签与源码树，没有单独发布 GitHub Release。

发布亮点

  • 重构基础设施、节点、仓库、Patroni、PgBouncer、监控与 PostgreSQL 初始化角色。
  • 新增 etcd DCS、生产/测试清单布局与可配置数据库超级用户支持。
  • 增加 Patroni 暂停处理、HAProxy 2.2 适配及旧版 CentOS 7 修复。

v0.2.0 早于带有完整正文的 GitHub Release；本记录依据标签源码及其与 v0.1.0 的差异整理。

信息来源

1.26 - Pigsty v0.1.0

完成首轮角色化重构并通过仿真环境验证

[!INFO]

这个历史版本只有 Git 标签与源码树，没有单独发布 GitHub Release。

发布亮点

  • 完成首轮从剧本到可复用 Ansible 角色的大规模重构。
  • 建立 PostgreSQL 主从、PgBouncer、监控、HAProxy、Keepalived 与软件仓库的早期工作流。
  • 在生产仿真测试环境中验证重组后的项目结构。

v0.1.0 是早期工程里程碑，并非带有独立正文的 GitHub Release；本说明依据标签与提交历史整理。

信息来源

2 - 文章

从 VONNG 汇集的 Pigsty 观点、教程、实践记录与项目故事。

本栏目收录 VONNG 的 Pigsty 专栏全文，以及其他专栏中 front matter 明确带有 Pigsty 标签的文章；原始页面资源与已有英文译文一并保留。

2.1 - Pigsty v1.5：Docker应用支持，基础设施自监控

原文发布于 VONNG。

GitHub Release | 发布注记 | 微信公众号

Pigsty v1.5 正式发布！完整的 Docker 支持带来了丰富的应用生态，无数使用数据库的软件均可 开箱即用！

其他改进包括：基础设施自我监控、更好的冷备份支持、兼容 Redis 与 Greenplum 的新 CMDB、ETCD 作为高可用 DCS、更好的日志收集与呈现。Github Star 突破 500！

亮点特性

特性 说明
Docker 支持 管理节点默认启用，提供丰富的开箱即用软件模板
基础设施自监控 Nginx、ETCD、Consul、Prometheus、Grafana、Loki
CMDB 升级 支持 Redis/Greenplum 集群元数据，配置可视化
服务发现改进 Consul 自动发现监控对象，纳入 Prometheus
冷备份增强 默认定时备份任务，pg_probackup，一键延迟从库
ETCD 作为 DCS PostgreSQL/Patroni 的 Consul 备选方案
Redis 改进 支持单实例级别的初始化与移除操作

Docker 支持

Pigsty v1.5 中最重要的特性莫过于 Docker 支持。无数软件与工具都可以通过 Docker 方式开箱即用：开箱即用的数据库 + 开箱即用的应用 = 开箱即用的软件解决方案。

很多软件都需要用到数据库，但数据库放入容器中仍然是一个充满争议的话题。基于 Docker 镜像的玩具数据库与生产级数据库之间存在巨大差距。Pigsty 可以将两者的优势融合：有状态的数据库使用 Pigsty 管理，运行于标准的物理机或虚拟机上（如 PostgreSQL 与 Redis）；而无状态的应用使用 Docker 运行，这些应用的状态存储在 Pigsty 托管的外部数据库中。

在 Pigsty v1.4.1 中，Docker 作为实验特性被加入；在 v1.5 中，Docker 将作为 Pigsty 的默认组件，在管理节点上默认启用。普通节点默认关闭，但可以通过配置项在所有节点上启用 Docker。

应用生态

Docker 本身只是工具，重要的是 Docker 所代表的巨大 应用生态！

Pigsty 挑选了一些常用软件，特别是那些使用 PostgreSQL 与 Redis 的软件，制作了一键拉起的教程与快捷方式，并提供可以离线使用自动加载的镜像软件包 docker.tgz。

代码托管平台 Gitea

如果需要启动一个私有的代码托管服务，可以使用以下命令一键拉起 Gitea：

cd ~/pigsty/app/gitea; make up

该命令将使用 Docker Compose 配置文件拉起 Gitea 镜像，并使用外部 Pigsty 默认的 CMDB pg-meta.gitea 作为元数据存储。访问配置文件指定的域名或端口，即可访问自己的代码托管服务。

数据库管控平台 PgAdmin

PgAdmin4 是老牌的 PostgreSQL 管控工具，提供了很多实用功能。Pigsty 提供了最新的 6.9 版本 PgAdmin4 支持，只需一行命令即可启动镜像，并自动加载 Pigsty 中所有托管数据库实例列表。

cd ~/pigsty/app/pgadmin; make up; make conf

模式变更工具 Bytebase

Bytebase 是一款为 PostgreSQL 设计的模式变更管理工具，采用 Git 工作流、工单审批的方式来对数据库模式进行版本控制。Bytebase 本身的元数据也使用 PostgreSQL 存储。

cd ~/pigsty/app/bytebase; make up

网页客户端 PGWEB

有时用户想使用个人账号从生产数据库中小批量查询数据，这时基于浏览器的 PostgreSQL 客户端会很好用。PGWEB 可以部署在管理节点或专用堡垒机上，设置特定的 HBA 规则来允许个人用户查询生产只读实例。

cd ~/pigsty/app/pgweb; make up

对象存储 MinIO

对象存储是云厂商提供的基础服务，在私有部署条件下，可以使用 MinIO 快速搭建自己的对象存储。它可以用于存储文档、图像、视频、备份，自动进行冗余备份与容灾，并对外提供标准的 S3 兼容 API。

cd ~/pigsty/app/minio; make up

在 MinIO 的基础上，可以进一步使用 JuiceFS，将对象存储提供的大规模分布式存储转换为文件系统，供其他服务使用。

数据分析环境 Jupyter

Pigsty 提供了趁手的数据分析工具：Jupyter Lab，可以使用 Python 与 SQL 进行组合数据处理与分析。Jupyter Lab 默认并不是通过 Docker 启动，而是由管理节点受限的操作系统用户直接运行，以便于与数据库交互。

数据库模式报表 SchemaSPY

当需要生成某个数据库模式的详情报表时，可以使用 SchemaSPY：

bin/schemaspy 10.10.10.10 meta pigsty

数据库日志分析报表

当需要查阅数据库日志的汇总摘要信息时，可以使用 Pgbadger：

bin/pglog-summary 10.10.10.10

更多应用

此外，还有很多知名的软件应用都可以使用 Pigsty + Docker 一键拉起：

应用 说明
Gitlab 使用 PG 的开源代码托管平台
Habour 使用 PG 的开源镜像仓库
Jira 使用 PG 的开源项目管理平台
Confluence 使用 PG 的开源知识托管平台
Odoo 使用 PG 的开源 ERP
Mastodon 基于 PG 的社交网络
Discourse 基于 PG 与 Redis 的开源论坛
KeyCloak 开源 SSO 单点登录解决方案

更好的冷备份

数据故障大体可以分为两类：硬件故障/资源不足（坏盘/宕机）和 软件缺陷/人为错误（删库/删表）。基于主从复制的物理复制用于应对前者，延迟从库与冷备份通常用于应对后者。因为误删数据的操作会立刻被复制到从库上执行，所以热备份与温备份都无法解决诸如 DROP DATABASE、DROP TABLE 这样的错误，需要使用 冷备份 或 延迟从库。

在 Pigsty v1.5 中，对冷备份机制进行了改善：

  • 添加了定时任务机制，每天制作全量冷备份
  • 改善了延迟从库的创建机制，只需声明即可自动创建
  • 对于专家用户，提供了 pg_probackup 作为备份解决方案
  • 内置的 MinIO Docker 镜像将为后续的开箱即用异地灾备中心奠定基础

定时任务

Pigsty v1.5 支持为节点配置定时任务，包括追加与覆盖 /etc/crontab 两种模式。可以将制作基础物理冷备份、日志分析、模式转储、垃圾回收、分析统计任务以统一的、声明式的方式管理起来。

其中最重要的是默认在每天凌晨 1 点制作一个全量备份。加上 Pigsty 默认自带的最近一天 WAL 日志归档，可以将数据库恢复至 1 天内的任意状态，为软件缺陷、人为故障导致的删库删表提供了有力的兜底。

延迟从库

在 Pigsty v1.5 中，创建延迟从库不再需要手工执行 patronictl edit-config 调整集群配置，只需像下面这样声明，即可为集群创建一个延迟从库（集群）。

CMDB 兼容性改进

Pigsty 有一个可选的 CMDB，允许用元节点上的默认 PostgreSQL 数据库存储配置，而不是默认的配置文件 pigsty.yml。

Pigsty CMDB 最早于 0.8 版本引入，当时只是为了支持 PostgreSQL 而设计。当 Pigsty 开始支持 Redis、Greenplum 以及更多种类的数据库时，原有设计开始显得不合时宜。因此在 Pigsty v1.5 中，对 CMDB 进行了重新设计。

只要使用 bin/inventory_load 即可将当前使用的配置文件加载入 CMDB 中，使用 bin/inventory_cmdb 切换为 CMDB 模式。使用 CMDB 时，可以直接通过 Grafana 的 CMDB Overview 面板查阅可视化的配置清单：

可以从 CMDB Overview 中看到 PostgreSQL、Redis 以及 Greenplum/MatrixDB 集群的成员信息。

可以直接通过 SQL 来调整配置，也可以通过 PostgREST 暴露的 API 来调整配置，例如创建新的集群、扩容缩容等。

PostgREST 是一个自动根据 PostgreSQL 数据库模式生成 REST API 的二进制组件，打包在 Pigsty v1.5 自带的 Docker 镜像包中。

cd ~/pigsty/app/postgrest; make up

它还可以通过 Swagger OpenAPI Spec 自动生成 API 的定义，并使用 Swagger Editor 暴露 API 文档，生成不同编程语言的客户端存根。

PostgREST 不仅仅可以用来暴露 CMDB 的增删改查接口。如果已经有了一个设计得当的数据库模式，那么使用 PostgREST 可以立即构建出一个后端 REST API 服务，无需手工编写繁琐重复的增删改查逻辑，复杂的逻辑可以通过存储过程对外暴露。

如果需要更强大的 API 支持，可以考虑 API 网关 Kong。它可以让任何已有 API 变成功能完备的接口服务，为 API 启用多种认证签名机制，自动记录日志，设置 Trace，进行限流与容灾。Kong 基于 Nginx + Lua（OpenResty）实现，使用 PostgreSQL 与 Redis 存储元数据：

cd ~/pigsty/app/kong; make up

基础设施监控

在 Pigsty v1.5 中，基础设施本身的监控进行了重大改进：INFRA 和 NODES、PGSQL、REDIS 现在采用一样的管理模式。基础设施通过 infra_register 角色完成自身的服务注册，将自己添加到 Prometheus 的监控对象中。Grafana 中相应添加了监控面板。

Pigsty v1.5 的 Home 监控中，基础设施作为嫩绿色的组件，与 NODES、REDIS、PGSQL 采用同种方式列入 Instance 中。此外，Infra 服务也会注册至 Service Registry（Consul），并可通过服务发现自动管理。

INFRA Overview 提供了所有基础设施组件基本状态与快速导航

Prometheus Overview：时序数据库自监控

Grafana Overview：监控面板自监控

Loki Overview：日志收集组件自监控

ETCD 作为 DCS

在 Pigsty v1.5 中，可以使用 ETCD 作为 Consul 的替代，用于 PostgreSQL 数据库高可用所需的 DCS。

与 Consul 相比，ETCD 少了服务发现、内建 DNS、健康检查以及开箱即用的 UI，但是 ETCD 无需 Agent 部署简单，依托 Kubernetes 生态的流行度更高，比 Consul 少一个失效点，更好的指标可观测性。

只需指定 pg_dcs_type: etcd，即可使用 ETCD 作为 DCS。此外，可以同时使用 Consul 与 ETCD，两者并行不悖：例如使用 ETCD 作为 DCS，而使用 Consul 进行服务发现。

Pigsty v1.5 针对 ETCD 与 Consul 进行了开箱即用的监控面板：DCS Overview

目前 ETCD 作为 DCS 属于最小可用功能实现，并没有添加 CA 证书与 TLS 支持，将在后续版本安全性加固专项中补充。

更好的日志收集与呈现

在 Pigsty v1.5 中，默认为每一个上游服务启用单独的访问日志，所有字段均由 Loki 解析，可以直接进行分析。如果有网站挂在 Pigsty 上，可以立刻进行交互式日志流量分析与统计。

NGINX Overview：展示 Nginx 指标与日志

v1.5.0 发行注记

亮点概述

  • 完善的 Docker 支持：在管理节点上默认启用并提供诸多开箱即用的软件模板：bytebase, pgadmin, pgweb, postgrest, minio 等。
  • 基础设施自我监控：Nginx，ETCD，Consul，Prometheus，Grafana，Loki 自我监控
  • CMDB 升级：兼容性改善，支持 Redis 集群/Greenplum 集群元数据，配置文件可视化。
  • 服务发现改进：可以使用 Consul 自动发现所有待监控对象，并纳入 Prometheus 中。
  • 更好的冷备份支持：默认定时备份任务，添加 pg_probackup 备份工具，一键创建延时从库。
  • ETCD 现在可以用作 PostgreSQL/Patroni 的 DCS 服务，作为 Consul 的备选项。
  • Redis 剧本/角色改善：现在允许对单个 Redis 实例，而非整个 Redis 节点进行初始化与移除。

监控系统

监控面板

  • CMDB Overview：可视化 Pigsty CMDB Inventory。
  • DCS Overview：查阅 Consul 与 ETCD 集群的监控指标。
  • Nginx Overview：查阅 Pigsty Web 访问指标与访问日志。
  • Grafana Overview：Grafana 自我监控
  • Prometheus Overview：Prometheus 自我监控
  • INFRA Dashboard 进行重制，反映基础设施整体状态

监控架构

  • 现在允许使用 Consul 进行服务发现（当所有服务注册至 Consul 时）
  • 现在所有的 Infra 组件会启用自我监控，并通过 infra_register 角色注册至 Prometheus 与 Consul 中。
  • 指标收集器 pg_exporter 更新至 v0.5.0，添加新功能，scale 与 default，允许为指标指定一个倍乘因子，以及指定默认值。
  • pg_bgwriter, pg_wal, pg_query, pg_db, pgbouncer_stat 关于时间的指标，单位由默认的毫秒或微秒统一缩放至秒。
  • pg_table 中的相关计数器指标，现在配置有默认值 0，替代原有的 NaN。
  • pg_class 指标收集器默认移除，相关指标添加至 pg_table 与 pg_index 收集器中。
  • pg_table_size 指标收集器现在默认启用，默认设置有 300 秒的缓存时间。

部署方案

  • 新增可选软件包 docker.tgz，带有常用应用镜像：Pgadmin, Pgweb, Postgrest, ByteBase, Kong, Minio 等。
  • 新增角色 ETCD，可以在 DCS Servers 指定的节点上自动部署 ETCD 服务，并自动纳入监控。
  • 允许通过 pg_dcs_type 指定 PG 高可用使用的 DCS 服务，Consul（默认），ETCD（备选）
  • 允许通过 node_crontab 参数，为节点配置定时任务，例如数据库备份、VACUUM，统计收集等。
  • 新增了 pg_checksum 选项，启用时，数据库集群将启用数据校验和（此前只有 crit 模板默认启用）
  • 新增了 pg_delay 选项，当实例为 Standby Cluster Leader 时，此参数可以用于配置一个 延迟从库
  • 新增了软件包 pg_probackup，默认角色 replicator 现在默认赋予了备份相关函数所需的权限。
  • Redis 部署现在拆分为两个部分：Redis 节点与 Redis 实例，通过 redis_port 参数可以精确控制一个具体实例。
  • Loki 与 Promtail 现在使用 frpm 制作的 RPM 软件包进行安装。
  • DCS3 配置模板现在使用一个 3 节点的 pg-meta 集群，与一个单节点的延迟从库。

软件升级

  • 升级 PostgreSQL 至 14.3
  • 升级 Redis 至 6.2.7
  • 升级 PG Exporter 至 0.5.0
  • 升级 Consul 至 1.12.0
  • 升级 vip-manager 至 v1.0.2
  • 升级 Grafana 至 v8.5.2
  • 升级 Loki & Promtail 至 v2.5.0，使用 frpm 打包。

问题修复

  • 修复了 Loki 与 Promtail 默认配置文件名的问题
  • 修复了 Loki 与 Promtail 环境变量无法正确展开的问题
  • 对英文文档进行了一次完整的翻译与修缮，文档依赖的 JS 资源现在直接从本地获取，无需互联网访问。

API 变化

新参数

  • node_data_dir : 主要的数据挂载路径，如果不存在会被创建。
  • node_crontab_overwrite : 覆盖 /etc/crontab 而非追加内容。
  • node_crontab: 要被追加或覆盖的 node crontab 内容。
  • nameserver_enabled: 在这个基础设施节点上启用 nameserver 吗？
  • prometheus_enabled: 在这个基础设施节点上启用 prometheus 吗？
  • grafana_enabled: 在这个基础设施节点上启用 grafana 吗？
  • loki_enabled: 在这个基础设施节点上启用 loki 吗？
  • docker_enable: 在这个基础设施节点上启用 docker 吗？
  • consul_enable: 启用 consul 服务器/代理吗？
  • etcd_enable: 启用 etcd 服务器/客户端吗？
  • pg_checksum: 启用 pg 集群数据校验和吗？
  • pg_delay: 备份集群主库复制重放时的应用延迟。

参数重制

现在 *_clean 是布尔类型的参数，用于在初始化期间清除现有实例。

*_safeguard 也是布尔类型的参数，用于在执行任何剧本时，避免清除正在运行的实例。

  • pg_exists_action -> pg_clean
  • pg_disable_purge -> pg_safeguard
  • dcs_exists_action -> dcs_clean
  • dcs_disable_purge -> dcs_safeguard

参数重命名

  • node_ntp_config -> node_ntp_enabled
  • node_admin_setup -> node_admin_enabled
  • node_admin_pks -> node_admin_pk_list
  • node_dns_hosts -> node_etc_hosts_default
  • node_dns_hosts_extra -> node_etc_hosts
  • node_dns_server -> node_dns_method
  • node_local_repo_url -> node_repo_local_urls
  • node_packages -> node_packages_default
  • node_extra_packages -> node_packages
  • node_packages_meta -> node_packages_meta
  • node_meta_pip_install -> node_packages_meta_pip
  • node_sysctl_params -> node_tune_params
  • app_list -> nginx_indexes
  • grafana_plugin -> grafana_plugin_method
  • grafana_cache -> grafana_plugin_cache
  • grafana_plugins -> grafana_plugin_list
  • grafana_git_plugin_git -> grafana_plugin_git
  • haproxy_admin_auth_enabled -> haproxy_auth_enabled
  • pg_shared_libraries -> pg_libs
  • dcs_type -> pg_dcs_type

v1.5.1 发行注记

亮点

重要：修复了 PG14.0-14.3 中 CREATE INDEX|REINDEX CONCURRENTLY 可能导致索引数据损坏的问题。

Pigsty v1.5.1 升级默认 PostgreSQL 版本至 14.4，强烈建议尽快更新。

软件升级

  • postgres 升级至 14.4
  • haproxy 升级至 2.6.0
  • grafana 升级至 9.0.0
  • prometheus 升级至 2.36.0
  • patroni 升级至 2.1.4

问题修复

  • 修复了 pgsql-migration.yml 中的 TYPO
  • 移除了 HAProxy 配置文件中的 PID 配置项
  • 移除了默认软件包中的 i686 软件包
  • 默认启用所有 Systemd Redis Service
  • 默认启用所有 Systemd Patroni Service

API 变更

  • grafana_database 与 grafana_pgurl 被标记为过时 API，将从后续版本移除

新增应用

  • wiki.js：使用 Postgres 搭建本地维基百科
  • FerretDB：使用 Postgres 提供 MongoDB API

2.2 - Pigsty是什么？

原文发布于 VONNG。

在介绍 Pigsty 前，我们必须要先说一说PostgreSQL！

PG 是世界上最先进的开源关系型数据库

图片图片图片图片图片

PG 是一个足够完美的内核，一颗强劲的引擎。

但用户要的 并不是发动机，而是 开门即走 的整车！

图片

Pigsty 要做的就是这辆车：

开箱即用，物美价廉，自动驾驶，数据库界的 TESLA！

图片

Pigsty，让天下没有难用的数据库！

图片

PostgreSQL 数据库发行版

RedHat for Linux！开箱即用！从无到有，让用户用得上！

Pigsty 将高可用集群部署，扩容缩容，主从复制，故障切换，流量代理，连接池，服务发现，访问控制，监控系统，告警系统，日志采集等生产级成熟解决方案封装为发行版。一次性解决在生产环境与各类场景下使用 世界上最先进的开源关系型数据库 —— PostgreSQL 时会遇到的各种问题，真正做到开箱即用。

Pigsty 深度整合最新 PostgreSQL 内核 (14) 与强力扩展：时序数据 TimescaleDB 2.6，地理空间 PostGIS 3.2，分布式 Citus 10，及上百+海量扩展插件，全部开箱即用。

图片图片

Pigsty 打包了大规模生产环境所需的基础设施：Grafana，Prometheus，Loki，Ansible，Consul，Docker 等，亦可作为部署监控其他数据库与应用的运行时/PaaS。

图片

Pigsty 集成了数据分析生态的常用工具：Jupyter，ECharts，Grafana，PostgREST，Postgres，可作为数据分析环境，或低代码数据可视化应用开发平台。

智能监控管控运维解决方案

Auto-Pilot for Postgres！自动驾驶！从有到优，让用户用的爽！

Pigsty 带有一个无可比拟的数据库监控系统，通过 30+精心设计组织的监控面板呈现超 1200 类指标，从全局概览到单个库内对象一览无余，提供终极的可观测性！

图片

Pigsty 提供高可用的 PostgreSQL 数据库集群，任意成员存活即可正常对外提供服务；各实例幂等，提供类分布式数据库的体验；故障自愈，极大简化运维工作！

图片

Pigsty 支持部署不同种类的数据库集群与实例：经典 PGSQL 主从复制集群/灾备集群，同步/延迟/离线/级联实例，Citus/Greenplum 集群，Redis 主从/哨兵/原生集群。\

图片

数据库即代码开发者工具箱

HashiCorp for Database！简单易用！从优到易，让用户省心！

Pigsty 秉持 Infra as Data 的设计理念，用户只需用几行声明式的配置文件描述自己想要的数据库，即可使用幂等剧本，一键将其创建。Just like Kubernetes！

图片

Pigsty 向开发者交付简单易用的数据库工具箱：一键下载安装，自动配置；一键部署各类开源数据库，一键迁移备份、扩容缩容，极大拉低数据库管理使用门槛，量产 DBA！

图片

Pigsty 能够简化数据库部署与交付、解决环境配置统一的难题：无论是上千套数据库几万核的生产环境，还是本地 1C1G 的笔记本均可完整运行；基于 Vagrant 的本地沙箱与基于 Terraform 的多云部署，云上云下，一键拉起！

图片

开源云数据库 PaaS 替代方案

Alternative for RDS！安全可控，降本增效！从易到廉，给用户省钱！

Pigsty 相比云厂商 RDS，在拥有更低使用⻔槛与更丰富功能的前提下，可节约 50% - 80% 的数据库软硬件成本，初级研发人员即可自主管理成百上千套数据库。

图片

Pigsty 采用模块化设计，可自由组合，按需定制扩展。可在生产环境部署管理各种数据库，或仅仅将其当成主机监控；可用于开发数据库可视化 Demo、或支撑各类 SaaS 应用。

图片

Pigsty 是开源免费的生产级数据库解决方案，用于补全云原生生态缺失的最后一块拼图。稳定可靠，经过长时间大规模生产部署验证，提供可选的专业技术支持服务。

自动驾驶高可用

以 PostgreSQL 为例，Pigsty 创建的数据库集群是分布式、高可用的数据库集群。只要集群中有任意实例存活，集群就可以对外提供完整的读写服务与只读服务。

Pigsty 的高可用架构久经生产环境考验，Pigsty 使用 Patroni + Consul 进行故障检测、Fencing 与自动故障切换，通过 HAProxy、VIP 或 DNS 实现流量的自动切换，以极低的复杂度代价实现了完整的高可用方案，让主从架构的数据库能用出了布式数据库般的体验。

数据库集群可以自动进行故障检测与主从切换，普通故障能在几秒到几十秒内自愈：主库故障 RTO < 1min，只读流量几乎无影响，同步集群 RPO = 0 不丢数据。

数据库集群中的每个数据库实例在使用上都是幂等的，任意实例都可以通过内建负载均衡组件 HAProxy 提供完整的读写服务。任何一个或多个 Haproxy 实例都可以作为集群的负载均衡器，并通过健康检查进行流量分发，对外屏蔽集群成员的区别。用户可以通过配置灵活定义服务，并通过多种可选方式接入。

图片

极致入微可观测\

You can’t manage you don’t measure.

监控系统提供了对系统状态的度量，是运维管理工作的基石。

【公开 Demo：http://demo.pigsty.cc】

Pigsty 带有一个针对大规模数据库集群管理而设计的专业级监控系统，基于业内最佳实践，采用 Prometheus、Alertmanager、Grafana、Loki 作为监控基础设施。开源开放，定制便利，可复用，可移植，没有厂商锁定。

Pigsty 在 PostgreSQL 监控上做到无可比拟，通过 30+监控面板与上千仪表盘综合呈现约 1200+类指标，覆盖从全局大盘到单个对象的详细信息，从数据库目录到节点日志全部一览无遗。与同类产品相比在指标的覆盖率与监控面板丰富程度上一骑绝尘，为专业用户提供无可替代的价值。详略得当的层次设计，为业余用户带来直观便捷的管理体验。

Pigsty 的监控系统可用于监控原生部署的各类数据库实例：PGSQL，REDIS，GPSQL 等，也可以独立使用，监控已有的数据库实例或远端云厂商 RDS，或仅仅作为主机监控使用，它还可以用作数据可视化作品的展示平台。

图片

简单易用门槛低

HashiCorp for Database!

Pigsty 采纳 Database as Data 的设计哲学，使用类似 Kubernetes 的声明式配置，通过大量可选的配置选项对数据库与运行环境进行描述，并通过幂等的预置剧本自动创建所需的数据库集群，提供私有云般的使用体验。

用户只需要通过配置文件或图形界面描述“自己想要什么样的数据库”，而无需关心 Pigsty 如何去创建或修改它。Pigsty 会根据用户的配置文件清单，在几分钟内从裸机节点上创造出所需的数据库集群。

例如，在三台机器上创建一主两从的数据库集群pg-test，只需要几行配置与一行命令即可创建出高可用数据库集群。

图片

自由部署体验齐

无论是几万核的生产环境，还是 1 核 2G 的本地虚拟机，云上云下，用哪个云，体验如一！

无论是几万核的生产环境、预发环境、还是本地 1 核 2GB 虚拟机的开发测试环境，对 Pigsty 来说，只有配置文件的内容差异。无论在哪里部署，都能带来统一的使用体验。

Pigsty 可以利用Vagrant与Virtualbox，在您自己的笔记本电脑上拉起安装所需的虚拟机沙箱环境，或通过 Terraform，自动向云服务商申请 ECS/VPC 资源，一键创建，一键销毁，自动获取多云部署的能力。

图片

应用广泛生态全\

一键拉起生产级 SaaS 应用，数据分析快速上手，低代码开发可视化大屏

SaaS 软件应用

Pigsty 在元节点上默认安装了 Docker，您可以一键拉起各类 SaaS 应用：开源私有代码托管平台 Gitlab，开源论坛 Discourse，开源社交网络 Mastodon，开源 ERP 软件 Odoo，以及用友、金蝶等软件。您可以使用 Docker 拉起无状态的部分，修改其数据库连接串使用外部数据库，获取丝滑的云原生管理体验与生产级的数据持久性。详情请参考 教程:Docker 应用。

图片

数据分析与可视化应用\

Pigsty 既是开箱即用的 PostgreSQL 发行版，也可以用做数据分析环境，或制作低代码的可视化应用。您可以直接从 SQL 数据处理到 Echarts 绘图一步到位，也可以使用更精细的工作流：例如使用 PG 作为主数据库，存储数据并用 SQL 实现业务逻辑；使用内置的 PostgREST 自动生成后端 API，使用内置的 JupyterLab 用 Python 进行复杂数据分析，并使用 Echarts 进行数据可视化，并通过 Grafana 获得交互能力。

图片

Pigsty 自带有几个应用样例作为参考：\

  • 分析 PG CSV 日志样本pglog

  • 新冠疫情数据可视化 covid

  • 全球地表气象站数据查询 isd

  • 数据库流行度排行趋势 dbeng

  • 查询大厂工作上下班安排 worktime

自主可控更省钱

Pigsty 可将数据库的综合持有成本降低 50% ～ 80%，

并让数据真正掌控在用户自己的手中！

公有云数据库/RDS，也是一种“开箱即用"的解决方案，但它交出的答卷离让用户满意还有很长路要走：相比自建数据库成本昂贵，许多需要超级用户权限的功能被阉割，愚笨的 UI 与大锅饭式的功能，但在所有问题中，最重要的问题莫过于云软件的安全与成本问题：

自主可控

  • 运行在你自己的电脑上的软件，即使软件供应商倒闭也可以继续运行下去。但如果提供云软件的公司/部门倒闭或决定停止支持，这些软件就没法工作了，而你用这些软件创造的数据就被锁死了。因为数据只存储在云端，而不是你自己服务器的磁盘上，而您能指望的补偿通常只有鸡肋的代金券。

  • 无法定制或扩展的问题在云数据库中进一步加剧。云数据库通常不向用户提供数据库超级用户，这将锁死一大批高级功能，以及自行加装扩展功能的能力。与此相对应，‘流复制’，‘高可用’这些本该是数据库标配的东西往往作为增值项向用户出售。

  • 云服务可能在没有警告和追索手段的情况下突然暂停你的账户。您可能在完全无辜的情况下，被自动化系统判定为违反服务条款：未备案使用 80 与 53 端口，账户被爆破并用于发送恶意软件或钓鱼邮件，触发违背服务条款。或因为一些政治原因被云厂商锤翻，例如 Parler。

  • 国内不用 SaaS 坚持自研或开源自建的习惯，是被恶劣的生态产业环境真金白银教育出来的。在信息时代把核心资产 — 数据放在别人的硬盘上，就像把金条放在超市存包柜中一样。您无法避免，无法监督、甚至无法意识到利益冲突的云厂商，或者仅仅是怀有恶意或好奇的运维与 DBA 人员偷窥盗窃您的珍贵数据。

Pigsty 则不然，它可以部署在任意地方，包括您自己的服务器上。它开源免费，无需 License，无需互联网访问，不收集任何用户数据。您可以在自己的服务器运行它直到海枯石烂。

降本增效

云数据库的成本则是另一个问题：省钱是用户的刚需。公有云厂商的 RDS 相比传统商业数据库也许有优势，但在自建开源数据库前仍然是暴利天价。据统计，RDS 的综合持有成本比起基于云服务器自建要高达 2~3 倍，比起 IDC 托管自建更是高出 5～10 倍。

图片

Pigsty 相比使用云数据库有显著成本优势。例如，您可以使用云数据库一半的开销购买同规格的云服务器，并使用 Pigsty 自行部署数据库。在这种情况下，您既可以享受公有云的绝大部分管理之快捷便利（IaaS），又可以立竿见影节省一半以上的开销。\

更重要的是，Pigsty 能显著提高用户效能：它允许一两个高级 DBA 将所有琐碎杂物交由软件处理，轻松管理几百套数据库集群；也可以让一个初级研发人员，经过简单的学习培训后，即可迅速达到一个高级 DBA 的廉价七成正确水平。

Pigsty 开源免费，在提供类似甚至超过云厂商 RDS 使用体验的前提下，可将数据库的综合持有成本降低 50% ～ 80%，并让数据真正掌控在用户自己的手中！

云原生运动的最后一块拼图

软件吞噬世界，开源吞噬软件，云吞噬开源；而吃掉云的，还得看云原生与多云部署。

图片

**云原生（Cloud Native，或曰“本地云”）**是一场从公有云厂商夺回软件自由的伟大运动。然而其图景中还缺少最后一块拼图 —— 数据库。

图片

将数据库稳定可靠地放入 Kubernetes/容器中仍然是一个业界难题，即使是云厂商，也仍然在大量使用物理机与虚拟机部署管理数据库。而很多的用户，因为没有数据库的运维能力，不得不使用公有云/RDS 来补足这个短板，进而不得不把自己的业务跑在云上。

图片

而 Pigsty 将会带来改变：用云服务器的牛，耕云数据库的田，享受绝大多数灵活性的同时立省一半开销；若是使用 IDC 托管/自建机房，综合持有成本省掉百分之八十都打不住！

Pigsty，要把 DB 的使用门槛压到地板，我们要把软件自由交还用户：让天下没有难用的数据库，谢谢！

图片图片

发布版本：微信公众号

2.3 - PG与Pigsty用户需求问卷调研结果

原文发布于 VONNG。

上周，我们进行了一次题为 PostgreSQL 与 Pigsty 用户需求调研的问卷调查。主要希望对用户的数据库需求进行了解，两天时间共收集有 77 份有效问卷。

本次问卷调查基于 PostgreSQL 社区 与 Pigsty 社区用户群体，通过微信公众号与群组进行发放。部分结果可能存在 Bias，但足以真实反映用户满意度与整体用户需求。

基本情况

此次接受调研的用户群体中，DBA 占近半数，DBA 与运维共计占 71%，应用研发次之，占 17%。

图片图片

其中，近半数参与调研者与数据库打交道的时间在 5-10 年范围内，90% 以上的受访者有两年以上相关工作经验。\

图片图片

其中，超过 30% 受访者的公司有着较大规模：超过 10 人以上的数据库专职团队与 200+数据库实例。

图片图片

在数据量上，超过半数的公司的业务数据量坐落于几百 GB 到几 TB 的数量级。

1TB 内占比 36%，1TB-1PB 占比 56%，PB 以上占比 7%。

图片图片

数据库使用情况

在数据库的使用上，PostgreSQL 占比最高，达到 90%，当然有一部分因素是调研对象是 PostgreSQL 社区/Pigsty 社区。此外，使用 MySQL 与 Redis 的用户并列第二，达到 70%。Oracle 排第四位占比 60%。MongoDB 与 Kafka 也分别有 43% 与 36% 的采用率，位列第五第六。“其他”选项中包括 IBM DB2，Starrocks，ElasticSearch，InfluxDB 等。

图片图片

数据库管理工具

在受访群体中，60% 的用户倾向于使用开源的数据库发行版来满足数据库管控的需求。倾向于购买云数据库的用户占比为 20%，使用商业数据库或商业管控软件的用户占比约为 10%。（注：本题可能因调研用户群体而产生 Bias）

图片

最需要的数据库相关功能

用户将选出自己最看重的五项 数据库相关 能力，其中，高可用与监控系统是用户最为强烈的需求，一键安装/CLI/GUI 的需求次之。流量分发、接入、负载均衡、数据分析、扩展插件基本位于第三梯队。

图片图片

Pigsty 相关

Pigsty 是开箱即用的 PostgreSQL 数据库发行版。在参与调查的 77 人中，有 70 人听说过 Pigsty，在 70 人中，有 40 人使用过 Pigsty。在使用 Pigsty 的 40 人里，NPS 分数为 80%。

图片图片图片

NPS 分数

NPS（Net Promoter Score），净推荐值，又称净促进者得分，亦可称口碑，是一种计量某个客户将会向其他人推荐某个企业或服务可能性的指数，它是最流行的用户满意度分析指标。

图片

NPS 的计算方式为，询问用户有多大可能性向朋友或同事推荐此产品，然后用推荐者比例（9,10 分）减去 - 贬损者比例（0-6 分）。

在 Pigsty 的 40 位用户中，有 83% 的用户给出了积极评价（9 分与 10 分），6 位用户给出了中性评价（7，8），1 位用户给出了 5 分，净推荐指数为 80%，是一个相当惊人的值。

图片

80% 的 NPS 是一个相当惊人的值，作为参考，软件行业的平均 NPS 大致在 31%。

图片图片

常见行业 NPS 均值报告，软件业均值为 31%

非常感谢各位填写问卷的朋友，参与问卷调查的用户如果留有收件地址，将会有一份随机小礼品发送，不过因为疫情原因还在定制中，将在问卷调查结束/寄到后统一发放。

图片图片

贴纸，两种胸针随机发送～

顺便一提，最近 Pigsty 进行了一次路演预演，在五十多个创业项目（从全球 5600 个项目初筛）中排名并列第二。以下是预演视频删减录像。

嵌入媒体

最后，添加 Pigsty 小助手，加入 Pigsty 群组！

图片

发布版本：微信公众号

2.4 - Pigsty v1.4：模块化架构，MatrixDB数据仓库支持

原文发布于 VONNG。

Pigsty v1.4 正式发布啦！全新的模块化架构：四大内置模块 INFRA，NODES，PGSQL，REDIS 可以独立使用并自由组合；新增时序数据仓库 MatrixDB 部署与监控支持；新建设了全球 CDN 加速下载；此外，Pigsty 完成种子轮融资，产品定位与战略进行重大升级，我也全职出来投入到此项目中。请系好安全带，老司机要加速发车啦！

图片

Github Star 指数增长，开始！

图片

模块化架构\

如果要我说 Pigsty v1.4 最给力的特性是什么，我认为是对底层架构的重大重构，尽管听上去比较枯燥，但这一点确实很重要。

在 1.4 中，整个系统解耦成 4 个独立的模块，可以独立维护，自由排列组合使用。**INFRA是 Pigsty 的基础设施部分，包括监控/告警/可视化/日志/DNS/NTP 等公共组件。NODES是主机节点管理模块，PGSQL是 PostgreSQL 数据库部署管控模块，REDIS**是 Redis 数据库部署管控模块。

图片

全新的 Pigsty v1.4 监控首页

如果您想将 Pigsty 当作单机的开箱即用的 PostgreSQL 发行版来使用，那么在一台机器上依次安装 INFRA,NODES,PGSQL 三个模块，就会有一个立即可用的，自我监控管理的数据库实例。

如果您想要一个生产环境的大规模主机监控系统，那么在一台机器上安装INFRA模块，在所有被监控的机器节点上安装NODES模块即可。所有的主机节点会配置有软件源，软件包，DNS，NTP，节点监控，日志收集，DCS Agent 这些生产环境所需的组件。纳入 Pigsty 管理的主机会带有详细的监控信息，并可以用于进一步部署各式各样的数据库模块。

如果您想部署管理大量的 PostgreSQL 集群，很简单，在这些纳入 Pigsty 管理的节点上再加装 PGSQL模块即可。您可以一键部署各种各样的 PGSQL 集群：单实例，一主 N 从的高可用集群，同步集群，法定人数提交的同步集群，带有离线 ETL 角色的集群，异地容灾的备集群，延迟复制集群，Citus 分布式集群，TimescaleDB 集群，MatrixDB 数据仓库集群。

如果你想部署并监控管理很多 Redis 集群，也很简单。只要在 Pigsty 托管的节点上加装REDIS模块即可。而且后续添加新类型的数据库也更加容易了：KAFKA,MINIO,MYSQL，…… 这些模块都可以用一种类似的方式加入到 Pigsty 中。一个成功的开源项目离不开开发者的贡献，而简洁优雅的架构，可以极大降低贡献的门槛。

Pigsty 1.4 在模块化上进行了大量的工作。无论是配置项，命名空间，剧本，标签，监控面板，全部按照这四个模块进行分类统筹。例如，下面是按照模块划分的剧本与配置项：

图片

模块化后的剧本与配置参数

全新数据库支持

PostgreSQL 是一个相当全能、相当完美的数据库内核了，但正所谓：红花还需绿叶配，一个好汉三个帮。当组织与数据成长到一定规模后，使用专有数据组件的需求也会随之出现。最典型的两类是：以 Redis 为代表的缓存，以及以 Greenplum 为代表的数据仓库。

图片

Redis 可以进一步强化业务系统的 OLTP 处理能力，分担数据库压力，模型简单易用，受到广受开发者的喜爱。而 Greenplum 则可以显著强化业务系统的 OLAP 能力，采用与 PostgreSQL 一致的语言、驱动与接口，将数据分析的量级从几十 TB 提升到 PB 乃至 ZB 的级别。

图片

Redis 与 Greenplum 在两个方向上扩展了 PostgreSQL 的能力边界，这两者都是 PostgreSQL 的拍档，经常在一起组合使用。因此，Pigsty 在 v1.4 中提供了对 Redis 与 Greenplum 的初步支持。

图片

Redis Overview 面版

不过，Pigsty 支持的并不是原生的 Greenplum，而是它的一个分支：MatrixDB。Greenplum 的正式版本目前仍然是 6.x，基于 PostgreSQL 9.6 内核，有些太老了。而 MatrixDB 则基于 Greenplum 7 和 PostgreSQL 12 内核，还有额外的时序功能支持。因此 Pigsty 目前使用 MatrixDB 作为 Greenplum 的替代实现。

Pigsty v1.4 最得意的一点在于，并没有一个专门的 MATRIXDB 模块，MatrixDB 的部署完全复用了PGSQL 模块。您可以用熟悉的配置参数来配置 MatrixDB。在 Pigsty 看来，一套 MatrixDB 数据仓库在逻辑上就是 N 对标准的一主一从 PGSQL 集群：一个标准的 Master 集群（Master & Standby），以及很多组散布在多个节点上的 Segment 集群（Primary & Mirror）。所有 PGSQL 的面板都可以直接用在 MatrixDB 上。

图片

PGSQL MatrixDB 面版

专用的 Dashboard：PGSQL Matrix 用于展示一套 MatrixDB 的核心监控指标，其他监控面板均复用已有的 PGSQL 面板。

图片

定义上面的 4 节点 MatrixDB 只需要这些配置

监控系统演进

监控系统一直以来在 Pigsty 中扮演着核心角色。在 1.4 中，Pigsty 的监控系统也有着很显著的改进。

主机监控

Pigsty v1.4 引入了一个全新的功能：节点监控，这也是模块化改造的一个直接成果。这并不是说以前 Pigsty 没有关于机器节点的监控指标，而是在以前，机器的监控指标是 1:1 与 PostgreSQL 实例绑定的。对于一个 PostgreSQL 数据库发行版来说，这样的设计是没有问题的。但随着 Pigsty 的发展，这样的设计就开始显得不合时宜了。

图片

NODES Overview 面板，提供所有节点的导航

用户可能有各种各样的使用方式与部署策略，例如，在一个节点上部署多个数据库实例，甚至部署多种不同类型的数据库。在这种情况下，合适的做法是把节点的管理与监控单独抽离出来，不与具体的数据库类型绑定。

这样做有两个显著的好处：一是如果用户不需要数据库监控与管理，只需要节点的监控与管理，那么会比以前简单很多；第二是一个节点上可以部署多个甚至多种数据库，并复用同样的节点监控指标数据。任何时候，您只要点击 IP 地址，就可以跳转到具体的 NODES Instance，查看该节点的详情。

图片

曾经的 PGSQL Node 现在变为 NODES Instance

节点监控提供了全局概览，集群，以及单个节点三种不同的层次。节点的集群可以配置为默认与 PostgreSQL 数据库集群保持一致，也可以有独立的身份配置。方便您从不同的角度来透视集群资源。

图片

新增的 Nodes Cluster 面板，关注一组节点的聚合指标与集群内的水平对比

虽然 Pigsty 的定位是开箱即用的 PostgreSQL 发行版，但其中也包含着主机监控的最佳实践。有些用户根本不 care 数据库，只是拿 Pigsty 做主机监控…。

日志收集

在 Pigsty 1.4 中，Loki 与 Promtail 日志收集组件升级为整个系统的默认组件。Loki 是 Grafana 出品的日志收集方案，采用与 Prometheus 类似的标签体系，与 PromQL 类似的 LogQL。是一个轻量化，优雅简洁的日志收集、处理、分析解决方案。经过了一年时间的测试与打磨，现在 Loki 已经成为了 Pigsty 的默认组成部分。会实时收集各式各样的日志：节点的 syslog，dmesg，cron 日志，数据库 postgres/pgbouncer/patroni 的日志，以及 Redis 日志。

图片

INFRA 板块的 LOGS Instance 监控面板，可以实时浏览搜索所有日志。

ELK 对于 SRE 的日志需求过重，其实大家想要的就是一个高效快速的大规模并行 GREP，Loki 在这件事上干的很出色。\

此外，除了节点日志，您也可以从新的 INFRA Overview 面板，查阅基础设施产生的实时日志数据。

图片

INFRA 板块的 Overview 面板，可以看到基础设施的各项日志

PGSQL 监控

Pigsty v1.4 提供了对新数据库种类的监控支持，但对于经典的 PostgreSQL 监控也没有落下。在 1.4 中，大量 PGSQL 的监控面板进行了调整与重置，最具有代表性的就是 PGSQL Cluster 面板。

图片

全新的 PGSQL Cluster 监控面板首屏

PGSQL Cluster 是 Pigsty 数据库监控中最核心的监控面板之一，承上启下，用于呈现一个自治数据库集群的关键状态。新的设计隐藏了不必要的信息，聚焦于集群资源。您可以从首屏快速点击集群内的资源对象，前往细分的监控面板：包括节点，实例，负载均衡器，服务，数据库，服务组件。

除了集群资源对象，PGSQL Cluster 的首屏只呈现最关键的监控指标，报警事件，集群/实例压力水位。其他细节都隐藏在下面的专题栏中。

图片

成员详情表在默认隐藏的第二栏中

第二个显著改进是新增的 PGSQL Databases 面板。在过去，数据库内监控只关注单个实例内的单个对象。但对于表、索引这样的业务对象，我们更关注的是它们在整个集群内的整体指标。PGSQL Databases 面板为此而生。您可以查询某一个数据库在整个集群内的表现，水平对比集群间不同实例的差异：

图片

PGSQL Databases 面板：agg(metrics{datname=*}) by (ins)

更重要的是，您可以看到每一张表，每一类查询在集群范围内的汇总视图。例如，您可以查阅一张表或一类查询在集群主库与从库实例上的 QPS，或者确认某一个索引在集群不同实例上的使用情况，从而对业务与应用进行有针对性的优化。

图片

库内对象在集群层面的汇总展示：Tables & Queries，点击下钻。

带颜色的 TreeMap 可以快速反映出两个维度的属性：对于表而言，大小代表表占用的空间，颜色代表表被访问的频次。对于查询而言，大小代表在此查询上耗费的总时长，颜色代表该类查询的平均响应时间。

应用面版

除了INFRA，NODES，PGSQL，REDIS四个核心模块外，Pigsty Grafana 的首页还有一个板块：APP。这是留给用户自己的应用的。任何带有**APP和Overview**标签的监控面版会被列入 Pigsty 的面版导航中。Pigsty 自带了一个开箱即用的小应用 PGLOG，用来分析 PG 自身的 CSV 日志，您可以快速从日志中定位异常，并快速定位跳转到具体连接的详情页。

图片

PGLOG Overview，使用快捷方式快速将日志灌入应用表中分析。

此外，Pigsty 还建立一个专用的代码仓库：Vonng/pigsty-app，用于盛放 Pigsty 样例应用：https://github.com/Vonng/pigsty-app。目前的应用包括：

  • ISD：NOAA 全球地表气象站历史天气数据查询

  • COVID：WHO 新冠疫情数据查询

  • DBENG：DB-Engine 数据库流行度趋势与预测

  • APPLOG：Apple 应用隐私日志可视化

  • WORKTIME：国内大公司上下班时间查询

后续将不断添加更多数据应用的样例。

图片

DBEng Trend：使用权威网站 DBEngine 流行度趋势数据，预测 PostgreSQL 什么时候会成为世界上最流行的关系型数据库。

安装体验优化/CDN

此前 Pigsty 使用 Github 作为发布平台，中国大陆访问起来还是比较吃力的。经常需要从百度网盘镜像下载，再手工拷贝到服务器上去。用户的体验就是我们的追求，所以我们又启用了全球 CDN 加速域名 http://download.pigsty.cc，朗朗上口，非常好记。例如最新的软件源码包与离线软件包的下载地址分别为：http://download.pigsty.cc/v1.4.0/pigsty.tgz （2MB）http://download.pigsty.cc/v1.4.0/pkg.tgz（940MB）

Pigsty 的软件包进行了一次重新梳理与瘦身，从原本的 1.3GB 压缩至 v1.4 的 940MB。需要安装 Greenplum 与 MatrixDB 的用户，单独下载另一个离线软件包 matrix.tgz （338MB）即可。

一键安装是 Pigsty 的光荣传统。尽管如此，下载一直以来都是最最不让人省心的地方。因此在 Pigsty v1.4 中提供了专用的下载脚本**download，可用于自动下载并解压可选的软件包pkg.tgz，matrix.tgz，app.tgz**。这个脚本会自动检测您的网络环境是不是在墙内，如果在墙外使用默认的 Github Releaes，在墙内则使用腾讯云 CDN 下载。

当然，download本身也是 pigsty 源码包的一部分，因此我们还提供了一条类似homebrew 的一键安装命令，用来一键下载最新的 pigsty 源码包。于是，现在安装 Pigsty 的流程如下所示了：

bash -c "$(curl -fsSL http://download.pigsty.cc/get)" # 下载
./download pkg matrix app   # 下载并解压可选的扩展软件包（可选步骤）
cd ~/pigsty && ./configure  # 配置
make install                # 安装

典型用户案例

探探是 Pigsty 最大的用户案例，也始终是第一个吃螃蟹的人。2022 年 3 月份，探探下线了最后一套遗留的旧 PostgreSQL 数据库 pg.meta.tt，生产环境所有数据库均已迁移至 Pigsty，一百套集群全部由 Pigsty v1.3.1 所托管（监控系统版本为 1.4）。所有集群的高可用自动切换也已经启用，历时近两年的数据库飞升项目正式宣告完工。

图片

探探主生产环境的 Pigsty 部署：240 实例 13400 核的 PostgreSQL OLTP 集群。

在探探，Pigsty 经过了长时间，大规模，高强度，惨无人道的实际生产环境测试。在两年的时间里不断打磨完善，最终演变为今天的样子。在近日的混沌工程演练中，运维随机挑选数据库机器进行多次宕机演练，Pigsty 在无人值守的情况下可以自动进行高可用主从/流量切换。从库宕机无业务影响，主库宕机对业务写入影响不超过在 1 分钟。

图片

一次典型从库宕机现场，读流量迅速由主库承担，业务只有极个别现场查询中断报错，而后立即恢复。

图片

一次典型主库宕机现场。主库宕机 30s 后，从库被提升新主库，影响 30s 业务写入请求后自愈。

潜在合作伙伴

一个篱笆三个桩，一个好汉三个帮。想要做大事，首先要确定的一点就是，谁是我们的敌人，谁是我们的朋友。Pigsty 定位了两个潜在的合作伙伴 Sealos，Bytebase，准备进行进一步接触。

Sealos 是一个很有趣的开源项目，可以把整个运行中的 K8s 集群打成镜像，然后一键部署到其他地方，Pigsty 和 Sealos 很互补：很多 SaaS 都是 DB + App 的方式。有了一个开箱即用的数据库，就差一个开箱即用的应用生态了，把 SaaS 软件丢进 K8s 里整体打成镜像，交付什么 Gitlab，Jira，Confluence，Odoo，Habour，金蝶啥的就很简单了，拉起来填个数据库连接串全部搞定。

另一个我比较关注的项目是ByteBase，这是一个做数据库 Schema Migration 的工具。用 Go 开发清清爽爽无依赖，使用 PostgreSQL 作为后端数据库，又可以用来做 PostgreSQL 的模式变更管理。那确实是极好的，Pigsty 可以用来做ByteBase的 Backend Database，ByteBase也可以作为 Pigsty 的 Migrator，预计在下个版本中会添加一个对 ByteBase 基本的集成与支持。

产品定位转换

Pigsty，是 Postgres in Graph STYle 的缩写，即图形化 PostgreSQL 的意思，在最初，它是一个针对 PostgreSQL 开发的专业监控系统。后来，随着各种各样功能的引入（声明式定义，一键部署，高可用 PG，自动流量切换，数据分析与可视化组件），Pigsty 在 1.0 的时候，定位调整为“开箱即用的 PostgreSQL 数据库发行版”。而现在，Pigsty v1.3 提供了 Redis 部署监控的支持，1.4 又引入了时序数据仓库 MatrixDB 监控部署支持。单一的PG 发行版 定位已经限制了 Pigsty 的想象力与可能性。

开箱即用的发行版

RedHat for Linux

  • Pigsty 打包最新 PostgreSQL 内核（14），集成强力的地理空间插件 PostGIS3.2，时序数据库插件 TimescaleDB2.6，分布式扩展插件 Citus10，以及上百功能扩展，全部一键安装，开箱即用。

  • Pigsty 集成了完整的大规模数据库监控管控解决方案：Grafana，Prometheus，Loki，Ansible，CMDB。亦可作为生产级应用运行时直接使用，监控管理其他数据库与应用。

  • Pigsty 集成了数据分析生态的常用工具：Jupyter，Echarts，Grafana，PostgREST，Postgres。可以低代码的方式，开发交互性数据应用与数据可视化作品。快速产出作品原型，并以标准的方式分享，演示与交付。

多快好省的开发者工具：
HashiCorp for Database!

  • Pigsty 采用 Infra as Data 的设计理念，用户描述自己想要什么样的数据库集群，而 Pigsty 自动为您创建！Just like Kubernetes！

  • Pigsty 提供灵活丰富的部署支持，本地沙箱，云端，多云部署。无论是高规格物理机还是 1 核 1G 虚机均可运行，保持生产、预发、开发、测试环境高度一致。

  • Pigsty 可以极大简化数据库部署实施维护工作，极大降低 PostgreSQL 数据库运维与使用的门槛，量产 DBA，有效降低软硬件人力成本。使用云厂商服务器的牛，耕云数据库的田，也能减少 50% 以上的 TCO，自建机房更是能节省 80% 的成本费用。

Pigsty 为 DBA 留下了两个安全出口：PITR 备份与等保安全加固。

自动驾驶 SRE 解决方案：
Alternative for RDS!

  • 终极可观测性：监控是有效管理的基石。没有完善的监控，SRE 无从谈起。Pigsty 带有终极的可观测性，以 BI 的思路设计监控系统，从最顶层的全局洞察到最细节的每一个对象，都可以获取实时洞察，为决策提供数据支撑，做到“心中有数”。

  • 高可用数据库集群：Pigsty 集成了久经考验的生产级高可用数据库架构方案：主从异地容灾，硬件故障自愈，高可用自动切换，自带连接池与负载均衡器，提供分布式数据库般的体验。冷备份与延时从库可有效应对各类软件故障与人为故障，确保系统稳定运行。极大简化运维工作。

  • Pigsty 还可以作为完整的 SRE 解决方案：主机监控，应用部署，并将逐步添加其他数据库的部署与监控：Redis/Greenplum/Kafka/Minio，或支持其他 SaaS 服务，制作 POC，交付 Demo 等。

未来路线规划

从长期来看，我希望在 Pigsty 中再添加 Minio，Kafka 支持，让整个产品形成一个以 PostgreSQL 为核心的整体解决方案，覆盖中小型企业完整生命周期的数据存储需求，打造一个开源的、私有的云数据库管控整体解决方案。关系型数据库 PostgreSQL 作为核心，缓存 Redis 强化 TP 能力，数仓 Greenplum/MatrixDB 强化大规模数据分析能力，对象存储 Minio 用于备份管理以及存储图像音视频等数据，消息队列 Kafka 提供数据总线的能力。通过完备的 ETL/CDC 支持将这些数据组件融为一体，实现 turning the database inside-out！

从短期来看，Pigsty 将尽可能充分利用元节点上的 CMDB。CMDB 模式应当尽快适配多模数据库，命令行工具也应当及时更新，提供类似于云 CLI 工具的使用体验。多云部署与云厂商适配也应当尽快弄起来。监控面板也有大量的改善空间，包括 Catalog 数据挖掘与呈现，日志分析与提炼。从可观测性的角度讲，Blackbox 黑盒探测与 Mtail/Promtail 日志衍生指标还有不小的创新空间。数据库模式演化，可以考虑使用开源的解决方案 Bytebase。PostgREST 的能力也有待进一步发掘。冷备份/PITR 是 Pigsty 留给 DBA 们的一个安全出口，但也应当准备一个 Best Pracetice 指南。

社区问卷调查

Pigsty 有一个活跃的用户群组，微信搜索 pigsty-cc 或扫二维码添加 Pigsty 小助手拉群。

图片

此外，我们还有一个关于 PostgreSQL 与 Pigsty 的用户问卷调查，填写会有社区周边与小礼品赠送哦～，问卷链接：https://www.wjx.cn/vj/Ys1hxik.aspx

图片

扫一扫上面的二维码或点击连接参与问卷调查，我们会寄送精美社区周边～。

v1.4.0 发行注记

架构

  • 将系统解耦为 4 大类别：INFRA、NODES、PGSQL、REDIS，这使得 Pigsty 更加清晰、更易于扩展。
  • 单节点部署 = INFRA + NODES + PGSQL
  • 部署 PGSQL 集群 = NODES + PGSQL
  • 部署 Redis 集群 = NODES + REDIS
  • 部署其他数据库 = NODES + xxx（例如 MONGO、KAFKA…）

可访问性

  • 为中国大陆提供 CDN。
  • 使用 bash -c "$(curl -fsSL http://get.pigsty.cc/latest)" 获取最新源代码。
  • 使用新的 download 脚本下载并提取包。

监控增强

  • 将监控系统分为 5 大类别：INFRA、NODES、REDIS、PGSQL、APP
  • 默认启用日志记录
    • 现在默认启用 loki 和 promtail，带有预构建的 loki-rpm。
  • 模型和标签
    • 为所有仪表板添加了一个隐藏的 ds prometheus 数据源变量
    • 为所有指标添加了一个 ip 标签，并将其用作数据库指标和节点指标之间的连接键
  • INFRA 监控
    • Infra 主仪表板：INFRA 概览
    • 添加日志仪表板：日志实例
    • PGLOG 分析和 PGLOG 会话现在被视为示例 Pigsty APP
  • NODES 监控应用
    • 可以单独使用 Pigsty 作为主机监控软件
    • 包括 4 个核心仪表板：节点概览 & 节点集群 & 节点实例 & 节点警报
    • 为节点引入新的身份变量：node_cluster 和 nodename
  • PGSQL 监控增强
    • 全新 PGSQL Cluster，简化并专注于集群中的重要内容
    • 新仪表板 PGSQL Databases 是集群级对象监控
    • PGSQL Alert 仪表板现在只关注 PGSQL 警报
    • PGSQL Shard 已添加到 PGSQL 中
  • Redis 监控增强
    • 为所有 Redis 仪表板添加节点监控

MatrixDB 支持

  • 通过 pigsty-matrix.yml playbook 可以部署 MatrixDB（Greenplum 7）
  • MatrixDB 监控仪表板：PGSQL MatrixDB
  • 添加示例配置：pigsty-mxdb.yml

软件升级

  • PostgreSQL 14.2
  • PostGIS 3.2
  • TimescaleDB 2.6
  • Patroni 2.1.3（Prometheus 指标 + 故障转移插槽）
  • HAProxy 2.5.5（修复统计错误，更多指标）
  • PG Exporter 0.4.1（超时参数等）
  • Grafana 8.4.4
  • Prometheus 2.33.4
  • Greenplum 6.19.4 / MatrixDB 4.4.0
  • Loki 现在作为 RPM 包提供，而不是 ZIP 存档

错误修复

  • 删除 Patroni 的 Consul 依赖，这使其更容易迁移到新的 Consul 集群
  • 修复 Prometheus bin/new 脚本的默认数据目录路径
  • 在 vip-manager systemd 服务中添加重新启动秒数
  • 修复错别字和任务

API 变更

新增变量

  • node_cluster：节点集群的身份变量
  • nodename_overwrite：如果设置，则 nodename 将设置为节点的主机名
  • nodename_exchange：交换 play 主机之间的节点主机名（在 /etc/hosts 中）
  • node_dns_hosts_extra：可以通过单个实例/集群轻松覆盖的额外静态 DNS 记录
  • patroni_enabled：如果禁用，postgres & patroni 的引导过程不会在 postgres 角色期间执行
  • pgbouncer_enabled：如果禁用，pgbouncer 在 postgres 角色期间不会启动
  • pg_exporter_params：生成监控目标 URL 时为 pg_exporter 提供的额外 URL 参数
  • pg_provision：布尔值变量，表示是否执行 postgres 角色的资源配置部分
  • no_cmdb：用于 infra.yml 和 infra-demo.yml 播放书，不会在元节点上创建 CMDB

v1.4.1 发行注记

日常错误修复 / Docker 支持 / 英文文档

现在默认在元节点上启用 Docker，可以用它启动大量各类软件。

Bug 修复

  • 修复 Promtail & Loki 配置变量问题
  • 修复 Grafana 旧版警报
  • 默认禁用 nameserver
  • 为 Patroni 快捷方式重命名 pg-alias.sh
  • 为所有仪表板禁用 exemplars 查询
  • 修复 Loki 数据目录问题
  • 将 autovacuum_freeze_max_age 从 100000000 更改为 1000000000

发布版本：微信公众号

2.5 - Pigsty近况与v1.4前瞻

原文发布于 VONNG。

Pigsty v1.4 将于 3 月内发布，对监控系统进行了显著改进；探探所有 PostgreSQL 完整搬迁至 Pigsty；Pigsty 开始接洽 VC

探探全量迁移至 Pigsty

探探是 Pigsty 最大的用户案例，也始终是第一个吃螃蟹的人。今天探探下线了最后一套遗留的旧 PostgreSQL 数据库 pg.meta.tt。至此，探探主生产环境所有数据库均已迁移至 Pigsty，近一百套集群全部由 Pigsty v1.3.1 所托管。所有集群全部启用了高可用自动切换，历时近两年的数据库飞升项目正式宣告完工。

图片

探探主生产环境的 Pigsty 部署：96 集群 12688 核的 PostgreSQL OLTP 集群。

在探探，Pigsty 经过了长时间，大规模，高强度的实际生产环境测试。在两年的时间里不断打磨完善，最终演变为今天的样子。在近日的混沌工程演练中，运维随机挑选数据库机器进行多次宕机演练，Pigsty 在无人值守的情况下可以自动进行高可用主从/流量切换。从库宕机无业务影响，主库宕机对业务写入影响不超过在 1 分钟。

图片

一次典型从库宕机现场，读流量迅速由主库承担，业务只有极个别现场查询中断报错，而后立即恢复。

图片

一次典型主库宕机现场。主库宕机 30s 后，从库被提升新主库，影响 30s 业务写入请求后自愈。

Pigsty 与 VC

Pigsty 是一个开源项目，致力于 PostgreSQL 的推广，极大降低数据库的使用与管理门槛，显著拉高社区用户使用 PostgreSQL 的下限。依托于 PostgreSQL 中文社区，属于用爱发电的公益开源项目。

不过，数据库作为信息系统的核心组件，很多用户在使用中反馈，希望有专业的商业服务来兜底。因此 Pigsty 也不排斥进行一些商业化方面的探索，最近接触了一些 VC 机构，也与不少投资人聊过。

图片

Pigsty 的用户痛点与产品定位

今日，Pigsty 很荣幸通过了由陆奇博士主办的创业孵化器 奇绩创坛 的面试，有机会进入 2022 春季创业营。如果您也对投资 Pigsty 感兴趣，现在确实是一个好机会哦，请联系我。\

Pigsty v1.4 新特性前瞻

最近经常听到一类用户的反馈：

  1. Pigsty 可不可以用来监控管理其他类型的数据库？

    例如 Redis，MySQL，Greenplum？

  2. Pigsty 的工作假设，DB：Node 1:1 部署是否合理？

    如何支持单机多实例的部署与监控？

  3. Pigsty 的主机监控能不能独立使用？

    我不想用数据库，只想用主机节点监控怎么弄？

应。Pigsty 将于 3 月内发布 v1.4，对这些用户关心的问题做出回应，带来一系列体验改进与新功能特性，包括：

  1. 独立的主机节点监控部署功能

  2. 改进的 PostgreSQL 数据库监控

  3. 对 Greenplum/MatrixDB 部署与监控的初步支持

  4. 改进的监控数据模型，支持单机多实例。

图片

Pigsty v1.4 Home 主页

节点监控\

Pigsty v1.4 引入了一个全新的功能：节点监控。

这并不是说以前 Pigsty 没有关于机器节点的监控指标，而是在以前，机器的监控指标是 1:1 与 PostgreSQL 实例绑定的。对于一个 PostgreSQL 数据库发行版来说，这样的设计是没有问题的。但随着 Pigsty 的发展，这样的设计就开始显得不合时宜了。

用户可能有各种各样的使用方式与部署策略，例如，在一个节点上部署多个数据库实例，甚至部署多种不同类型的数据库。在这种情况下，合适的做法是把节点的管理与监控单独抽离出来，不与具体的数据库类型绑定。

这样做有两个显著的好处：一是如果用户不需要数据库监控与管理，只需要节点的监控与管理，那么会比以前简单很多；第二是一个节点上可以部署多个甚至多种数据库，并复用同样的节点监控指标数据。

图片

Node Overview 面板，关注所有节点的指标。

虽然 Pigsty 的定位是开箱即用的 PostgreSQL 发行版，但其中也包含着主机监控的最佳实践。有些用户根本不 care 数据库，只是拿 Pigsty 做主机监控…。

图片

新增的 Nodes Cluster 面板，关注一组节点的聚合指标与集群内的水平对比

节点监控提供了全局概览，集群，以及单个节点三种不同的层次。节点的集群可以独立配置，也可以配置为默认与 PostgreSQL 数据库集群保持一致。

多数据库支持

节点监控与置备的剥离，为第二件事打下了基础，那就是多数据库支持。

图片

PostgreSQL 是一个相当全能、相当完美的数据库内核了，但正所谓：红花还需绿叶配，一个好汉三个帮。当组织与数据成长到一定规模后，使用专有数据组件的需求也会随之出现。最典型的两类是：以 Redis 为代表的缓存，以及以 Greenplum 为代表的数据仓库。

图片

Redis 可以进一步强化业务系统的 OLTP 处理能力，分担数据库压力，模型简单易用，受到广受开发者的喜爱。而 Greenplum 则可以显著强化业务系统的 OLAP 能力，采用与 PostgreSQL 一致的语言、驱动与接口，将数据分析的量级从几十 TB 提升到 PB 乃至 ZB 的级别。

Redis 与 Greenplum 在两个方向上扩展了 PostgreSQL 的能力边界，这两者都是 PostgreSQL 的拍档，经常在一起组合使用。因此，Pigsty 在 v1.4 中提供了对 Redis 与 Greenplum 的初步支持。

图片

Redis Overview 监控面板

图片

复用 Postgers 剧本，声明一个 MatrixDB 集群

PG 监控例行改进

Pigsty v1.4 提供了对新数据库种类的监控支持，但对于经典的 PostgreSQL 监控也没有落下。在 1.4 中，大量 PGSQL 的监控面板进行了调整与重置，最具有代表性的就是 PGSQL Cluster 面板。

图片

全新的 PGSQL Cluster 监控面板

PGSQL Cluster 是 Pigsty 数据库监控中最核心的监控面板之一，承上启下，用于呈现一个自治数据库集群的关键状态。新的设计隐藏了不必要的信息，聚焦于集群资源。您可以从首屏快速点击集群内的资源对象，前往细分的监控面板：包括节点，实例，负载均衡器，服务，数据库，服务组件。

除了集群资源对象，PGSQL Cluster 的首屏只呈现最关键的监控指标，报警事件，集群/实例压力水位。其他细节都隐藏在下面的专题栏中。

图片

成员详情表在默认隐藏的第二栏中

第二个显著改进是 PGSQL Database 面板。在过去，这个监控面板的存在感与使用频率并不高。因此在 v1.4 中，PGSQL Database 进行了彻底的改版。从笼统地介绍一个数据库实例的库级指标，变为关注整个数据库集群内部对象的详情。例如，您可以查阅一张表或一类查询在集群主库与从库实例上的 QPS，或者确认某一个索引在集群不同实例上的使用情况，从而对业务与应用进行有针对性的优化。

其他一些新的主题监控面板也在制作打磨完善中。例如，关注集群维护任务的 PGSQL Maintenance 面板，可以观察备份、创建索引、垃圾回收任务的实时进度。PGSQL Shard 面板，则关注多个水平分片的业务集群之间的横向比较。这些 Dashboard 都将在生产环境中不断打磨优化，臻至成熟后进入到 Pigsty 中。

使用方式与接口

Pigsty v1.4 提供了一系列新的 Playbook / 剧本。

在 v1.4 中，Pigsty 的使用方式变得更加直观了。如果您将 Pigsty 用作单机数据库或监控核心，只需要执行 meta.yml 即可。如果您希望部署额外的数据库集群，使用 node.yml 将这些节点先纳入管理，而后选择对应数据库的剧本（ pgsql.yml , redis.yml，gpsql.yml ）执行即可。

meta.yml 用于替代以前的 infra.yml，负责在单台节点上完整安装一套 Pigsty 系统。包括一套完整就绪的的 PostgreSQL 数据库。同时，新增的 meta-remove.yml 剧本用于 Pigsty 的卸载。

node.yml 从 pgsql.yml 中剥离，用于将新的节点纳入 Pigsty 管理。执行此剧本，会自动将目标节点置备为指定的状态，并安装 DCS（Consul Agent）与节点监控。如果您希望使用 Pigsty 在部署数据库集群，则应当使用此剧本将目标节点先纳入 Pigsty 管理。同时，新增的 node-remove.yml 剧本用于将节点从 Pigsty 中移除。

pgsql.yml 现在移除了节点初始化的部分，只负责在已经初始化好的节点上部署 PostgreSQL 集群与实例，并将其纳入监控。一些新的开关选项被添加至相关的 Ansible Roles 中，但主体配置仍与先前保持兼容。pgsql-remove.yml 剧本亦进行了相应调整，移除 DCS 服务现在由 node-remove.yml 负责。

redis.yml 也移除了节点初始化的部分，您需要在已经初始化好的节点上执行此剧本以部署 Redis 服务。新增的 redis-remove.yml 剧本用于从目标节点上移除 Redis 服务。

gpsql.yml 是新增的，用于部署 MatrixDB 的剧本（实际上是 Greenplum 7 的超集），目前仍然处于 Beta 阶段，可以对 MatrixDB/Greenplum 提供基本的部署与安装支持。

未来的路线图

从长期来看，我希望在 Pigsty 中再添加 Minio，Kafka 支持，让整个产品形成一个以 PostgreSQL 为核心的整体解决方案，覆盖中小型企业完整生命周期的数据存储需求，打造一个开源的、私有的云数据库管控整体解决方案。关系型数据库 PostgreSQL 作为核心，缓存 Redis 强化 TP 能力，数仓 Greenplum/MatrixDB 强化大规模数据分析能力，对象存储 Minio 用于备份管理以及存储图像音视频等数据，消息队列 Kafka 提供数据总线的能力。通过完备的 ETL/CDC 支持将这些数据组件融为一体，实现 turning the database inside-out！

从中期来看，Pigsty 将尽可能充分利用元节点上的 CMDB。CMDB 模式应当尽快适配多模数据库，命令行工具也应当及时更新，提供类似于云 CLI 工具的使用体验。多云部署与云厂商适配也应当尽快弄起来。

从短期来看，Pigsty 的监控面板还有大量的改善空间，包括 Catalog 数据挖掘与呈现，日志分析与提炼。从可观测性的角度讲，Blackbox 黑盒探测与 Mtail 日志衍生指标还有很大挖掘空间。此外，针对 Greenplum 的定制 Dashboard 也将提上日程。

当然，这些都需要大量的人力脑力投入，一个人用爱发电速度毕竟有限，特别是最近在热恋中，对 Pigsty 的爱被分走了很多呢。所以，也非常欢迎大家一起来 Contrib 啊，一起打造一款属于我们自己的 “RDS”。

发布版本：微信公众号

2.6 - Pigsty v1.3：PGCAT大修，PGSQL增强，Redis支持

原文发布于 VONNG。

GitHub Release | 发布注记 | 微信公众号

Pigsty v1.3 正式发布，新增 Redis 支持、PGCAT 应用重构、PGSQL 监控增强。

Redis 支持

虽然 PostgreSQL 是 世界上最先进的开源关系型数据库，但一个好汉三个帮。Pigsty v1.3 为 PostgreSQL 引入了一位得力的缓存伙伴：世界上最快的数据库 —— Redis。

redis-partner

Redis 性能强悍，单核轻松达到二三十万 QPS。

redis-fast

Pigsty Demo 中已经纳入 Redis 集群样例：

redis-demo

三种部署模式

Redis 有三种经典部署模式：普通主从结构（Standalone）、原生集群（Cluster）、高可用哨兵（Sentinel）。Pigsty v1.3 全部支持。

redis-overview

Redis Overview 首页展示了三个样例集群，分别对应三种部署模式。

声明式配置

定义 Redis 集群的方式与 PostgreSQL 高度一致。声明完成后，使用 redis.yml -l <cluster> 即可创建对应集群：

redis-config

只需少量必选身份参数即可声明一个 Redis 集群。当然，也可以使用更多参数进行精细配置：

redis-params-1redis-params-2

自动监控

使用 Pigsty 创建的 Redis 集群与实例会自动纳入监控系统。

redis-cluster

单个 Redis 集群的监控首页，点击具体实例可跳转至实例级监控：

redis-instance

PGCAT 重构

v1.3 重构了 PGCAT 应用，这是一个直接从 Grafana 访问并可视化 PostgreSQL 系统目录的应用。

pgcat-instance

单个 PostgreSQL 实例的 Catalog 信息：数据库、活动会话、查询语句。

pgcat-instance-2

单个 PostgreSQL 实例的 Catalog 信息：配置、复制、内存使用、持久化、角色。

pgcat-database

单个 PostgreSQL 数据库的 Catalog 信息，包括数据库内的模式、表、索引、序列等对象。

pgcat-table

PGCAT TABLE Dashboard 改版：添加每一列的详细统计信息展示。

无侵入式设计

PGCAT 只需一个可访问的目标数据库 URL 即可使用，无需安装任何 Agent。即使是仅监控模式部署现有实例，也可以完整使用 PGCAT 功能。

pgsql-monitor-only

在 Pigsty v1.3 的仅监控部署模式中，外部 PostgreSQL 实例也会在 Grafana 中注册并默认启用 PGCAT 功能。

PGSQL 增强

核心 PGSQL 监控应用也有显著改进。

pgsql-cluster

在 Pigsty v1.3 中，PGSQL Cluster 添加了 10 个核心指标的快速导览面板。

PGSQL Instance、PGSQL Cluster 都新增了若干快速导览面板，用于快速定位问题。PGSQL Service 完整重置，更为简洁直观，便于快速理清集群拓扑。其他 Dashboard 也有相应优化与改进。

此外，v1.3 还包含半自动数据库迁移剧本的改进、Profiling 工具支持等功能增强。

v1.3.0 更新日志

Redis 支持

功能 说明
Redis 部署 支持集群、哨兵、主从三种模式
Redis 监控 提供总览、集群、实例三级仪表盘

PGCAT 大修

仪表盘 说明
PGCAT Instance 新增实例级 Catalog 仪表盘
PGCAT Database 新增数据库级 Catalog 仪表盘
PGCAT Table 重做表级统计仪表盘

PGSQL 增强

仪表盘 改进内容
PGSQL Cluster 新增 10 个关键指标面板
PGSQL Instance 新增 10 个关键指标面板
PGSQL Service 简化重设计，更清晰直观
交叉引用 在 PGCAT 与 PGSQL 仪表盘间添加导航链接

监控部署

  • Grafana 数据源在仅监控部署期间自动注册

软件升级

  • 将 PostgreSQL 13 添加到默认包列表
  • 默认升级到 PostgreSQL 14.1
  • 添加 Greenplum RPM 和依赖项
  • 添加 Redis RPM 及源码包
  • 将 perf 添加为默认包

v1.3.1 更新日志

监控

  • PGSQL & PGCAT 仪表盘改进
  • 优化 PGCAT Instance & PGCAT Database 布局
  • 在 PGSQL Instance 仪表盘中添加关键指标面板，与 PGSQL Cluster 保持一致
  • 在 PGCAT Database 中添加表/索引膨胀面板，移除 PGCAT Bloat 仪表盘
  • 在 PGCAT Database 仪表盘中添加索引信息
  • 修复 Grafana 8.3 中的损坏面板
  • 在 Nginx 主页中添加 Redis 索引

部署

  • 新增 infra-demo.yml 剧本用于一次性引导
  • 使用 infra-jupyter.yml 剧本部署可选的 Jupyter Lab 服务器
  • 使用 infra-pgweb.yml 剧本部署可选的 PgWeb 服务器
  • 在 Meta 节点上新增 pg 别名，可从 admin 用户启动 PostgreSQL 集群
  • 根据 timescaledb-tune 建议调整所有 Patroni 配置模板中的 max_locks_per_transactions
  • 在配置模板中添加 citus.node_conninfo: 'sslmode=prefer' 以便在无 SSL 情况下使用 Citus
  • 在 PGDG14 包列表中添加所有扩展（除 pgrouting 外）
  • 将 node_exporter 升级到 v1.3.1
  • 将 PostgREST v9.0.0 添加到包列表，支持从 PostgreSQL Schema 生成 API

错误修复

  • Grafana 安全漏洞修复（升级到 v8.3.1，详情）
  • 修复 pg_instance & pg_service 在 register 角色中从剧本中间开始时的问题
  • 修复在没有 pg_cluster 变量的主机上 Nginx 主页渲染问题
  • 修复升级到 Grafana 8.3.1 时的样式问题

2.7 - Pigsty v1.2：PG14默认，监控现有PG

原文发布于 VONNG。

GitHub Release | 发布注记 | 微信公众号

Pigsty v1.2 正式发布，将 PostgreSQL 14 作为默认版本，并支持独立监控现有数据库实例。

PostgreSQL 14 成为默认版本

PostgreSQL 14 于上月发布，在各方面特别是可观测性上有显著改进。经过多个组织生产环境的部署与充分测试后，PostgreSQL 14 已成为 Pigsty 的默认数据库版本。

同时，适配 PG14 的时序数据扩展 TimescaleDB 2.5、地理空间扩展 PostGIS 3.1 已默认安装启用，配合分布式数据库插件 Citus 10，真正实现 开箱即用的时空超融合开源 PostgreSQL 数据库发行版。

timescale-postgis-citus

三者相互兼容，可组合使用。

仅监控部署模式

第二个重要特性是 仅监控部署模式。此前 Pigsty 作为发行版，监控系统与部署方案浑然一体。但很多用户希望只使用 Pigsty 的监控系统来监控已有的数据库实例、云数据库、以及其他 RDS 产品与各类衍生版本。

monitor-minio

最小部署模式在本地不同端口启动 pg_exporter 以监控外部 PostgreSQL 实例。

在 v1.2 中，Pigsty 提供三种可选的监控部署模式：

模式 说明
完整部署 完整的 Pigsty 部署，包含监控与管控
精简部署 仅部署监控相关组件
最小部署 仅需数据库连接串，无需远程机器权限

新增的最小部署模式不再需要远程机器的登录与管理权限，只要有一个连接串可以只读访问远程数据库，即可将其纳入监控管理。所有监控功能浓缩在一台机器上，管理简单方便。

monitor-only

尽管只有 PostgreSQL 本身的指标，但 Pigsty 监控系统的大部分功能仍可正常工作。经测试，Pigsty 也可直接用于监控 MatrixDB、GreenPlum 等 PostgreSQL 衍生/兼容数据库产品。

配置模板精简

配置模板被进一步精简：现在只有两种模板：生产环境（默认）与 沙箱环境。

规格参数模板更加丰富，提供平滑过渡的规格选项：

规格 配置 说明
tiny 1C1G 最小测试规格
mini 2C4G 开发环境规格
small 4C8G 小型生产规格
medium 8C16G 中型生产规格
large 16C32G 大型生产规格
oltp/olap/crit 64C400G 专业生产规格

在配置过程中，安装向导会自动根据机器规格选择对应的参数模板。

configure

Pigsty 始终保持 ./configure && make install 一行命令完成安装的优良传统。

实用工具剧本

新增 pgsql-migration 剧本可自动生成数据库迁移所需的命令、脚本与手册，使基于逻辑复制的在线不停机数据库迁移变得简单（已在生产环境迁移数十套数据库）。

pgsql-audit 剧本可根据审计需求生成对应数据库实例的审计报告。

示例应用

v1.2 提供两个新的 Pigsty App 示例：

AppLog - 用于可视化 Apple iOS15 新隐私日志的应用，可以展示哪些应用访问了哪些权限。

applog

WorkTime - 查询中国各大公司工作休息时间的应用。

worktime

两个应用功能简单但实用，开发只用了不到一小时。Pigsty 在产出具有基本功能的应用原型时是一个非常趁手的工具。

后续规划

PGSQL v8 - 提供更加层次分明的监控面板组织，面向不同用户群体提供不同的主题视图。

pgsql-v8

PGCAT v2 - 提供更为丰富的系统目录导航浏览功能。

pgcat-v2

REDIS v1beta - Redis 经常与 PostgreSQL 搭配使用，后续版本会将 Redis 部署与监控整合为完整的解决方案。

redis-v1

v1.2.0 更新日志

核心功能

  • 默认使用 PostgreSQL 14 版本
  • 默认使用 TimescaleDB 2.5 扩展
  • TimescaleDB 和 PostGIS 默认在 CMDB 中启用

仅监控模式

  • 仅通过可连接的 URL 即可监控现有 PostgreSQL 实例
  • pg_exporter 将在本地 Meta 节点上部署
  • 新增 PGSQL Cluster Monly 仪表盘用于远程集群

软件升级

  • Grafana 升级到 8.2.2
  • pev2 升级到 v0.11.9
  • Promscale 升级到 0.6.2
  • PgWeb 升级到 0.11.9
  • 新增扩展：pglogical、pg_stat_monitor、orafce

改进增强

  • 自动检测机器规格并使用适当的 node_tune 和 pg_conf 模板
  • 重做膨胀相关视图，公开更多信息
  • 删除 TimescaleDB 和 Citus 的内部监控
  • 新增 pgsql-audit.yml 剧本用于创建审计报告
  • 所有配置模板简化为两种：auto 和 demo

错误修复

  • pgbouncer_exporter 资源所有者改为 {{ pg_dbsu }} 而不是 postgres
  • 修复执行 REINDEX TABLE CONCURRENTLY 时 pg_exporter 在 pg_table/pg_index 上的重复指标问题

升级说明

v1.2.0 中没有 API 变更，仍可使用旧的 pigsty.yml 配置文件（PG13）。对于基础设施部分，重新执行 repo 将完成大部分工作。

对于数据库，可继续使用现有的 PG13 实例。涉及 PostGIS 和 TimescaleDB 等扩展时，就地升级较为复杂，推荐使用逻辑复制进行数据库迁移。新增的 pgsql-migration.yml 剧本将生成一系列脚本，帮助实现近乎零停机时间的集群迁移。

2.8 - Pigsty v1.1：主页，Jupyter，Pev2，Pgbadger

原文发布于 VONNG。

好消息，好消息，时隔一月，开箱即用的开源 PostgreSQL 发行版 —— Pigsty 正式发布 v1.1 版本！v1.1 带来了一些非常不错的特性，主要是关于基础设施的（毕竟部署好的数据库没人想去动它）。以下是更新摘要。

图片

全新的首页

一直以来，Grafana 监控系统中的 Home Dashboard 都扮演着 Pigsty“主页”的角色，现在 Pigsty 终于有一个看上去还不错的独立的主页啦。如果想知道主页是什么样子，可以访问公开演示：http://home.pigsty.cc

图片

比较熟悉 Pigsty 的用户可能一下子就能看出来，这不就是文档站抽出来改了一改吗？哈哈是的，这个首页就是一个本地版的文档站，由默认的 Nginx 提供服务。

服务导航

这个主页提供了前往 Pigsty 各个服务组件的导航，包括以前就有的：Consul，Grafana，Prometheus，AlertManager，以及在 1.1 中新引入的 PGWeb 与Jupyter Lab。您可以直接点击首页正中的组件名称/URL，或通过导航栏右上角的Service下拉菜单进入。

监控导航

首页现在也可以呈现 Pigsty 部署中的集群与实例（可选），并提供到具体集群、实例的监控首页，流量的管控界面的的直接跳转。

图片

应用导航

右上角的 App 下拉选单将成为 Pigsty 扩展功能的入口，在 1.1 中，Pigsty 自带了几个实用而有趣的应用。这些应用都可以通过配置选项添加。

图片

本地文档\

在 Pigsty1.1 中，您可以直接从 Pigsty 首页访问本地离线文档，包括中英双语。

图片

Jupyter Lab

如果您曾使用 Python 进行数据分析，那么 Jupyter 一定不会陌生。Pigsty v1.0.0 打包了 Jupyter Lab 软件包，而 v1.1 则更进一步，将其放入原生支持中。在演示与个人配置模板中，Jupyter Lab 默认启用，在生产环境部署中则默认不启用。

图片

您可以通过 Jupyter Notebook，高效，敏捷地提取数据，处理、分析、转换、并进行可视化，组合使用 Python 与 SQL 的强大能力。（当然您也可以继续使用 Pigsty 提供的 Grafana 与 Echarts 进行可视化）

图片

当然，强大与便利往往也蕴涵着风险。Jupyter 执行任意代码的能力对于生产环境仍然是一个过于冒险的配置，因此默认不会在生产环境配置模板中启用。

PGWeb

作为一个开箱即用的数据库发行版，提供一个开箱即用的图形化客户端工具也是非常重要的。PGWEB 是一个使用 Go 编写的，小巧的，基于浏览器的 Postgres 图形客户端

图片

与 Jupyter 类似，PGWEB 在演示与个人配置模板中默认启用，在生产环境部署中则默认不启用。但 PGWEB 要求用户拥有访问数据库的连接串，因此相对安全，可以用于生产环境中个人用户查询少量数据的场景。

图片

用户可以浏览数据库中的模式、对象。快速浏览表中的数据，执行查询等。

PEV2

Pev2 是一个实用的执行计划分析器，可以把 PostgreSQL 查询 EXPLAIN 的结果转换为一颗直观的执行计划树。

图片

这个工具对于优化慢查询，分析 auto_explain 结果都非常好用。

PGBadger

PGBADGER 是一个非常好用的 Postgres 日志分析组件，可以从 CSV 日志中快速生成精美全面的分析报告。

使用bin/pglog-summary [ip] [date] 即可拉取特定节点特定日期的日志，并创建日志分析报告。

图片

为该命令添加 Crontab，即可每天、或准实时地自动生成数据库运行报表。

软件更新

PostgreSQL 14 已经正式发布了，Pigsty v1.1 也第一时间进行了跟进与支持。pigsty-pg14 模板已经可以在生产环境中创建默认版本为 14 的 PostgreSQL 数据库了。但因为 PostgreSQL 的一个重要三方扩展 TimescaleDB 尚未正式支持 PG14 （预计时间 10-30），因此 PG14 还不是 Pigsty 的默认数据库版本。

Pigsty 将于 v1.2 进行默认 PG 版本升级，将默认数据库版本升级为 PG14。

图片

此外，其他软件也都有升级：

  • postgres 升级至 v13.4

  • pgbouncer 升级至 v1.16 (新增 2 监控指标)

  • grafana 升级至 v8.1.4

  • prometheus 升级至 v2.2.29

  • node_exporter 升级至 v1.2.2

  • haproxy 升级至 v2.1.1

  • consul 升级至 v1.10.2

  • vip-manager 升级至 v1.0.1

新的剧本：数据库迁移

Pigsty 内置了一个 数据库在线迁移的辅助脚本：pgsql-migration.yml，提供了一个开箱即用的基于逻辑复制的不停机数据库迁移方案。

填入源集群与宿集群相关信息，该剧本即会自动创建出迁移中所需的脚本，在数据库迁移时只需要依次执行即可，包括：

图片图片

新的应用：苹果隐私日志可视化

最后，Pigsty 的自带的默认演示应用里又多了一个：苹果应用隐私日志可视化（APPLOG），您可以在 iOS15 系统中导出应用程序访问隐私的记录，并在此应用中进行可视化，细节可以参考公众号前一篇文章 《 微信读相册这点事 》。

图片

图：微信大清早偷偷访问我的相册长达 4 分钟

图片

一些有趣的小功能

部署好的数据库没人想去动它，但 Pigsty 还是在 v1.1 加入了一个数据库实例上的新特性：Dummy file。原理很简单，创建一个一定尺寸（例如 1～4GB）的/pg/dummy，这样当出现磁盘写满的故障时（通常很多操作都无法正常完成了），只需要将其删除，就可以释放出一定的应急空间来。

这个功能非常实用，但对于已经创建好的数据库实例而言，手动dd或filealloc一个就可以与新版本保持一致，或者彻底无视也没有关系。

此外，v1.1 中还添加了 promscale 的安装包，这是一个有趣的组件，可以将 Prometheus 的时序数据存储替换为 TimescaleDB（Postgres），文档中的教程也更新了如何替换的细节。

Enjoy！

其他

此外，还有一些 Bug 与小问题的修复，文档的例行完善等

变更细节

图片

v1.1.0 更新日志

功能增强

  • 增加 pg_dummy_filesize 以创建文件系统空间占位符
  • 主页大改版
  • 增加 Jupyter Lab 整合
  • 增加 PGWeb 控制台整合
  • 增加 PgBadger 支持
  • 增加 PEV2 支持，执行计划可视化工具
  • 增加 pglog 工具

软件升级

  • PostgreSQL 升级至 v13.4（支持官方 PG14）
  • pgbouncer 升级至 v1.16（指标定义更新）
  • Grafana 升级至 v8.1.4
  • Prometheus 升级至 v2.2.29
  • node_exporter 升级至 v1.2.2
  • HAProxy 升级至 v2.1.1
  • Consul 升级至 v1.10.2
  • vip-manager 升级至 v1.0.1

API 变更

  • nginx_upstream 现持有不同结构（不兼容）
  • 新配置条目：app_list，渲染至主页的导航条目
  • 新配置条目：docs_enabled，在默认服务器上设置本地文档
  • 新配置条目：pev2_enabled，设置本地 PEV2 工具
  • 新配置条目：pgbadger_enabled，创建日志概要/报告目录
  • 新配置条目：jupyter_enabled，在元节点上启用 Jupyter Lab 服务器
  • 新配置条目：jupyter_username，指定运行 Jupyter Lab 的用户
  • 新配置条目：jupyter_password，指定 Jupyter Lab 的默认密码
  • 新配置条目：pgweb_enabled，在元节点上启用 PGWeb 服务器
  • 新配置条目：pgweb_username，指定运行 PGWeb 的用户
  • 将内部标记 repo_exist 重命名为 repo_exists
  • repo_address 默认值改为 pigsty 而非 yum.pigsty
  • HAProxy 访问点改为 http://pigsty 而非 http://h.pigsty

v1.1.1 更新日志

  • 用 timescale 版本替换 TimescaleDB 的 apache 版本
  • 升级 Prometheus 到 2.30
  • 修复 pg_exporter 配置目录属主问题（改为 {{ pg_dbsu }}）

升级说明

此版本主要变动是 TimescaleDB，使用 TimescaleDB License（TSL）的官方版本替代了 PGDG 仓库中 Apache License v2 的版本。

# 停止带有 timescaledb 的 postgres 实例
yum remove -y timescaledb_13

# 添加 TimescaleDB 官方仓库
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/7/$basearch
repo_gpgcheck=0
gpgcheck=0
enabled=1

yum install timescaledb-2-postgresql13

发布版本：微信公众号

2.9 - Pigsty v1.0：正式发布，监控大修

原文发布于 VONNG。

GitHub Release | 发布注记 | 微信公众号

经过一年多的迭代与打磨，Pigsty 正式发布 v1.0.0 GA 版本。

Pigsty (/ˈpɪɡˌstaɪ/) 是 PostgreSQL In Graphic STYle 的缩写，即"图形化 Postgres"。

Pigsty 是什么？

Pigsty 是一个 开箱即用的 PostgreSQL 数据库发行版，将生产级的集群部署、扩容缩容、主从复制、故障切换、流量代理、连接池、服务发现、访问控制、监控系统、告警系统、日志采集解决方案集成封装为发行版。一次性解决在生产环境与各类场景下使用 世界上最先进的开源关系型数据库 —— PostgreSQL 时会遇到的问题。

定位 说明
发行版 开箱即用的 PostgreSQL 发行版
监控系统 全面专业的 PostgreSQL 监控系统
部署方案 简单易用的 PostgreSQL 高可用部署方案
沙箱环境 便捷全能的本地沙箱与数据分析可视化环境
开源软件 自由免费，基于 Apache 2.0 协议开源

核心特性

whatwherewho

发行版

所谓发行版，是指由数据库内核及其一组软件包组成的数据库 整体解决方案。例如，Linux 是一个操作系统内核，而 RedHat、Debian、SUSE 则是基于此内核的操作系统发行版。PostgreSQL 是一个数据库内核，而 Pigsty、BigSQL、Percona、各种云 RDS 则是基于此内核的数据库发行版。

distro

作为数据库发行版，Pigsty 的核心特性：

  • 全面专业 的监控系统
  • 简单易用 的部署方案
  • 稳定可靠 的高可用架构
  • 便捷全能 的沙箱环境
  • 免费友好 的开源协议

开箱即用

所谓 开箱即用（Battery-Included）：用户只需一台刚装完系统的虚拟机，一行命令，10 分钟内即可完成基础设施、数据库、监控系统、管控平台的安装，进入可用状态。

Pigsty 将 部署 与 监控 做到极致，让大规模数据库集群的部署实施、管理运维、设计使用这些门槛颇高的工作，成为普通研发人员即可轻松搞定的事情。

面向专业用户，Pigsty 提供最全面专业的监控系统；面向大众用户，Pigsty 提供最简单易用的部署方案。 此外，针对数据研发人员，Pigsty 还集成了 JupyterLab、Echarts 等实用工具，可作为数据研发与可视化的集成开发环境。

battery

监控系统

Pigsty 带有一个针对大规模数据库集群管理而设计的专业级 PostgreSQL 监控系统。包括约 1200 类指标、20+ 监控面板、上千个监控仪表盘，覆盖从全局大盘到单个对象的详细信息。与同类产品相比，在指标覆盖率与监控面板丰富程度上一骑绝尘，为专业用户提供无可替代的价值。

一个典型的 Pigsty 部署可以管理几百套数据库集群，采集上千类指标，管理百万级时间序列，并将其精心组织为上千个监控仪表盘，交织于几十个监控面板中实时呈现。从全局大盘概览，到单个对象（表、查询、索引、函数）的细节指标，如同实时的核磁共振/CT 机一般，将整个数据库剖析得清清楚楚，明明白白。

dashboards

监控面板什锦

pgsql-overview

单查询监控

pgsql-query

单表监控

pgsql-table

单实例主题监控面板

pgsql-instance

三大核心应用

Pigsty 监控系统由三个紧密联系的核心 应用 共同组成：

PGSQL - 收集并呈现监控指标数据

pgsql-instance

PGCAT - 直接浏览数据库系统目录

pgcat

PGLOG - 实时查询搜索分析数据库日志

pglog

Pigsty 监控系统基于业内最佳实践，采用 Prometheus、Grafana 作为监控基础设施。开源开放，定制便利，可复用，可移植，没有厂商锁定。可与已有 PostgreSQL 数据库实例集成，亦可用于其他数据库或应用的监控与管理（例如 Redis）。

部署方案

数据库是管理数据的软件，管控系统是管理数据库的软件。

Pigsty 内置了一套以 Ansible 为核心的数据库管控方案，并基于此封装了命令行工具与图形界面。它集成了数据库管理中的核心功能：包括数据库集群的创建、销毁、扩缩容；用户、数据库、服务的创建等。

Pigsty 采纳 Infra as Code 的设计哲学，使用类似 Kubernetes 的声明式配置，通过大量可选的配置选项对数据库与运行环境进行描述，并通过幂等的预置剧本自动创建所需的数据库集群，提供私有云般的使用体验。

用户只需通过配置文件或图形界面描述"自己想要什么样的数据库"，而无需关心 Pigsty 如何去创建或修改它。Pigsty 会根据用户的配置文件清单，在几分钟内从裸机节点上创造出所需的数据库集群。

iac

对于不习惯配置文件与 Ansible 剧本的用户，Pigsty 亦提供了可选的 CMDB 模式与 CLI/GUI 工具封装常用操作。

gui

对于专业用户，Pigsty 提供了 160+ 可配置参数，允许对数据集群、基础设施运行时的方方面面进行配置与定制。而新手亦可在完全不修改配置的前提下，创建出相当可靠的数据库集群。

高可用集群

Pigsty 创建的数据库集群是分布式、高可用的数据库集群。从效果上讲，只要集群中有任意实例存活，集群就可以对外提供完整的读写服务与只读服务。

数据库集群中的每个数据库实例在使用上都是幂等的，任意实例都可以通过内建负载均衡组件提供完整的读写服务。数据库集群可以自动进行故障检测与主从切换，普通故障能在几秒到几十秒内自愈，且期间只读流量不受影响。

Pigsty 的高可用架构久经生产环境考验，以极小的复杂度实现了完整的高可用方案，让传统主从架构的数据库用出分布式数据库的感觉。

ha-arch

默认接入方式架构（DNS+L2VIP+HAProxy，共 7 种）

failover

沙箱环境

使用 PostgreSQL 不仅仅是企业，还有许许多多个人用户：用于软件的开发、测试、实验、演示；或者是数据的清洗、分析、可视化、存储。然而如何搭建环境往往成为用户面前的第一道拦路虎。

Pigsty 沙箱旨在解决这一问题，可以一键在笔记本或 PC 机上拉起完整的生产级 PostgreSQL 服务（通过 Vagrant 调用 VirtualBox 自动创建所需的虚拟机）。默认沙箱为单节点（2 核 4G），带有各类实用工具，可服务于各种用途。此外，还有四节点版本的完整版沙箱，可用于搭建生产仿真环境，充分探索 Pigsty 高可用架构与监控系统的能力。

sandbox

四节点沙箱环境架构示意图

数据分析

Pigsty 提供了 PostgreSQL 作为后端数据库，JupyterLab Python 集成开发环境，Grafana 前后端运行时，以及 Grafana Echarts Panel 用于进行高级可视化。这些工具构成了数据处理、分析、开发数据应用的一整套完整工具组合。

可基于 Pigsty 环境进行数据分析，快速产出数据应用 POC Demo，并通过标准化的方式进行打包、分发、部署、发布。Pigsty 项目中自带两个数据应用样例：

COVID - 疫情数据可视化应用

covid

点击查看单个国家详情与时间线地图

ISD - 全球地表气象站历史数据查询应用

isd

点击查看单个气象站详情与历史气象要素数据

路线图

roadmap-1roadmap-2

开源

Pigsty 基于 Apache 2.0 协议开源，可免费用于商业目的，但改装与衍生需遵守 Apache License 2.0 的显著声明条款。

Pigsty 的宗旨是：用好 数据库，用 好数据库。

让中小企业用户真正拥有"自主可控"的选择，让所有人都能轻松享受 PostgreSQL 的乐趣。

v1.0.0 更新日志

监控系统全面改进

  • 在 Grafana 8.0 上新增仪表盘
  • 新的度量定义，增加 PG14 支持
  • 简化的标签系统：静态标签集（job, cls, ins）
  • 新的警报规则与衍生度量
  • 同时监控多个数据库
  • 实时日志搜索 & csvlog 分析
  • 链接丰富的仪表盘，点击图形元素进行深入/汇总

架构变更

  • 将 Citus 和 TimescaleDB 加入默认安装部分
  • 增加对 PostgreSQL 14beta2 的支持
  • 简化 HAProxy 管理页面索引
  • 通过添加新角色 register 来解耦基础设施和 PGSQL
  • 添加新角色 loki 和 promtail 用于日志记录
  • 为管理节点上的管理员用户添加新角色 environ 以设置环境
  • 默认使用 static 服务发现用于 Prometheus（而非 consul）
  • 添加新角色 remove 以优雅地移除集群和实例
  • 升级 Prometheus 和 Grafana 的配置逻辑
  • 升级到 vip-manager 1.0、node_exporter 1.2、pg_exporter 0.4、Grafana 8.0
  • 每个实例上的每个数据库都可自动注册为 Grafana 数据源
  • 将 Consul 注册任务移到 register 角色，更改 Consul 服务标签
  • 添加 cmdb.sql 作为 pg-meta 基线定义（CMDB & PGLOG）

应用框架

  • 可扩展框架用于新功能
  • 核心应用：PostgreSQL 监控系统 pgsql
  • 核心应用：PostgreSQL 目录浏览器 pgcat
  • 核心应用：PostgreSQL Csvlog 分析器 pglog
  • 添加示例应用 covid 用于可视化 COVID-19 数据
  • 添加示例应用 isd 用于可视化 ISD 数据

其他

  • 添加 JupyterLab，为数据科学提供完整的 Python 环境
  • 添加 vonng-echarts-panel 以恢复对 Echarts 的支持
  • 添加 wrap 脚本 createpg、createdb、createuser
  • 添加 CMDB 动态库存脚本：load_conf.py、inventory_cmdb、inventory_conf
  • 移除过时的剧本：pgsql-monitor、pgsql-service、node-remove 等

API 变更

  • 新变量：node_meta_pip_install
  • 新变量：grafana_admin_username
  • 新变量：grafana_database
  • 新变量：grafana_pgurl
  • 新变量：pg_shared_libraries
  • 新变量：pg_exporter_auto_discovery
  • 新变量：pg_exporter_exclude_database
  • 新变量：pg_exporter_include_database
  • 变量重命名：grafana_url 改为 grafana_endpoint

Bug 修复

  • 修复默认时区 Asia/Shanghai (CST) 问题
  • 修复 pgbouncer & patroni 的 nofile 限制
  • 当执行标签 pgbouncer 时，pgbouncer 的用户列表和数据库列表将被生成

v1.0.1 更新日志

2021-09-14

文档更新

  • 现已支持中文文档
  • 现已支持机器翻译的英文文档

错误修复

  • pgsql-remove 不会移除主实例
  • 用 pg_cluster + pg_seq 替换 pg_instance（Start-At-Task 可能因 pg_instance 未定义而失败）
  • 从默认共享预加载库中移除 Citus（Citus 会强制 max_prepared_transaction 的值为非零）
  • 在 configure 中进行 ssh sudo 检查（现在使用 ssh -t sudo -n ls 进行权限检查）
  • pg-backup 脚本笔误修复

调整优化

  • 移除 NTP 合理性检查警报（与 ClockSkew 重复）
  • 移除 collector.systemd 以减少开销

2.10 - 开箱即用的PGSQL发行版Pigsty —— v1.0 beta发布

原文发布于 VONNG。

经过了半个月的 Alpha 阶段，Pigsty 于 7 月 15 日发布了v1.0.0-beta，并进入功能冻结状态，进行最后的生产测试。不出意外的话v1.0.0 GA将于2021-07-31如期与大家见面。

v1.0.0-beta 监控系统的公开 Demo 已经上线：http://g.pigsty.cc

Pigsty 里程碑记

一年多的时间，一个人的力量，Pigsty 能走到现在这一步，已经远远超过了我的预期。

最开始它只是一个用来演示概念的沙箱环境，随即又成为我自己用来管理数据库的软件。后来又经过一年多的打磨，现在已经成为一个通用的、完整的，解决实际问题的软件产品，被不同行业的用户真正运行在生产环境中。而其定位也从监控系统和演示沙箱，发展到了 数据库发行版 这样宏大的目标。回头看看，还是很让人感慨的：日积跬步，竟能走到这样的程度。

图片

图：Pigsty 项目里程碑

v1.0.0 是这样一个里程碑：在我自己看来，Pigsty 已经足够好，值得我用自己的声誉来担保它足够好用。在 v1.0.0 以后，我会继续维护 Pigsty，可以承诺 Pigsty 会始终跟上 PostgreSQL 大版本迭代的脚步。毕竟一个开源项目灌注了作者的心血，就像自己的孩子一样。父母总是孩子的港湾，最起码我自己就是最大的用户（200+节点）。不用担心 Pigsty 会死掉，还是有老可以啃的（＾ω＾）

在 v2.0.0 前，现有数据库部署架构上都不再会有变化，毕竟部署好的数据库没几个人会想去折腾，稳定才是最重要的。v1.0.0 后的更新主要会集中在监控系统与基础设施部分，而这一部分是很容易升级的。v1.0.0 后续任何涉及到架构调整的版本都会给出升级的解决方案，所以 1.0.0 可以放心用于生产环境。

v1.0.0 的变化

1.0 相比 0.9 的最大改进，在于完全重制了监控系统，基于 PG 14 设计了全新的指标体系，并基于 Grafana 8.0 对监控面板进行了整体性重制。Pigsty 的监控面板有自己的版本号，而这是第 7 个大版本。

图片

图：重制后的监控系统概览(v7)

相比 v6 30+的监控面板，目前 v7 只是重制了其中的一半左右。一部分专题监控面板没有移植，不过问题不大，因为监控面板本身就是持续更新改进的，后面会进一步充实。而且现阶段的监控面板绝对足以满足日常管理与分析需求。

图片

图：重制前的监控系统概览(v6)

更多关于 v1.0.0 监控系统变化的详情，可以拉到本文末尾查阅。

对于不了解 Pigsty 的朋友，这里我再简单介绍一下这个产品与项目。

Pigsty 简介

图片图片

一句话：Pigsty 是开箱即用的开源 PostgreSQL 发行版。

这里有三个关键字：发行版，开源，开箱即用。

发行版

所谓发行版（Distribution），指的是由数据库内核及其一组软件包组成的数据库整体解决方案。例如，Linux 是一个操作系统内核，而 RedHat，Debian，SUSE 则是基于此内核的操作系统发行版。PostgreSQL 是一个数据库内核，而 Pigsty，BigSQL，Percona，各种云 RDS，则是基于此内核的数据库发行版。

内核非常重要，但用户所接触到的往往都是发行版。Linux 的内核只有几 MB，但整个操作系统安装盘却往往有几 GB的大小。这些软件工具集围绕着内核组成了一整个系统，这样才构成了一个完整可用的操作系统。

数据库亦然。一个在现实世界生产环境运行的数据库，也需要基础设施、运行时、工具来协同数据库内核一同工作。这就是数据库发行版。例如，Oracle，EnterpriseDB，本质上售卖的都不是数据库内核，而是数据库发行版，或者更进一步，运行中的数据库发行版服务（各种云数据库）。因为采用了友善的协议，有很多数据库发行版都是基于 PostgreSQL 内核的：

图片

图：PostgreSQL 及其衍生数据库发行版

（顺带一提，“国产数据库”的半壁江山都是 PostgreSQL 换皮，不在此列）

PostgreSQL 是世界上最先进的开源关系型数据库，它是一个接近完美的数据库内核，比肩 Oracle，代码严谨，设计优雅，功能丰富，具有强大的可扩展性，更重要的是采用类 BSD 协议开源，让所有人都可以免费获取到最先进的数据库内核。

但只有内核是远远不够的，PostgreSQL 的生态系统里缺少一个开源的数据库发行版，而 Pigsty 便旨在填补这一空白生态位。

一个发行版就像一颗鸡蛋，有蛋壳（品牌），蛋清（软件工具），蛋黄（内核）。有一些优秀的数据库厂商，例如 Postgres Pro，EnterpriseDB，在**蛋黄（内核）上做了很多工作。而一些数据库厂商，则是在蛋壳（换皮）**上钻研。有的厂商比较中庸，几样都粘一点，内核稍微改一点，在蛋清上做一些自己的管理软件，然后套上蛋壳。

Pigsty 的工作主要集中于蛋清部分，它的内核就是纯粹的原生 PostgreSQL，它的核心定位就是向用户交付开源的，开箱即用的数据库解决方案。

图片

图：Pigsty 数据库发行版

**

Pigsty 并集成打包了 PG 生态中最强大的三个扩展插件：地理空间 PostGIS，时序数据 Timescale，分布式集群 Citus，这几个每一个都足以视作一个新数据库内核，但它们仍然选择拥抱 PostgreSQL，成为一个 PG 的的扩展插件。

作为一个数据库发行版，Pigsty 区别于其他发行版的五个核心特性为：

  • 全面专业的监控系统

  • 稳定可靠的部署方案

  • 简单省心的用户界面

  • 灵活开放的扩展机制

  • 免费友好的开源协议

更多关于 Pigsty 的介绍，可参阅 开箱即用的 PostgreSQL 发行版：Pigsty

开箱即用

所谓 开箱即用（Battery-Included），就是说用户现在有一台刚装完系统的虚拟机，一行命令，在 10 分钟内完成基础设施、数据库，监控系统，管控平台的安装，立刻进入生产可用状态。

更直截了当的说，让大规模数据库集群的部署实施，管理运维，设计使用这种门槛很高的事情，成为普通 DBA/Dev/Ops 几分钟就能搞定的事情。

降低数据库的使用门槛，核心就是两件事：部署 与 监控，以 TiDB 类比的话，就是 tiup 和 tidashboard 这样的组件。所以，Pigsty 的核心功能聚焦在供给方案与监控系统这两个部分：面向专业用户，提供最全面专业的监控系统；面向大众用户，提供最简单易用的供给方案。

监控系统

图片

Pigsty 是一个数据库管理工具，核心用户群是 DBA，以及 Dev 与 Ops。管理数据库当然也是算管理，遵循管理学一般原理。

什么叫管理？从词源理解，通过施加控制（管）使得事物按规律（理）运行。实行有效控制，最重要的就是有 Measurement。正如名言所说：“you can’t manage what you can’t measure”。想要管理任何事物，都要先获取信息，对关键指标进行度量，才能采取正确的行动。监控监控，监就是看，控就是管。用什么看？监控系统。所以说，监控系统是管理的核心工具，是进行有效管理的基本要求。

当然按这种思路的话，健康码通信大数据是监控系统，金盾天网智慧城市是监控系统，核磁共振/CT 扫描也是监控系统。全知即全能，只有对数据库中所有指标了然于胸，才能真正将数据库玩弄于股掌之中。人与动物的最大区别就是人会使用工具，而高效的管理需要趁手的工具。

一个典型的 Pigsty 部署可以管理几百套数据库集群，采集上千类指标，秒级抓取百万级时间序列，精心组织为几百个监控面板，交织于几十个 Dashboard 中实时呈现。\

如果说传统的数据库巡检就像听诊器，血压计之类的赤脚大仙级装备，那么Pigsty 就是数据库监控的核磁共振/CT 机，而且是实时出片，把整个数据库的方方面面剖析的明明白白。

在监控这一点上，在我的已知范围内，Pigsty 在这个细分领域做到了世界最好。即使是商业产品，目前也没看到在可观测性上有任何可以构成替代的产品。

说到底，Pigsty 就是源于没有能满足我需求的产品，我才自己去做的。我行我上，这一点还是比较让人自豪的。

部署与管控

图片

当然，Pigsty 不仅仅是监控系统，它还是一套“供给方案”。“管理”这件事是有一个主体的：如果没有数据库本身，那么再好的监控系统也无用武之地。所以 Pigsty 集成了一套完整的数据库解决方案，这个解决方案主要关注易用性的问题。说到底，很多人管理数据库还处于原始人阶段。差不多类似于

yum install postgresql13 && systemctl start postgresql

这样子肯定是不行的，自己玩一玩是没有问题的，但在真实生产环境中这样用就是在埋地雷。运气好马照跑舞照跳，运气差，就是救火删库跑路上吊。

但是太复杂的东西，新手也不会用。而 Pigsty 供给方案主打的特色就是便利，概括一下就是：一台机器（2 核 2G），一条命令，10 分钟，全家桶就位。提供类似于Postgres.app，minikube，tiup这样的丝滑体验。将创建/销毁集群，集群扩缩容，用户/数据库管理这几个核心功能做到极致，在 PostgreSQL 数据库管理这个细分领域比 Kubernetes 还简单好用得多才行。

以安装为例 

git clone https://github.com/Vonng/pigsty && cd pigsty && ./configure && make install

同样是一行命令的安装，Pigsty 就能在你的环境中部署一整套完整的生产级解决方案。那肯定是比 yum install && systemctl start 要高到不知道哪里去了。

图片图片

图：Pigsty 单节点架构图

以部署为例

Pigsty 部署的数据库集群都是高可用、故障自愈、自带连接池、负载均衡、服务发现，完整监控，几乎无需人工介入。而且集群中的每个成员从效果上讲是等价的。任何一个成员都以提供所有服务（读写/只读）。只要集群中还有一个实例存活，整个集群对外提供的服务就不会中断。感觉上就像是在用分布式数据库一样。

图片

图：Pigsty 部署的数据库集群（沙箱 pg-test 三节点演示集群）

而新增这样一套数据库所需的配置工作也少的可怜，基本上只需告诉 Pigsty 你想在哪几台机器上部署一个集群，里面有什么数据库和什么用户这样的最基础的信息。\

图片

然后执行命令即可根据配置文件创建出数据库集群来

bin/createpg   pg-test       # 创建pg-test集群
bin/createuser pg-test test  # 在pg-test集群中创建test用户
bin/createdb   pg-test test  # 在pg-test集群中创建test数据库

对于专业用户来说，有着 160+参数可以对数据库与运行时基础设施进行精细的定制。对于新手小白，什么都不配置也可以创建出非常不错的数据库：带有基本的用户角色，权限系统，配置好了所有默认权限，安装好了常用的扩展。Citus，TimescaleDB，PostGIS 这些的强力扩展也可以在配置中指定安装，或使用 CREATE EXTENSION 事后一键安装。

图片

图：如果你真的连命令都懒得敲，这儿还有个可行的 GUI/CLI 工具

在管控部署这一点上，我自认为在易用性上做到了极致。在系统设计中把面向用户的复杂度压到了最小的程度：你只要有台机器（甚至只要有自己的笔记本），会敲一行命令就可以搞数据库了。Pigsty 可以说让世界上最先进的开源关系型数据库 PostgreSQL 的使用门槛降低到了一个全新高度。这也是一件值得自豪的事情。

开源

图片

Once open source gets good enough, competing with it would be insane.

Larry Ellison —— Oracle CEO

在软件行业，开源是一种大趋势，互联网的历史就是开源软件的历史，IT 行业之所以有今天的繁荣，人们能享受到如此多的免费信息服务，核心原因之一就是开源软件。开源是一种真正成功的，由开发者构成的 communism（译成社区主义会更贴切）：软件这种 IT 业的核心生产资料变为全世界开发者公有，人人为我，我为人人。

一个开源程序员工作时，其劳动背后其实可能蕴含有数以万计的顶尖开发者的智慧结晶。通过开源，所有社区开发者形成合力，极大降低了重复造轮子的内耗。使得整个行业的技术水平以匪夷所思的速度向前迈进。开源的势头就像滚雪球，时至今日已经势不可挡。除了一些特殊场景和路径依赖，软件开发中闭门造车搞自力更生已经成了一个大笑话。

依托开源，回馈开源。Pigsty 采用了友好的 Apache License 2.0，可以免费用于商业目的。Pigsty 永远欢迎任何人的反馈与贡献。只要遵守 Apache 2 License 的显著声明条款，也欢迎云厂商与软件厂商集成与二次研发商用。

A system cannot be successful if it is too strongly influenced by a single person. Once the initial design is complete and fairly robust, the real test begins as people with many different viewpoints undertake their own experiments.

— Donald Knuth

发展规划

Pigsty 有极大的 Potential，假以时间与资源，它可以成为一个 Game Changing 的开源项目。例如：

Pigsty 可以选择专注于产出更多更丰富的监控面板，做最好的开源 PG 监控系统；

制作一系列基于此的数据应用与数据分析 &可视化作品，进一步丰富应用场景与案例；

添加对 PostgreSQL衍生版本的支持，例如 Citus，Greenplum，PipelineDB，openGauss

专注于容化与 Kubernetes Operator 开发，拥抱云原生；

提高操作系统兼容性，支持 SUSE（已有），Debian，Ubuntu 等其他 Linux 发行版；

选择海纳百川，用同一套现成的运行时监控管理其他开源数据库。

这些都是很有价值的事情，而且不仅仅是 PostgreSQL，也可以把 Redis（已有），MongoDB，甚至是 MySQL 都搞进来。让所有有意愿的用户用好数据库，用好数据库。形成合力，掀翻云厂商垄断，让优质的数据库重新成为人人可以拥有，人人可以使用的自由软件。

但即使最为天才的个人，也难以在合理的时间内完成这么多任务。只有凝聚社区的力量，才能将这样的事情推进下去。v1.0.0 就是这样一个里程碑：Pigsty 已经足够成熟，作为一个成年的项目，将走出自己的道路。1.0 后，我将逐渐专注于 Pigsty 社区建设与推广，顺便修养一段时间。这个项目能走到哪一步，就让我们拭目以待吧！

如果有什么问题，欢迎 加入 Pigsty 交流群。

了解最新进展，体验最新特性，答疑与故障排查，吹牛唠嗑灌水。

图片

Pigsty v1.0.0 监控系统变更

兼容性

v6 与 v7 的监控面板并不兼容。主要原因有二：第一是使用的监控指标体系发生了显著变化。第二是底层基础设施 Grafana 从 v7 升级到了 v8，这是一个重大版本变化（甚至连开源协议都改了）。但个人认为 Grafana 8.0 带来的用户体验改善非常显著的，还是很值得升级的，很多图表重制后给人完全不一样的感受。

图片

图：新监控系统首页

设计风格变更

Pigsty 监控面板（v7）基于 Grafana 8.0 提供的诸多新特性彻底重制。采用了新的设计风格，给人带来焕然一新的用户体验。另外，这一版基于用户反馈采用了新的分级设计与主题化拆分理念：所有的导航监控面板（Overview，Cluster，Instance，Database）都比较简洁，只呈现关键核心指标，并提供到专门主题监控面板的导航。

图片

图：新的 PGSQL Cluster 监控面板

可以从这里直接前往集群内的：实例，节点，服务，负载均衡器，数据库，告警，流量管理界面

主题化面板

采用简洁导航+专业主题面板的一个好处就是，普通开发者和新人用户不会因为海量的监控指标与面板感到困扰，而专业用户则仍然可以通过进入主题面板获取所有的细节信息。拆分后的主题面板更为紧凑专注，因此打开与渲染速度更快，而且可以围绕一类核心问题快速给出洞察。

图片

图：新的 PGSQL Queries 主题面板，关注单个实例内的所有查询类指标

图片

图：新的 PGSQL Session 主题面板，关注单个实例内的所有会话类指标\

交互式导航

v1.0 监控面板最给力的改进是：绝大多数监控图表现在都可以进行交互点击了。例如在上图中，如果您从饼图中发现某一个查询执行所耗费的时间非常显著，希望查阅该查询的详细指标。那么只要点击对应的图形元素即可跳转至 PGSQL Query 面板并加载对应查询的数据。

以往当我们从图表中发现异常值时，通常要从图例中找到这个查询的 ID，然后再手工查找或复制 ID 执行查询。现在就可以直接点击图形元素「点、线、面」跳转。用户体验有了飞跃式的提升。

图片

****图：新的 PGSQL Database 监控面板，可直接跳转至表或查询的详情 ****

用户可以快速进行下钻上卷横跳，而跳转也不仅仅局限在 Grafana 中。比如，可以直接点击负载均衡器跳转到 Haproxy 流量管理界面，也可以点击报警事件条直接跳转到AlertManager查阅或直接屏蔽告警。\

图片

自动注册数据源

在 1.0 中，所有由 Pigsty 托管的 PostgreSQL 都会在创建数据库与集群时，自动注册 PostgreSQL 数据源至 Grafana

图片

图：自动注册的 PG 数据源，名称为：ins.db

这带来了很多新的可能性，例如：直接从监控系统中查阅浏览系统目录，获取关于某一个具体的表和某一类查询的详细信息，目录数据与监控系统中的指标数据可以相互印衬，提供更全面的信息。一个典型的场景就是：用户不需要登陆数据库查阅pg_stat_statements以将 QueryID 转换为具体的 SQL 语句了。

图片

图：CATATLOG 视角下的查询（包含语句与历史统计）

点击 QueryID 可以跳转至 Metrics 视角下的查询

图片

图：Metrics 视角下的查询指标，可以与 Catalog 交叉对比。

关注单个表的详情的 PGSQL Table 监控面板。详细展示了一张表上的增删改查，扫描与访问，IO 与命中率，垃圾清理与分析活动，所有相关索引以及其上的访问，与表相关的函数与序列号相关访问指标。同时点击 Relation 还可以跳转到 PGCAT Table 从数据字典的角度查阅这张表的详细信息。

图片

图：新的 PGSQL Table 主题面板，从监控指标的角度分析表********\

图片

图：新的 PGCAT Table 主题面板，从系统目录的角度分析表\

使用 PGLOG 应用分析 CSVLOG 样本

尽管基于Loki与Promtail的 PGLOG Instance 监控面板已经允许用户实时查询与搜索数据库日志（Postgres，Pgbouncer，Patroni）。但 grep 毕竟功能有限，对于更进一步的精细分析则有些力不从心。一个典型的场景就是故障现场的日志分析，靠人眼看原始日志是很低效的。但是通过 Pigsty v1.0 内置的新应用 pglog，我们就可以快速定位问题日志，并使用 SQL 对日志进行深度处理与分析。

pglog 是一个分析 PG CSV 日志的数据应用。您只需要在管理节点上使用一条简单的命令，即可将数据库日志导入 Pigsty MetaDB 中进行分析：

# 获取当前节点当天的日志

catlog | pglog\

# 获取特定节点node-1具体某一天2021-07-15的日志

catlog node-1 ‘2021-07-15’ | pglog

# 实际上干的事情就是把CSV日志灌入样本

COPY pglog.sample FROM STDIN CSV;
图片

图：PGLOG Analysis 面板，基于日志样本进行分析并呈现

点击左上方的 AutoZoom 按钮即可将时间轴缩放至日志样本的时间范围上。

这里，用户可以在日志分布图上直接拖选时间范围，几次缩放就可以定位到毫秒级现场。通过 TimePickle 快速筛选，日志也会随之联动。发现错误日志后，可以点击日志项的 Session ID 字段连接，跳转到 PGLOG Session 面板查阅错误发生时的上下文详情。

图片

**\

图：PGLOG Session 面板，专注于日志样本中的单条连接

PG Session 会展示这条数据库连接相关的所有日志，并将日志事件以 Annotation 注解的方式显示在图表上。

使用注解

Grafana 提供了 注解（Annotation） 机制用于呈现离散事件。在 Pigsty v1.0.0 中，诸如表的垃圾回收（Vacuum），实例的检查点（Checkpoint） 都会使用注解的方式标记在图标上。

图片

图：关注单个实例持久化主题的 PGSQL Persist 面板

使用蓝线标注周期性检查点，使用红线标注手工检查点。

例如，PostgreSQL Checkpoint 会使一些指标出现显著抖动。将 Checkpoint 事件标记在图标上，可以让用户一眼识别出指标的变化是否来自检查点，从而提高问题定位的效率。

报警规则重制

Pigsty v1.0.0 彻底梳理了所有的告警规则，现在告警系统有两种等效实现：Prometheus + AlertManager，以及 Grafana。前者更为专业，可定制化更强，便于与外部系统对接；后者更为灵活方便，可以集成不同数据源进行报警，并在告警消息中附带截图与连接。您可以同时使用这两种告警系统，互为备份。

图片

图：PGSQL Alert 面板

其他有趣的改进

限于篇幅，这里就不再一一列出。更多信息，敬请关注本公众号，Github Repo

，官方文档站，或加入末尾的微信群。

发布版本：微信公众号

2.11 - 开箱即用的PG发行版：Pigsty

原文发布于 VONNG。

什么是Pigsty

Pigsty是开箱即用的生产级开源PostgreSQL发行版。

所谓 发行版（Distribution），指的是由数据库内核及其一组软件包组成的数据库整体解决方案。例如，Linux是一个 操作系统内核，而RedHat，Debian，SUSE则是基于此内核的 操作系统发行版。PostgreSQL是一个 数据库内核，而 Pigsty，BigSQL，Percona，各种云RDS，换皮数据库则是基于此内核的 数据库发行版。

Pigsty区别于其他数据库发行版的五个核心特性为：

  • 全面专业 的 监控系统
  • 稳定可靠 的 部署方案
  • 简单省心的用户界面
  • 灵活开放 的 扩展机制
  • 免费友好 的 开源协议

这五个特性，使得Pigsty真正成为 开箱即用 的PostgreSQL发行版。

谁会感兴趣？

Pigsty面向的用户群体包括：DBA，架构师，OPS，软件厂商、云厂商、业务研发、内核研发、数据研发；对数据分析与数据可视化感兴趣的人；学生，新手程序员，有兴趣尝试数据库的用户。

对于DBA，架构师等专业用户，Pigsty提供了独一无二的 专业级 PostgreSQL监控系统，为数据库管理提供不可替代的价值点。与此同时，Pigsty还带有一个 稳定可靠，久经考验的生产级PostgreSQL部署方案，可在生产环境中自动部署带有监控报警，日志采集，服务发现，连接池，负载均衡，VIP，以及高可用的PostgreSQL数据库集群。

对于研发人员（业务研发、内核研发、数据研发），学生，新手程序员，有兴趣尝试数据库的用户，Pigsty提供了门槛极低，一键拉起，一键安装 的 本地沙箱。本地沙箱除机器规格外与生产环境完全一致，包含完整的功能：带有开箱即用的数据库实例与监控系统。可用于学习，开发，测试，数据分析等场景。

此外，Pigsty提供了一种称为“Datalet”的灵活扩展机制 。对数据分析与数据可视化感兴趣的人可能会惊讶地发现，Pigsty还可以作为数据分析与可视化的集成开发环境。Pigsty集成了PostgreSQL与常用的数据分析插件，并带有Grafana和内嵌的Echarts支持，允许用户编写，测试，分发数据小应用（Datalet）。如：“Pigsty监控系统的额外扩展面板包”，“Redis监控系统”，“PG日志分析系统”，“应用监控”，“数据目录浏览器”等。

最后，Pigsty采用了免费友好的Apache License 2.0，可以免费用于商业目的。只要遵守Apache 2 License的显著声明条款，也欢迎云厂商与软件厂商集成与二次研发商用。

全面专业的监控系统

You can’t manage what you don’t measure.

— Peter F.Drucker

Pigsty提供 专业级 监控系统，面向专业用户提供不可替代的价值点。

以医疗器械类比，普通监控系统 类似于心率计、血氧计，普通人无需学习也可以上手。它可以给出患者生命体征核心指标：起码用户可以知道人是不是要死了，但对于看病治病无能为力。例如，各种云厂商软件厂商提供的监控系统大抵属于此类：十几个核心指标，告诉你数据库是不是还活着，让人大致有个数，仅此而已。

专业级 监控系统则类似于CT，核磁共振仪，可以检测出对象内部的全部细节，专业的医师可以根据CT/MRI报告快速定位疾病与隐患：有病治病，没病健体。Pigsty可以深入审视每一个数据库中的每一张表，每一个索引，每一个查询，提供巨细无遗的全面指标（1155类），并通过几千个仪表盘将其转换为 洞察：将故障扼杀在萌芽状态，并为性能优化提供 实时反馈。

Pigsty监控系统基于业内最佳实践，采用Prometheus、Grafana作为监控基础设施。开源开放，定制便利，可复用，可移植，没有厂商锁定。可与各类已有数据库实例集成。

稳定可靠的部署方案

A complex system that works is invariably found to have evolved from a simple system that works.

—John Gall, Systemantics (1975)

数据库是管理数据的软件，管控系统是管理数据库的软件。

Pigsty内置了一套以Ansible为核心的数据库管控方案。并基于此封装了命令行工具与图形界面。它集成了数据库管理中的核心功能：包括数据库集群的创建，销毁，扩缩容；用户、数据库、服务的创建等。Pigsty采纳“Infra as Code”的设计哲学使用了声明式配置，通过大量可选的配置选项对数据库与运行环境进行描述与定制，并通过幂等的预置剧本自动创建所需的数据库集群，提供近似私有云般的使用体验。

Pigsty创建的数据库集群是 分布式、高可用 的数据库集群。Pigsty创建的数据库基于DCS、Patroni、Haproxy实现了高可用。数据库集群中的每个数据库实例在 使用 上都是 幂等 的，任意实例都可以通过内建负载均衡组件提供完整的读写服务，提供分布式数据库的使用体验。数据库集群可以自动进行故障检测与主从切换，普通故障能在几秒到几十秒内自愈，且期间只读流量不受影响。故障时。集群中只要有任意实例存活，就可以对外提供完整的服务。

Pigsty的架构方案经过审慎的设计与评估，着眼于以最小复杂度实现所需功能。该方案经过长时间，大规模的生产环境验证，已经被互联网/B/G/M/F多个行业内的组织所使用。

简单省心的用户界面

Pigsty旨在降低PostgreSQL的使用门槛，因此在易用性上做了大量工作。

安装部署

Someone told me that each equation I included in the book would halve the sales.

— Stephen Hawking

Pigsty的部署分为三步：下载源码，配置环境，执行安装，均可通过一行命令完成。遵循经典的软件安装模式，并提供了配置向导。您需要准备的只是一台CentOS7.8机器及其root权限。管理新节点时，Pigsty基于Ansible通过ssh发起管理，无需安装Agent，即使是新手也可以轻松完成部署。

Pigsty既可以在生产环境中管理成百上千个高规格的生产节点，也可以独立运行于本地1核1GB虚拟机中，作为开箱即用的数据库实例使用。在本地计算机上使用时，Pigsty提供基于Vagrant与Virtualbox的 沙箱。可以一键拉起与生产环境一致的数据库环境，用于学习，开发，测试数据分析，数据可视化等场景。

用户接口

Clearly, we must break away from the sequential and not limit the computers. We must state definitions and provide for priorities and descriptions of data. We must state relation‐ ships, not procedures.

—Grace Murray Hopper, Management and the Computer of the Future (1962)

Pigsty吸纳了Kubernetes架构设计中的精髓，采用声明式的配置方式与幂等的操作剧本。用户只需要描述“自己想要什么样的数据库”，而无需关心Pigsty如何去创建它，修改它。Pigsty会根据用户的配置文件清单，在几分钟内从裸机节点上创造出所需的数据库集群。

在管理与使用上，Pigsty提供了不同层次的用户界面，以满足不同用户的需求。新手用户可以使用一键拉起的本地沙箱与图形用户界面，而开发者则可以选择使用 pigsty-cli 命令行工具与配置文件的方式进行管理。经验丰富的DBA、运维与架构师则可以直接通过Ansible原语对执行的任务进行精细控制。

灵活开放的扩展机制

PostgreSQL的 可扩展性（Extensible） 一直为人所称道，各种各样的扩展插件让PostgreSQL成为了最先进的开源关系型数据库。Pigsty亦尊重这一价值，提供了一种名为“Datalet”的扩展机制，允许用户和开发者对Pigsty进行进一步的定制，将其用到“意想不到”的地方，例如：数据分析与可视化。

当我们拥有监控系统与管控方案后，也就拥有了开箱即用的可视化平台Grafana与功能强大的数据库PostgreSQL。这样的组合拥有强大的威力 —— 特别是对于数据密集型应用而言。用户可以在无需编写前后端代码的情况下，进行数据分析与数据可视化，制作带有丰富交互的数据应用原型，甚至应用本身。

Pigsty集成了Echarts，以及常用地图底图等，可以方便地实现高级可视化需求。比起Julia，Matlab，R这样的传统科学计算语言/绘图库而言，PG + Grafana + Echarts的组合允许您以极低的成本制作出 可分享，可交付，标准化 的数据应用或可视化作品。

Pigsty监控系统本身就是Datalet的典范：所有Pigsty高级专题监控面板都会以Datalet的方式发布。Pigsty也自带了一些有趣的Datalet案例：Redis监控系统，新冠疫情数据分析，七普人口数据分析，PG日志挖掘等。后续还会添加更多的开箱即用的Datalet，不断扩充Pigsty的功能与应用场景。

免费友好的开源协议

Once open source gets good enough, competing with it would be insane.

Larry Ellison —— Oracle CEO

在软件行业，开源是一种大趋势，互联网的历史就是开源软件的历史，IT行业之所以有今天的繁荣，人们能享受到如此多的免费信息服务，核心原因之一就是开源软件。开源是一种真正成功的，由开发者构成的communism（译成 社区主义 会更贴切）：软件这种IT业的核心生产资料变为全世界开发者公有，人人为我，我为人人。

一个开源程序员工作时，其劳动背后其实可能蕴含有数以万计的顶尖开发者的智慧结晶。通过开源，所有社区开发者形成合力，极大降低了重复造轮子的内耗。使得整个行业的技术水平以匪夷所思的速度向前迈进。开源的势头就像滚雪球，时至今日已经势不可挡。除了一些特殊场景和路径依赖，软件开发中闭门造车搞自力更生已经成了一个大笑话。

依托开源，回馈开源。Pigsty采用了友好的Apache License 2.0，可以免费用于商业目的。只要遵守Apache 2 License的显著声明条款，也欢迎云厂商与软件厂商集成与二次研发商用。

关于Pigsty

A system cannot be successful if it is too strongly influenced by a single person. Once the initial design is complete and fairly robust, the real test begins as people with many different viewpoints undertake their own experiments. — Donald Knuth

Pigsty围绕开源数据库PostgreSQL而构建，PostgreSQL是世界上 最先进的开源关系型数据库，而Pigsty的目标就是：做 最好用的开源PostgreSQL发行版。

在最开始时，Pigsty并没有这么宏大的目标。因为在市面上找不到任何满足我自己需求的监控系统，因此我只好自己动手，丰衣足食，给自己做了一个监控系统。没有想到它的效果出乎意料的好，有不少外部组织PG用户希望能用上。紧接着，监控系统的部署与交付成了一个问题，于是又将数据库部署管控的部分加了进去；在生产环境应用后，研发希望能在本地也有用于测试的沙箱环境，于是又有了本地沙箱；有用户反馈ansible不太好用，于是就有了封装命令的 pigsty-cli 命令行工具；有用户希望可以通过UI编辑配置文件，于是就有了Pigsty GUI。就这样，需求越来越多，功能也越来越丰富，Pigsty也在长时间的打磨中变得更加完善，已经远远超出了最初的预期。

做这件事本身也是一种挑战，做一个发行版有点类似于做一个RedHat，做一个SUSE，做一个“RDS产品”。通常只有一定规模的专业公司与团队才会去尝试。但我就是想试试，一个人可不可以？实际上除了慢一点，也没什么不可以。一个人在产品经理、开发者，终端用户的角色之间转换是很有趣的体验，而“Eat dog food”最大的好处就是，你自己既是开发者也是用户，你了解自己需要什么，也不会在自己的需求上偷懒。

不过，正如高德纳所说：“带有太强个人色彩的系统无法成功”。 要想让Pigsty成为一个具有旺盛生命力的项目，就必须开源，让更多的人用起来。“当最初的设计完成并足够稳定后，各式各样的用户以自己的方式去使用它时，真正的挑战才刚刚开始”。

Pigsty很好的解决了我自己的问题与需求，现在我希望它可以帮助到更多的人，并让PostgreSQL的生态更加繁荣，更加多彩。

2.12 - Pigsty v0.9：GUI/CLI与日志集成

原文发布于 VONNG。

GitHub Release | 发布注记

v0.9.0

新功能

  • 一键安装模式：

    /bin/bash -c "$(curl -fsSL https://pigsty.cc/install)"

  • 开发命令行工具 pigsty-cli 封装常用Ansible命令，目前pigsty-cli处于Beta状态

  • 使用Loki与Promtail收集日志：

    • 默认收集Postgres，Pgbouncer，Patroni日志
    • 新增部署脚本 infra-loki.yml 与 pgsql-promtail.yml
    • 定义基于日志的监控指标
    • 使用Grafana制作日志相关可视化面板。

  • 监控组件可以使用二进制安装，使用 files/get_bin.sh 下载监控二进制组件。

  • 飞升模式：

    当集群元节点初始化完成后，可以使用 bin/upgrade 升级为动态Inventory

    使用pg-meta上的数据库代替YAML配置文件。

问题修复

  • 集中修复日志相关问题：

    • 修复了HAProxy健康检查造成PG日志中大量 connection reset by peer 的问题。
    • 修复了HAProxy健康检查造成Patroni日志中大量出现 Connect Reset Exception的问题
    • 修复了Patroni日志时间戳格式，去除毫秒时间戳，附加完整时区信息。
    • 为 dbuser_monitor 配置1秒的 log_min_duration_statement，避免监控查询出现在日志中。

  • 重构Grafana角色

    • 在保持API不变的前提下重构Grafana角色。
    • 使用CDN下载预打包的Grafana插件，加速插件下载

  • 其他问题修复

    • 修复了 pgbouncer-create-user 未能正确处理 md5 密码的问题。
    • 完善了数据库与用户创建SQL模版中参数空置检查。
    • 修复了 NODE DNS配置时如果手工中断执行，DNS配置可能出错的问题。
    • 重构了Makefile快捷方式 Makefile 中的错别字

参数变更

  • node_disable_swap 默认为 False，默认不会关闭SWAP。
  • node_sysctl_params 不再有默认修改的系统参数。
  • grafana_plugin 的默认值 install 现在意味着当插件缓存不存在时，从CDN下载。
  • repo_url_packages 现在从 Pigsty CDN 下载额外的RPM包，解决墙内无法访问的问题。
  • proxy_env.no_proxy 现在将Pigsty CDN加入到NOPROXY列表中。
  • grafana_customize 现在默认为 false，启用意味着安装Pigsty Pro版UI（默认不开源所以不要启用）
  • node_admin_pk_current，新增选项，启用后会将当前用户的 ~/.ssh/id_rsa.pub 添加至管理员的Key中
  • loki_clean：新增选项，安装Loki时是否清除现有数据
  • loki_data_dir：新增选项，指明安装Loki时的数据目录
  • promtail_enabled 是否启用Promtail日志收集服务？
  • promtail_clean 是否在安装promtail时移除已有状态信息？
  • promtail_port promtail使用的默认端口，默认为9080
  • promtail_status_file 保存Promtail状态信息的文件位置
  • promtail_send_url 用于接收日志的loki服务endpoint

2.13 - Pigsty v0.8：服务供给

原文发布于 VONNG。

GitHub Release | 发布注记

v0.8.0

v0.8 针对 服务（Service） 接入部分进行了彻底的重做。现在除了默认的 primary, replica 服务外，用户可以自行定义新的服务。服务的接口可以支持多种不同的实现，例如L4 DPKG VIP可作为Haproxy的替代品与Pigsty集成。同时，针对用户反馈的一些问题进行了集中处理与改进。

改动内容

v0.8是供给方案定稿版本，此后供给系统的API将保持稳定。

API变更

原有 vip 与 haproxy 角色的所有配置项，现在迁移至 service 角色中。

#------------------------------------------------------------------------------
# SERVICE PROVISION
#------------------------------------------------------------------------------
pg_weight: 100              # default load balance weight (instance level)

# - service - #
pg_services:                                  # how to expose postgres service in cluster?
  # primary service will route {ip|name}:5433 to primary pgbouncer (5433->6432 rw)
  - name: primary           # service name {{ pg_cluster }}_primary
    src_ip: "*"
    src_port: 5433
    dst_port: pgbouncer     # 5433 route to pgbouncer
    check_url: /primary     # primary health check, success when instance is primary
    selector: "[]"          # select all instance as primary service candidate

  # replica service will route {ip|name}:5434 to replica pgbouncer (5434->6432 ro)
  - name: replica           # service name {{ pg_cluster }}_replica
    src_ip: "*"
    src_port: 5434
    dst_port: pgbouncer
    check_url: /read-only   # read-only health check. (including primary)
    selector: "[]"          # select all instance as replica service candidate
    selector_backup: "[? pg_role == `primary`]"   # primary are used as backup server in replica service

  # default service will route {ip|name}:5436 to primary postgres (5436->5432 primary)
  - name: default           # service's actual name is {{ pg_cluster }}-{{ service.name }}
    src_ip: "*"             # service bind ip address, * for all, vip for cluster virtual ip address
    src_port: 5436          # bind port, mandatory
    dst_port: postgres      # target port: postgres|pgbouncer|port_number , pgbouncer(6432) by default
    check_method: http      # health check method: only http is available for now
    check_port: patroni     # health check port:  patroni|pg_exporter|port_number , patroni by default
    check_url: /primary     # health check url path, / as default
    check_code: 200         # health check http code, 200 as default
    selector: "[]"          # instance selector
    haproxy:                # haproxy specific fields
      maxconn: 3000         # default front-end connection
      balance: roundrobin   # load balance algorithm (roundrobin by default)
      default_server_options: 'inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100'

  # offline service will route {ip|name}:5438 to offline postgres (5438->5432 offline)
  - name: offline           # service name {{ pg_cluster }}_replica
    src_ip: "*"
    src_port: 5438
    dst_port: postgres
    check_url: /replica     # offline MUST be a replica
    selector: "[? pg_role == `offline` || pg_offline_query ]"         # instances with pg_role == 'offline' or instance marked with 'pg_offline_query == true'
    selector_backup: "[? pg_role == `replica` && !pg_offline_query]"  # replica are used as backup server in offline service

pg_services_extra: []        # extra services to be added

# - haproxy - #
haproxy_enabled: true                         # enable haproxy among every cluster members
haproxy_reload: true                          # reload haproxy after config
haproxy_policy: roundrobin                    # roundrobin, leastconn
haproxy_admin_auth_enabled: false             # enable authentication for haproxy admin?
haproxy_admin_username: admin                 # default haproxy admin username
haproxy_admin_password: admin                 # default haproxy admin password
haproxy_exporter_port: 9101                   # default admin/exporter port
haproxy_client_timeout: 3h                    # client side connection timeout
haproxy_server_timeout: 3h                    # server side connection timeout

# - vip - #
vip_mode: none                                # none | l2 | l4
vip_reload: true                              # whether reload service after config
# vip_address: 127.0.0.1                      # virtual ip address ip (l2 or l4)
# vip_cidrmask: 24                            # virtual ip address cidr mask (l2 only)
# vip_interface: eth0                         # virtual ip network interface (l2 only)

新增选项

# - localization - #
pg_encoding: UTF8                             # default to UTF8
pg_locale: C                                  # default to C
pg_lc_collate: C                              # default to C
pg_lc_ctype: en_US.UTF8                       # default to en_US.UTF8

pg_reload: true                               # reload postgres after hba changes
vip_mode: none                                # none | l2 | l4
vip_reload: true                              # whether reload service after config

移除选项

haproxy_check_port                            # Haproxy相关参数已经被Service定义覆盖
haproxy_primary_port
haproxy_replica_port
haproxy_backend_port
haproxy_weight
haproxy_weight_fallback
vip_enabled                                   # vip_enabled参数被vip_mode覆盖

服务管理

pg_services 与 pg_services_extra 定义了集群中的 服务，每一个服务的定义结构如下例所示：

一个服务必须指定以下内容：

  • 名称：服务的完整名称以数据库集群名为前缀，以 service.name 为后缀，通过 - 连接。例如在 pg-test 集群中 name=primary 的服务，其完整服务名称为 pg-test-primary。

  • 端口：在Pigsty中，服务默认采用NodePort的形式对外暴露，因此暴露端口为必选项。但如果使用外部负载均衡服务接入方案，您也可以通过其他的方式区分服务。

  • 选择器：选择器指定了服务的成员，采用JMESPath的形式，从所有集群实例成员中筛选变量。默认的 [] 选择器会选取所有的集群成员。

    此外 selector_backup 会选择或标记用于backup的实例列表（当集群中所有其他成员失效时方才接管服务）

  # default service will route {ip|name}:5436 to primary postgres (5436->5432 primary)
  - name: default           # service's actual name is {{ pg_cluster }}-{{ service.name }}
    src_ip: "*"             # service bind ip address, * for all, vip for cluster virtual ip address
    src_port: 5436          # bind port, mandatory
    dst_port: postgres      # target port: postgres|pgbouncer|port_number , pgbouncer(6432) by default
    check_method: http      # health check method: only http is available for now
    check_port: patroni     # health check port:  patroni|pg_exporter|port_number , patroni by default
    check_url: /primary     # health check url path, / as default
    check_code: 200         # health check http code, 200 as default
    selector: "[]"          # instance selector
    haproxy:                # haproxy specific fields
      maxconn: 3000         # default front-end connection
      balance: roundrobin   # load balance algorithm (roundrobin by default)
      default_server_options: 'inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100'

数据库管理

数据库现在可以对locale的细分选项：lc_ctype 与 lc_collate 分别进行指定。支持这一功能的主要原因是PG的扩展插件 pg_trgm 需要在 lc_ctype!=C 的环境中才能正常支持中文。

旧接口定义 

pg_databases:
  - name: meta                      # name is the only required field for a database
    owner: postgres                 # optional, database owner
    template: template1             # optional, template1 by default
    encoding: UTF8                  # optional, UTF8 by default
    locale: C                       # optional, C by default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

新的接口定义 

pg_databases:
  - name: meta                      # name is the only required field for a database
    # owner: postgres                 # optional, database owner
    # template: template1             # optional, template1 by default
    # encoding: UTF8                # optional, UTF8 by default , must same as template database, leave blank to set to db default
    # locale: C                     # optional, C by default , must same as template database, leave blank to set to db default
    # lc_collate: C                 # optional, C by default , must same as template database, leave blank to set to db default
    # lc_ctype: C                   # optional, C by default , must same as template database, leave blank to set to db default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    # tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

2.14 - Pigsty v0.7：仅监控部署

原文发布于 VONNG。

GitHub Release | 发布注记

v0.7.0

v0.7 针对 接入已有数据库实例 进行了改进，现在用户可以采用 仅监控部署（Monly Deployment） 模式使用Pigsty。同时新增了专用于管理数据库与用户、以及单独部署监控的剧本，并对数据库与用户的定义进行改进。

改动内容

Features

Bug Fix

API变更

新增选项

prometheus_sd_target: batch                   # batch|single    监控目标定义文件采用单体还是每个实例一个
exporter_install: none                        # none|yum|binary 监控Exporter的安装模式
exporter_repo_url: ''                         # 如果设置，这里的REPO连接会加入目标的Yum源中
node_exporter_options: '--no-collector.softnet --collector.systemd --collector.ntp --collector.tcpstat --collector.processes'                          # Node Exporter默认的命令行选项
pg_exporter_url: ''                           # 可选，PG Exporter监控对象的URL
pgbouncer_exporter_url: ''                    # 可选，PGBOUNCER EXPORTER监控对象的URL

移除选项

exporter_binary_install: false                 # 功能被 exporter_install 覆盖

定义结构变更

pg_default_roles                               # 变化细节参考 用户管理。
pg_users                                       # 变化细节参考 用户管理。
pg_databases                                   # 变化细节参考 数据库管理。

重命名选项

pg_default_privilegs -> pg_default_privileges # 很明显这是一个错别字

仅监控模式

有时用户不希望使用Pigsty供给方案，只希望使用Pigsty监控系统管理现有PostgreSQL实例。

Pigsty提供了 仅监控部署（monly, monitor-only） 模式，剥离供给方案部分，可用于监控现有PostgreSQL集群。

仅监控模式的部署流程与标准模式大体上保持一致，但省略了很多步骤

  • 在 元节点 上完成基础设施初始化的部分与标准流程保持一致，仍然通过 ./infra.yml 完成。
  • 不需要在 数据库节点 上完成 基础设施初始化。
  • 不需要在 数据库节点 上执行数据库初始化的绝大多数任务，而是通过专用的 ./pgsql-monitor.yml 完成仅监控系统部署。
  • 实际使用的配置项大大减少，只保留基础设施相关变量，与 监控系统 相关的少量变量。

数据库管理

Database provisioning interface enhancement #33

旧接口定义 

pg_databases:                       # create a business database 'meta'
  - name: meta
    schemas: [meta]                 # create extra schema named 'meta'
    extensions: [{name: postgis}]   # create extra extension postgis
    parameters:                     # overwrite database meta's default search_path
      search_path: public, monitor

新的接口定义 

pg_databases:
  - name: meta                      # name is the only required field for a database
    owner: postgres                 # optional, database owner
    template: template1             # optional, template1 by default
    encoding: UTF8                  # optional, UTF8 by default
    locale: C                       # optional, C by default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

接口变更

  • Add new options: template , encoding, locale, allowconn, tablespace, connlimit
  • Add new option revokeconn, which revoke connect privileges from public for this database
  • Add comment field for database

数据库变更

在运行中集群中创建新数据库可以使用 pgsql-createdb.yml 剧本，在配置中定义完新数据库后，执行以下剧本。

./pgsql-createdb.yml -e pg_database=<your_new_database_name>

通过 -e pg_datbase= 告知需要创建的数据库名称，则该数据库即会被创建（或修改）。具体执行的命令参见集群主库 /pg/tmp/pg-db-{{ database.name}}.sql 文件。

用户管理

User provisioning interface enhancement #34

旧接口定义 

pg_users:
  - username: test                  # example production user have read-write access
    password: test                  # example user's password
    options: LOGIN                  # extra options
    groups: [ dbrole_readwrite ]    # dborole_admin|dbrole_readwrite|dbrole_readonly
    comment: default test user for production usage
    pgbouncer: true                 # add to pgbouncer

新接口定义 

pg_users:
  # complete example of user/role definition for production user
  - name: dbuser_meta               # example production user have read-write access
    password: DBUser.Meta           # example user's password, can be encrypted
    login: true                     # can login, true by default (should be false for role)
    superuser: false                # is superuser? false by default
    createdb: false                 # can create database? false by default
    createrole: false               # can create role? false by default
    inherit: true                   # can this role use inherited privileges?
    replication: false              # can this role do replication? false by default
    bypassrls: false                # can this role bypass row level security? false by default
    connlimit: -1                   # connection limit, -1 disable limit
    expire_at: '2030-12-31'         # 'timestamp' when this role is expired
    expire_in: 365                  # now + n days when this role is expired (OVERWRITE expire_at)
    roles: [dbrole_readwrite]       # dborole_admin|dbrole_readwrite|dbrole_readonly
    pgbouncer: true                 # add this user to pgbouncer? false by default (true for production user)
    parameters:                     # user's default search path
      search_path: public
    comment: test user

接口变更

  • username field rename to name

  • groups field rename to roles

  • options now split into separated configration entries:

    login, superuser, createdb, createrole, inherit, replication,bypassrls,connlimit

  • expire_at and expire_in options

  • pgbouncer option for user is now false by default

用户管理

在运行中集群中创建新数据库可以使用 pgsql-createuser.yml 剧本，在配置中定义完新数据库后，执行以下剧本。

./pgsql-createuser.yml -e pg_user=<your_new_user_name>

通过 -e pg_user= 告知需要创建的数据库名称，则该数据库即会被创建（或修改）。具体执行的命令参见集群主库 /pg/tmp/pg-user-{{ user.name}}.sql 文件。

2.15 - Pigsty v0.6：架构增强

原文发布于 VONNG。

GitHub Release | 发布注记

v0.6.0

v0.6 对数据库供给方案进行了修改与调整，根据用户的反馈添加了一系列实用功能与修正。针对监控系统的移植性进行优化，便于与其他外部数据库供给方案对接，例如阿里云MyBase。

BUG修复

  • 修复了新版本Patroni重启后会重置PG HBA的问题
  • 修复了PG Overview Dashboard标题中的别字
  • 修复了沙箱集群 pg-test 的默认主库，原来为 pg-test-2，应当为 pg-test-1
  • 修复了过时代码注释

功能改进

  • 改造Prometheus与监控供给方式
    • 允许在无基础设施的情况下对已有PG集群进行监控部署，便于监控系统与其他供给方案集成。#11
    • 基于Inventory渲染所有监控对象的静态列表，用于静态服务发现。#11
    • Prometheus添加了静态对象模式，用于替代动态服务发现，集中进行身份管理#11
    • 监控Exporter现在添加了 service_registry 选项，Consul服务注册变为可选项 #13
    • Exporter现在可以通过拷贝二进制的方式直接安装：exporter_binary_install，#14
    • Exporter现在具有 xxx_enabled 选项，控制是否启用该组件。
  • Haproxy供给重构与改进 #8
    • 新增了全局HAProxy管理界面导航，默认域名 h.pigsty
    • 允许将主库加入只读服务集中，当集群中所有从库宕机时自动承接读流量。 #8
    • 允许位Haproxy实例管理界面启用认证 haproxy_admin_auth_enabled
    • 允许通过配置项调整每个服务对应后端的流量权重. #10
  • 访问控制模型改进。#7
    • 添加了默认角色 dbrole_offline，用于慢查询，ETL，交互式查询场景。
    • 修改默认HBA规则，允许 dbrole_offline 分组的用户访问 pg_role == 'offline' 及 pg_offline_query == true 的实例。
  • 软件更新 Release v0.6
    • PostgreSQL 13.2
    • Prometheus 2.25
    • PG Exporter 0.3.2
    • Node Exporter 1.1
    • Consul 1.9.3
    • 更新默认PG源：PostgreSQL现在默认使用浙江大学的镜像，加速下载安装

接口变更

新增选项

service_registry: consul                      # 服务注册机制：none | consul | etcd | both
prometheus_options: '--storage.tsdb.retention=30d'  # prometheus命令行选项
prometheus_sd_method: consul                  # Prometheus使用的服务发现机制：static|consul
prometheus_sd_interval: 2s                    # Prometheus服务发现刷新间隔
pg_offline_query: false                       # 设置后将允许dbrole_offline角色连接与查询该实例
node_exporter_enabled: true                   # 设置后将安装配置Node Exporter
pg_exporter_enabled: true                     # 设置后将安装配置PG Exporter
pgbouncer_exporter_enabled: true              # 设置后将安装配置Pgbouncer Exporter
dcs_disable_purge: false                      # 双保险，强制 dcs_exists_action = abort 避免误删除DCS实例
pg_disable_purge: false                       # 双保险，强制 pg_exists_action = abort 避免误删除数据库实例
haproxy_weight: 100                           # 配置实例的相对负载均衡权重
haproxy_weight_fallback: 1                    # 配置集群主库在只读服务中的相对权重

移除选项

prometheus_metrics_path                       # 与 exporter_metrics_path 重复
prometheus_retention                          # 功能被 prometheus_options 覆盖

2.16 - Pigsty正式发布

原文发布于 VONNG。

今天我很荣幸的宣布，Pigsty 正式发布了！

图片

官方网站：https://pigsty.cc

Pigsty 是什么？

  • Pigsty 是针对大规模 PostgreSQL 集群的监控系统

  • Pigsty 是高可用 PostgreSQL 集群的供给方案

  • Pigsty 基于开源生态构建，是免费的开源软件

图片

Pigsty 针对大规模数据库集群监控与管理而设计，提供业界顶尖的 PostgreSQL 监控系统与开箱即用的高可用数据库供给方案。Pigsty 基于开源生态构建，旨在降低 PostgreSQL 使用管理的门槛，为用户带来极致的可观测性与丝滑的数据库使用体验。\

Pigsty 是监控系统

PostgreSQL 是世界上最好的开源关系型数据库，但在其生态中却缺少一个足够好的监控系统。Pigsty 即旨在解决这一问题：提供世界上最好的 PostgreSQL 监控系统，

开发 Pigsty 的初衷是：作者需要对一个大规模 PostgreSQL 集群进行管理，但找遍所有市面上的开源与商业监控系统方案后，发现没有一个是“足够好用”的。本着“我行我上”的精神，开发设计了本系统。

Pigsty 的界面基于 Grafana 深度定制，由 30+监控面板，上千+仪表盘，18 万行 JSON 定制而成，涵盖数据库与基础设施的方方面面。

图片图片

Pigsty 提供近 1200 个监控指标，一骑绝尘，远超市面上现有的相关产品。提供从全局大盘汇总到某一个数据对象增删改查的全域数据支持。\

图片

Pigsty 是供给方案

Pigsty 同时还是一个高可用数据库集群供给方案。

监控系统要想发行与演示，必须要先有被监控的对象。可许多用户自建的数据库实在是千奇百怪。所以这里，Pigsty 项目决定将数据库供给方案作为项目的一部分发布。

将主从复制，故障切换，流量代理，连接池，服务发现，基本权限系统等成熟的生产级部署方案打包至本项目中，真正让用户做到立等可取，开箱即用。

图片

数据库供给方案所做的事情一言以蔽之：您填写一张表单，然后系统会自动根据表单的内容创建出对应的数据库集群。真正做到傻瓜式数据库管理。

图片

Pigsty 通过 130+配置项定义了数据库与基础设施的方方面面，采用声明式的语法与幂等的执行机制，使用代码定义基础设施，在物理机与虚拟机上达到了与 Kubernetes 类似的舒爽体验，简单易用。

Pigsty 是开源软件

Pigsty 依托开源，回馈社区，是免费的开源软件。Pigsty 基于Apache 2.0协议开源，但也提供专业版与可选的商业支持服务。欢迎各位贡献 ISSUE 与 PR，也欢迎捐赠与赞助。

图片

Pigsty 的监控系统基于开源组件 Prometheus，Grafana，Alertmanager，Exporter 进行深度定制开发。同时还包括 Nginx，Dnsmasq/CoreDNS，NTP/Chrony，Consul/Etcd 等基础设施。遵循业界监控最佳实践，可以方便地与已有监控基础设施集成。

Pigsty 的供给方案基于流行的 DevOps 工具 Ansible 进行开发，部署涉及的组件包括：Postgres，Pgbouncer，Patroni，HAProxy，Keepalived。所有部署逻辑都以 Ansible Role 的方式编写，可以方便地进行集成、定制与二次开发。

PostgreSQL 是世界上最先进的开源关系型数据库，而 Pigsty 旨在成为世界上最先进的开源关系型数据库的监控系统与供给方案。希望 Pigsty 能在各位使用 PostgreSQL 的过程中起到帮助。

Pigsty 可以开箱即用

Pigsty 提供了详实的中英文档供您参考。

更重要的是，Pigsty 既提供了可公开访问的演示 Demo，也自带了基于 Vagrant 的本地沙箱。您可以使用以下命令简单的在自己的笔记本上一键拉起带有数据库集群与监控基础设施的沙箱环境。

make up          # 拉起vagrant虚拟机
make ssh         # 配置虚拟机ssh访问
make init        # 初始化Pigsty
sudo make dns    # 写入Pigsty静态DNS域名（需要sudo,可选）
make mon-view    # 打开Pigsty首页（默认用户密码：admin:admin）

也可以在修改极少量配置后，使用完全相同的工作流初始化生产环境。

Pigsty 的相关站点\

Pigsty 提供了详实的中英文档供您参考。

中文站点：https://pigsty.cc

英文站点：https://pigsty.cc/en/

官方演示：http://demo.pigsty.cc

Github 仓库：https://github.com/Vonng/pigsty

图片

发布版本：微信公众号

2.17 - Pigsty官方网站上线啦！

原文发布于 VONNG。

好久没有冒泡了！今天，俺很荣幸的宣布，Pigsty 官方文档站上线啦！

地址为：http://pigsty.cc\

图片

什么？你问 Pigsty 是什么东东？\

Pigsty 是我亲自开发的 PostgreSQL 监控系统暨高可用数据库供给方案。

开源免费！详见下图，或者您点进那个站点看看也行啊。\

图片

虽然 “世界上最好的 PostgreSQL 监控系统”这个口号好像有违反广告法的嫌疑，不过自己站在甲方爸爸的立场上，我也确实找不到比它更好的了。用真理说服人嘛，所以也就厚着脸皮这样写上了，反正我也没收钱嘛。

图片

关于 Pigsty 本身，我就不多说了，该说的全都写在网站里了。但是建这个站可真是费老鼻子劲儿了！倒不是说建站有多难，毕竟都是现成的模板，我用的是 hugo，一个 go 写的静态网站生成器，主题用的是 Google 出品的 Docsy，相当方便，往里填内容就行了。改下文案改个图标和背景图片，用不了一会儿英文首页就都出来了。\

图片

但写文档真是要了我老命了，文档怎么说也有几十万字（符）了，再加上还要中英文双语，写的我是头昏脑胀，把一个周末就这么交代了。港真，写文档真的是比写书还累。很耽误打《赛博朋克 2077》和《原神》的进度啊。

中文文档首页

图片

特别费时间的就是监控系统的界面说明，几十个 Dashboard 需要一个个去截图配文。想想就有点抓狂了。

图片

英文文档首页

更让人抓狂的当然是整个文档网站得做一个一模一样的英文版出来。

图片

多亏了 DeepL，不少英文文档可以先机翻凑合一下。\

大体上弄完了中英文文档，看着空落落的博客里只有六篇新闻和 Release Note。我又想着要不把以前写过的和 PostgreSQL 相关的技术文章也搬运过来。于是整理了一部分，又是几个小又过去了

图片

好了就说这么多吧。应该说看上去还是很不错的，总归有一些正经项目的样子了。也基本上算可以拿的出手了。所以最近呢，我准备推广一下 Pigsty，有两个相关活动。

一个是阿里云搞的 PostgreSQL 创新训练营，一个是 1 月 15 号在广州举办的 PG Conf 大会。

阿里弄的这个报名不要钱，还有小奖品。对 PostgreSQL 感兴趣的同学可不要错过哈。关于 Pigsty 的课程在 1 月 22 号那天。

图片

PG Conf 2020

PG 大会在广州举办，具体时间是是 2021-01-16 下午 14:30-15:00

专场七数据库内核及新特性（下）

我也不知道讲监控系统为啥给分到内核里了，可能是比较硬核吧😎。\

可以在这里看到大会的具体议程：

http://pigsty.cc/zh/blog/2021/01/08/pg-conf-china-2021/

最后，如果您是 GitHub 用户，也非常欢迎来加个星，提个 Issue PR 什么的。

火钳刘明：https://github.com/Vonng/pigsty。

梦想还是要有的，万一🔥了呢对不对？

发布版本：微信公众号

2.18 - Pigsty v0.5：数据库定制模板

原文发布于 VONNG。

GitHub Release | 发布注记

v0.5.0

大纲

  • Pigsty官方文档站正式上线！
  • 添加了数据库模板的定制支持，用户可以通过配置文件定制所需的数据库内部对象。
  • 对默认访问控制模型进行了改进
  • 重构了HBA管理的逻辑，现在将由Pigsty替代Patroni直接负责生成HBA
  • 将Grafana监控系统的供给方案从sqlite改为JSON文件静态Provision
  • 将 pg-cluster-replication 面板加入Pigsty开源免费套餐。
  • 最新的经过测试的离线安装包：pkg.tgz (v0.5)

定制数据库

您是否烦恼过单实例多租户的问题？比如总有研发拿着PostgreSQL当MySQL使，明明是一个Schema就能解决的问题，非要创建一个新的数据库出来，在一个实例中创建出几十个不同的DB。 不要忧伤，不要心急。Pigsty已经提供数据库内部对象的Provision方案，您可以轻松地在配置文件中指定所需的数据库内对象，包括：

  • 角色
    • 用户/角色名
    • 密码
    • 用户属性
    • 用户备注
    • 用户所属的权限组
  • 数据库
    • 属主
    • 额外的模式
    • 额外的扩展插件
    • 数据库级的自定义配置参数
  • 数据库
    • 属主
    • 额外的模式
    • 额外的扩展插件
    • 数据库级的自定义配置参数
  • 默认权限
    • 默认情况下这里配置的权限会应用至所有由 超级用户 和 管理员用户创建的对象上。
  • 默认扩展
    • 所有新创建的业务数据库都会安装有这些默认扩展
  • 默认模式
    • 所有新创建的业务数据库都会创建有这些默认的模式

配置样例

# 通常是每个DB集群配置的变量
pg_users:
  - username: test
    password: test
    comment: default test user
    groups: [ dbrole_readwrite ]    # dborole_admin|dbrole_readwrite|dbrole_readonly
pg_databases:                       # create a business database 'test'
  - name: test
    extensions: [{name: postgis}]   # create extra extension postgis
    parameters:                     # overwrite database meta's default search_path
      search_path: public,monitor

# 通常是整个环境统一配置的全局变量
# - system roles - #
pg_replication_username: replicator           # system replication user
pg_replication_password: DBUser.Replicator    # system replication password
pg_monitor_username: dbuser_monitor           # system monitor user
pg_monitor_password: DBUser.Monitor           # system monitor password
pg_admin_username: dbuser_admin               # system admin user
pg_admin_password: DBUser.Admin               # system admin password

# - default roles - #
pg_default_roles:
  - username: dbrole_readonly                 # sample user:
    options: NOLOGIN                          # role can not login
    comment: role for readonly access         # comment string

  - username: dbrole_readwrite                # sample user: one object for each user
    options: NOLOGIN
    comment: role for read-write access
    groups: [ dbrole_readonly ]               # read-write includes read-only access

  - username: dbrole_admin                    # sample user: one object for each user
    options: NOLOGIN BYPASSRLS                # admin can bypass row level security
    comment: role for object creation
    groups: [dbrole_readwrite,pg_monitor,pg_signal_backend]

  # NOTE: replicator, monitor, admin password are overwritten by separated config entry
  - username: postgres                        # reset dbsu password to NULL (if dbsu is not postgres)
    options: SUPERUSER LOGIN
    comment: system superuser

  - username: replicator
    options: REPLICATION LOGIN
    groups: [pg_monitor, dbrole_readonly]
    comment: system replicator

  - username: dbuser_monitor
    options: LOGIN CONNECTION LIMIT 10
    comment: system monitor user
    groups: [pg_monitor, dbrole_readonly]

  - username: dbuser_admin
    options: LOGIN BYPASSRLS
    comment: system admin user
    groups: [dbrole_admin]

  - username: dbuser_stats
    password: DBUser.Stats
    options: LOGIN
    comment: business read-only user for statistics
    groups: [dbrole_readonly]


# object created by dbsu and admin will have their privileges properly set
pg_default_privilegs:
  - GRANT USAGE                         ON SCHEMAS   TO dbrole_readonly
  - GRANT SELECT                        ON TABLES    TO dbrole_readonly
  - GRANT SELECT                        ON SEQUENCES TO dbrole_readonly
  - GRANT EXECUTE                       ON FUNCTIONS TO dbrole_readonly
  - GRANT INSERT, UPDATE, DELETE        ON TABLES    TO dbrole_readwrite
  - GRANT USAGE,  UPDATE                ON SEQUENCES TO dbrole_readwrite
  - GRANT TRUNCATE, REFERENCES, TRIGGER ON TABLES    TO dbrole_admin
  - GRANT CREATE                        ON SCHEMAS   TO dbrole_admin
  - GRANT USAGE                         ON TYPES     TO dbrole_admin

# schemas
pg_default_schemas: [monitor]

# extension
pg_default_extensions:
  - { name: 'pg_stat_statements',  schema: 'monitor' }
  - { name: 'pgstattuple',         schema: 'monitor' }
  - { name: 'pg_qualstats',        schema: 'monitor' }
  - { name: 'pg_buffercache',      schema: 'monitor' }
  - { name: 'pageinspect',         schema: 'monitor' }
  - { name: 'pg_prewarm',          schema: 'monitor' }
  - { name: 'pg_visibility',       schema: 'monitor' }
  - { name: 'pg_freespacemap',     schema: 'monitor' }
  - { name: 'pg_repack',           schema: 'monitor' }
  - name: postgres_fdw
  - name: file_fdw
  - name: btree_gist
  - name: btree_gin
  - name: pg_trgm
  - name: intagg
  - name: intarray

# postgres host-based authentication rules
pg_hba_rules:
  - title: allow meta node password access
    role: common
    rules:
      - host    all     all                         10.10.10.10/32      md5

  - title: allow intranet admin password access
    role: common
    rules:
      - host    all     +dbrole_admin               10.0.0.0/8          md5
      - host    all     +dbrole_admin               172.16.0.0/12       md5
      - host    all     +dbrole_admin               192.168.0.0/16      md5

  - title: allow intranet password access
    role: common
    rules:
      - host    all             all                 10.0.0.0/8          md5
      - host    all             all                 172.16.0.0/12       md5
      - host    all             all                 192.168.0.0/16      md5

  - title: allow local read-write access (local production user via pgbouncer)
    role: common
    rules:
      - local   all     +dbrole_readwrite                               md5
      - host    all     +dbrole_readwrite           127.0.0.1/32        md5

  - title: allow read-only user (stats, personal) password directly access
    role: replica
    rules:
      - local   all     +dbrole_readonly                               md5
      - host    all     +dbrole_readonly           127.0.0.1/32        md5
pg_hba_rules_extra: []

# pgbouncer host-based authentication rules
pgbouncer_hba_rules:
  - title: local password access
    role: common
    rules:
      - local  all          all                                     md5
      - host   all          all                     127.0.0.1/32    md5

  - title: intranet password access
    role: common
    rules:
      - host   all          all                     10.0.0.0/8      md5
      - host   all          all                     172.16.0.0/12   md5
      - host   all          all                     192.168.0.0/16  md5
pgbouncer_hba_rules_extra: []

数据库模板

权限模型

v0.5 改善了默认的权限模型，主要是针对单实例多租户的场景进行优化，并收紧权限控制。

  • 撤回了普通业务用户对非所属数据库的默认 CONNECT 权限
  • 撤回了非管理员用户对所属数据库的默认 CREATE 权限
  • 撤回了所有用户在 public 模式下的默认创建权限。

供给方式

原先Pigsty采用直接拷贝Grafana自带的grafana.db的方式完成监控系统的初始化。 这种方式虽然简单粗暴管用，但不适合进行精细化的版本控制管理。在v0.5中，Pigsty采用了Grafana API完成了监控系统面板供给的工作。 您所需的就是在 grafana_url 中填入带有用户名密码的Grafana URL。 因此，监控系统可以背方便地添加至已有的Grafana中。

2.19 - Pigsty v0.4：PG13 与文档站

原文发布于 VONNG。

GitHub Release | 发布注记

v0.4.0

第二个公开测试版v0.4现已正式发行

Pigsty v0.4 对监控系统进行了整体升级改造，精心挑选了10个面板作为标准的Pigsty开源内容。同时，针对Grafana 7.3的不兼容升级进行了大量适配改造工作。使用升级的 pg_exporter v0.3.1 作为默认指标导出器，调整了监控报警规则的监控面板连接。

Pigsty开源版

Pigsty开源版选定了以下10个Dashboard作为开源内容。其他Dashboard作为可选的商业支持内容提供。

  • PG Overview
  • PG Cluster
  • PG Service
  • PG Instance
  • PG Database
  • PG Query
  • PG Table
  • PG Table Catalog
  • PG Table Detail
  • Node

尽管进行了少量阉割，这10个监控面板所涵盖的内容仍然可以吊打所有同类软件。

软件升级

Pigsty v0.4进行了大量软件适配工作，包括：

  • Upgrade to PostgreSQL 13.1, Patroni 2.0.1-4, add citus to repo.
  • Upgrade to pg_exporter 0.3.1
  • Upgrade to Grafana 7.3, Ton’s of compatibility work
  • Upgrade to prometheus 2.23, with new UI as default
  • Upgrade to consul 1.9

其他改进

  • Update prometheus alert rules
  • Fix alertmanager info links
  • Fix bugs and typos.
  • add a simple backup script

离线安装包

  • v0.4的离线安装包（CentOS 7.8）已经可以从Github下载：pkg.tgz

2.20 - Pigsty v0.3：首个公开测试版

原文发布于 VONNG。

GitHub Release | 发布注记

v0.3.0

首个Pigsty公开测试版本现在已经释出！

监控系统

Pigsty v0.3 包含以下8个监控面板作为开源内容：

  • PG Overview
  • PG Cluster
  • PG Service
  • PG Instance
  • PG Database
  • PG Table Overview
  • PG Table Catalog
  • Node

离线安装包

  • v0.3 离线安装包（CentOS 7.8）已经可以从Github下载：pkg.tgz

2.21 - PostgreSQL监控系统Pigsty概述

原文发布于 VONNG。

近自己做了套数据库监控系统，搞的还可以，简单给大家介绍一下。

Pigsty is an advanced PostgreSQL monitoring systemd based on open source projects like prometheus & grafana. PIGSTY /pɪɡ staɪ/ is the abbreviation of “Postgres in Grafana Style”.

Pigsty 是一个基于 Grafana 与 Prometheus 与 Consul 的 Postgres 数据库监控系统。

整体架构

TLDR: (Node/Pg/Pgbouncer) Exporter Discovered by Consul to Prometheus to Grafana

┏━━━━━━━━━━━┓     ┏━━━━━━━━━━━━━━━━━━━━┓
┃   Node    ┃ --> ┃   Node    Exporter-┃┐
┃ Pgbouncer ┃ --> ┃ Pgbouncer Exporter-┃┼--> Prometheus ---> Grafana
┃ Postgres  ┃ --> ┃ Postgres  Exporter-┃┘        ↑
┃           ┃     ┗━━━━━━━━━━━━━━━━━━━━┛  (Service Discovery)
┃  Consul   ┃ ----------------------------->   Consul
┗━━━━━━━━━━━┛

一言以蔽之：用 Exporter 取指标数据，通过 Consul 服务发现赋予身份标签与组织结构，存进 Prometheus 中进行预处理计算，最后使用 Grafana 展示

这里能看到的主要还是 Grafana 里的 Dashboard，因此主要还是介绍脸面上的东西。\

层次组织

图片

监控主要分为五个层次，集群（cluster），服务（service），实例（instance），数据库（database），与节点（node）。不过在本系统中，服务层次的监控指标被整合至集群级别，数据库层次的监控指标被整合至实例级别。因此实际上，只有三个核心层次的监控展示：集群，实例，节点。

  • 集群使用cls唯一标识，名称类似于：pg-test-tt

  • 实例使用ins唯一标识，名称类似于：pg-test-tt-0，以集群为前缀，序号为后缀。后缀为 0 的实例通常是集群中的主库。

  • 节点使用ip唯一标识。

除此之外，还有一些其他层次的 Dashboard：例如全局大盘概览，分片库专用的 Shard Dashboard，每一个数据库具体的 Database Dashboard、连接池 Pool 层次的 Dashboard，具体到某一个库上某一个查询的 PG Query Dashboard，Pgbouncer 中间件专用 Dashboard，等等，这些衍生或周边的 Dashboard 就不介绍了。

功能简介

核心功能：日常巡检，故障排查，性能优化，全知即全能。

  • PG 全局监控

  • PG Shard 监控

  • PG 集群监控

  • PG 实例监控

  • PG 实例监控（故障排查专用视图）

  • PG 节点监控

  • PG 慢查询平台

  • Redis 全局概览

  • Redis 集群监控

  • Redis 实例监控

  • PG 集群健康度评估系统

首页导航概览

包含 PG 和 Redis 两部分，左侧为全局指标概览，右侧为集群导航。中间为全局报警与事件提醒。点击右上角的导航链接，或者页面中的可导航元素（Shard，集群名，实例名，IP 等）可跳转至感兴趣的面板

图片

DB 监控：指标介绍

指标丰富程度

你可以不看，我不能没有。

每个实例包括了约 3300 个指标，其中：

数据库与连接池指标 1000 个，其中规则定义衍生指标 250 个。

节点指标约 2000 个，其中规则定义的衍生指标 700 个。

举个例子，单纯一个 QPS，就可以衍生出下面近 30 个指标。\

图片

这里随便挑一些重要的指标介绍一下\

指标内容

按 Google SRE 实践划分的四类黄金指标

错误

  • 配置错误：关键功能是否配置正常：校验和，Numa，透明大页，同步提交等。

  • 内存错误，TCP 错误，时间漂移错误

  • 服务宕机：机器，数据库，连接池，监控组件

  • 数据库客户端排队，IdleInXact 连接，超长事务，死锁，复制中断，大量回滚，监控报错

饱和度

  • PG Load, Node Load

  • CPU 使用，内存使用，磁盘使用，网卡带宽利用率，缓存命中率，后端连接使用，连接池使用

流量

  • 数据库直接指标：QPS，TPS，查询细分 QPS

  • 间接流量指标：连接池进出流量，WAL 写入量，增删改查条数，块访问量，缓冲区访问量

  • 节点流量：磁盘 IO 流量，网络 IO 流量，内存页面换入换出

延迟

  • 事务平均响应时间 Xact RT

  • 查询平均响应时间 Query RT

  • 语句平均响应时间：Statement RT

  • 磁盘平均响应时间：Disk R/W Latency

  • 复制延迟（以秒或字节计算）

  • 监控查询延迟

DB 监控：PG 实例

实例概览

  • 实例身份信息：集群名，ID，所属节点，软件版本，所属集群其他成员等

  • 实例配置信息：一些关键配置，目录，端口，配置路径等

  • 实例健康信息，实例角色（Primary，Standby）等。

  • 黄金指标：PG Load，复制延迟，活跃后端，排队连接，查询延迟，TPS，数据库年龄

  • 数据库负载：实时（Load0），1 分钟，5 分钟，15 分钟

  • 数据库警报与提醒事件

图片

关于 PG Load，可以参考本号前一篇文章，如何给 PostgreSQL 定 KPI

节点概览

  • 四大基本资源：CPU，内存，磁盘，网卡的配置规格，关键功能，与核心指标

  • 右侧是网卡详情与磁盘详情

图片

单日统计

以最近 1 日为周期的统计信息（从当前时刻算起的前 24 小时），比如最近一天的查询总数，返回的记录总数等。上面两行是节点级别的统计，下面两行是主要是 PG 相关的统计指标。

对于计量计费，水位评估特别有用。

复制

  • 当前节点的 Replication 配置

  • 复制延迟：以秒计，以字节计的复制延迟，复制槽堆积量

  • 下游节点对应的 Walsender 统计

  • 各种 LSN 进度，综合展示集群的复制状况与持久化状态。

  • 下游节点数量统计，可以看出复制中断的问题

图片

事务

事务部分用于洞悉实例中的活动情况，包括 TPS，响应时间，锁等。

  • TPS 概览信息：TPS，TPS 与过去两天的 DoD 环比。DB 事务数与回滚数

  • 回滚事务数量与回滚率

  • TPS 详情：绿色条带为±1σ，黄色条带为±3σ，以过去 30 分钟作为计算标准，通常超出黄色条带可认为 TPS 波动过大

  • Xact RT，事务平均响应时间，从连接池抓取。绿色条带为±1σ，黄色条带为±3σ。

  • TPS 与 RT 的偏离程度，是一个无量纲的可横向比较的值，越大表示指标抖动越厉害，计算方式为：(μ/σ)^2

  • 按照 DB 细分的 TPS 与事务响应时间，通常一个实例只有一个 DB，但少量实例有多个 DB。

  • 事务数，回滚数（TPS 来自连接池，而这两个指标直接来自 DB 本身）

  • 锁的数量，按模式聚合（8 种表锁），按大类聚合（读锁，写锁，排他锁）

图片

查询

大多数指标与事务中的指标类似，不过统计单位从事务变成了查询语句。查询部分可用于分析实例上的慢查询，定位性能瓶颈。

  • QPS 每秒查询数，与 Query RT 查询平均响应时间，以及这两者的波动程度，QPS 的周期环比等

  • 生产环境对查询平均响应时间有要求：1ms 为红线，100ms 就该约谈了。

图片

语句

语句展示了查询中按语句细分的指标。每条语句（查询语法树抽离常量变量后如果一致，则算同一条查询）都会有一个查询 ID，可以在慢查询平台中获取到具体的语句与详细指标与统计。

  • 左侧慢查询列表是按pg_stat_statments中的平均响应时间从大到小排序的，点击查询 ID 会自动跳转到慢查询平台

  • 这里列出的查询，是累计查询耗时最长的 32 个查询，但排除只有零星调用的长耗时单次查询与监控查询。

  • 右侧包括了每个查询的实时 QPS，平均响应时间。按照 RT 与总耗时的排名。

后端进程

后端进程用于显示与 PG 本身的连接，后端进程相关的统计指标。特别是按照各种维度进行聚合的结果，特别适合定位雪崩，慢查询，其他疑难杂症。

  • 后端进程数按种类聚合，后端进程按状态聚合，后端进程按 DB 聚合，后端进程按等待事件类型聚合。

  • 活跃状态的进程/连接，在事务中空闲的连接，长事务。

图片

连接池

连接池部分与后端进程部分类似，但全都是从 Pgbouncer 中间件上获取的监控指标

  • 连接池后端连接的状态：活跃，刚用过，空闲，测试过，登录状态。

  • 分别按照 User，按照 DB，按照 Pool（User:DB）聚合的前端连接，用于排查异常连接问题。

  • 等待客户端数（重要），以及队首客户端等待的时长，用于定位连接堆积问题。

  • 连接池可用连接使用比例。

数据库概览

Database 部分主要来自pg_stat_database与pg_database，包含数据库相关的指标：

  • WAL Rate，标识数据库的写入负载，每秒产生的 WAL 字节数量。

  • Buffer Hit Rate，数据库 ShareBuffer 命中率，未命中的页面将从操作系统 PageCache 和磁盘获取。

  • 每秒增删改查的记录条数

  • 临时文件数量与临时文件大小，可以定位大型查询问题。

图片

持久化

持久化主要包含数据落盘，Checkpoint，块访问相关的指标

  • 重要的持久化参数，比如是否出现数据校验和验证失败（如果启用可以检测到数据腐坏）

  • 数据库文件（DB，WAL，Log）的大小与增速。

  • 检查点的数量与检查点耗时。

  • 每秒分配的块，与每秒刷盘的块。每秒访问的块，以及每秒从磁盘中读取的块。（以字节计，注意一个 Buffer Page 是 8192，一个 Disk Block 是 4096）

监控 Exporter

Exporter 展示了监控系统组件本身的监控指标，包括：

  • Exporter 是否存活，Uptime，Exporter 每分钟被抓取的次数

  • 每个监控查询的耗时，产生的指标数量与错误数量。

图片

DB 监控：PG 集群

PG 集群监控是最常用的 Dashboard，因为 PG 以集群为单位提供服务，因此 Cluster 集合了最完整全面的信息。

大多数监控图都是实例级监控的泛化与上卷，即从展示单个实例内的细节，变为展现集群内每个实例的信息，以及集群和服务层次聚合后的指标。

集群概览

Cluster 级别的集群概览相比实例级别多了一些东西：

  • 时间线与领导权，当数据库发生 Failover 或 Switchover 时，时间线会步进，领导权会发生变化。

  • 集群拓扑，集群拓扑展现了集群中的复制拓扑，以及采用的复制方式（同步/异步）。

  • 集群负载，包括整个集群实时、1 分钟、5 分钟、15 分钟的负载情况。以及集群中每个节点的 Load1

  • 集群报警与事件。

图片

集群复制

Cluster 级别的 Dashboard 与 Instance 级别 Dashboard 最重要的区别之一就是提供了整个集群的复制全景。包括：

  • 集群中的主库与级联桥接库。集群是否启用同步提交，同步从库名称。桥接库与级联库数量，最大从库配置

  • 成对出现的 Walsender 与 Walreceiver 列表，体现一对主从关系的复制状态

  • 以秒和字节衡量的复制延迟（通常 1 秒的复制延迟对应 10M~100M 不等的字节延迟），复制槽堆积量。

  • 从库视角的复制延迟

  • 集群中从库的数量，备份或拉取从库时可以从这里看到异常。

  • 集群的 LSN 进度，用于整体展示集群的复制状态与持久化状态。

图片

节点指标

PG 机器的相关指标，按照集群进行聚合。

图片

事务与查询

与实例级别的类似，但添加了 Service 层次的聚合（一个集群通常提供primary与standby两种 Service）。

图片

其他指标与实例级别差别不大。\

DB 监控：PG 慢查询平台

显示慢查询相关的指标，上方是本实例的查询总览。鼠标悬停查询 ID 可以看到查询语句，点击查询 ID 会跳转到对应的查询细分指标页（Query Detail）。

  • 左侧是格式化后的查询语句，右侧是查询的主要指标，包括

    • 每秒查询数量：QPS

    • 实时的平均响应时间（RT Realtime）

    • 每次查询平均返回的行数

    • 每次查询平均用于 BlockIO 的时长

    • 响应时间的均值，标准差，最小值，最大值（自从上一次统计周期以来）

    • 查询最近一天的调用次数，返回行数，总耗时。以及自重置以来的总调用次数。

  • 下方是指定时间段的查询指标图表，是概览指标的细化。

图片

发布版本：微信公众号

3 - 设计

Pigsty 工程中的架构决策与实现说明。

设计专栏记录 Pigsty 架构与实现背后的背景、约束、决策与取舍。