Pigsty v4.5：575扩展、Silo、Valkey、Kafka与MySQL

GitHub Release | 发布注记

Pigsty v4.5 正式发布。上一版的结尾我说过，5.0 之前可能会有一个 4.5 过渡版本。现在它来了，只是做着做着发现，这个 “过渡版本” 塞得比正经大版本还满。

先拉个清单，v4.5 里有什么：

• 575 个 PostgreSQL 扩展：从 531 涨到 575，pg_lake、pg_jieba、plruby 这些都进来了。
• Silo 对象存储：MINIO 模块正式换芯，切换到 Pigsty 自家维护的 MinIO 分支 —— Silo。
• Valkey：REDIS 模块新增 Valkey 引擎，一个参数切换，清单、监控、面板原样保留。
• Kafka 模块：全新试点模块，Pigsty 原生 KRaft 编排：多集群、动态成员、SCRAM/TLS、四个监控面板。
• MySQL 模块：是的，MySQL，你没看错。8.4 LTS，单机或三节点 InnoDB Cluster，同样是试点。
• 剩下是一堆零碎但有用的东西：显式集群身份、更稳的移除流程、pg_exporter 1.4、SOW 仓库工具、51 套配置模板……

下面按这个顺序，一项一项说。

扩展来到 575 个

#

每个版本都要报一遍扩展数字，这次是 575 —— 相比 v4.4 的 531，新增 46 个、移除 2 个，净增 44。完整目录照旧在 扩展列表 里，这里只点几个值得说道的新面孔：

• pg_lake 全家桶：Snowflake 收购 Crunchy Data 之后开源的湖仓扩展，用 DuckDB 做向量化执行引擎，把 Iceberg 与 Parquet 直接接进 PostgreSQL。这是今年 PG 生态在数据湖方向上最重要的新东西，Pigsty 第一时间打好了包（PG 16–18，RPM 侧目前仅 EL9/10）。
• pg_jieba 与 pg_cjk_parser：中文与 CJK 分词。做中文全文检索的用户应该知道这意味着什么 —— 以前要自己编译 pg_jieba 的朋友可以歇歇了。
• plruby：Ruby 存储过程语言，连带 hstore / jsonb / ltree 三个类型转换子扩展一起打包。PL 语言拼图又补上一块，至于谁会真的用 Ruby 写存储过程，我也很好奇。
• pgmemento：纯 SQL 实现的审计与数据变更追踪，给表上加一条完整的时光轴。
• online_advisor：根据实际执行的查询在线给出索引建议。
• pg_turbovec、pgcontext、pg_tiktoken_c：向量与 RAG 方向继续加码，加上升级到 0.16 的 pgmnemo（Agent 记忆），AI 全家桶又厚了一层。
• 还有 pgwasm（WebAssembly）、postbis（生物信息序列）、qdgc（地理网格，含 PostGIS 子扩展）、pg_vault_tde（对接 Vault 的透明加密）这些各有各用处的。

除了上新，这一轮还把几乎所有 Rust 扩展迁移到 pgrx 0.19.1 重新构建了一遍。表面上看很多包版本号没变，背后是整个构建矩阵的重跑 —— 版本号不动不代表没干活。

移除了两个：pg_analytics（上游已归档）和 spat（废弃的 alpha 项目）。另外有五个扩展（emailaddr、explain_ui、oidc_validator、pg_summarize、smlar）因为上游没有提供许可证，从默认安装组里移了出来。软件包还在，想用请显式安装，并自己确认许可证与再分发边界 —— 发行版可以帮你打包，但没法替你承担合规责任。

常规升级也没停：Citus 14.2、TimescaleDB 2.29.1、pgvector 0.8.6、pg_search 0.25.2、DocumentDB 0.114、pg_partman 5.5、pgmq 1.12……完整的软件包变更表见 发布注记，两百多行，就不搬过来了。

Silo：对象存储换芯

#

MinIO 的事，老读者都熟：上游把管理界面砍成登录页，社区版接近弃疗，我 fork 了一份续命，修了 CVE，写过《MinIO已死》和《续命 MinIO：承诺兑现》。这个分支后来有了自己的名字：Silo，筒仓。猪圈（Pigsty）旁边立一个饲料塔（Silo），再配上包管理器小猪（pig）和仓库工具母猪（sow），一家人整整齐齐。

v4.5 把这件事做到了头：MINIO 模块现在部署并且只部署 Silo，minio_type 参数目前唯一合法值就是 silo。兼容性不用担心：S3 与 Admin API、/minio/* 路由、MINIO_* 环境变量、磁盘数据格式全部保持原样，变的只是软件包、二进制与 systemd 服务的名字。对存量用户来说，这更像换了个牌子的发动机，底盘和方向盘都没动。

当然，协议兼容不等于迁移自动验收。切换生产对象存储之前，备份、回滚预案、真实读写验证，一样都不能省。

围绕 Silo 还有一圈配套改进：

• 启动流程用 systemd Invocation ID、ActiveState 与 Silo 集群健康三重确认，最长等待约 600 秒，不会再把旧进程的状态误判成本次启动成功。
• 对象存储集群按 minio_cluster 身份聚合，同一份清单可以声明多套集群，各用各的 minio_alias 与 minio_endpoint。
• 高可用模板 ha/trio 从单节点对象存储改成三节点单盘 Silo（EC:1），通过 VIP 与 HAProxy 暴露 9002 端口。
• 分布式 Silo 强制要求 /data/minio 是独立文件系统，根分区下的普通目录会被直接拒绝 —— 这条是在帮你避开 “把生产对象存储放在根分区上” 这类事故。

至于 RustFS：这个开发周期里我们确实把 RustFS 后端做进去过，最后在发布前撤了回来。它还差一口气，等真正 GA 稳定之后再说。仓库里保留了 rustfs 软件包（1.0.0-rc.1），想自己折腾可以装着玩，但它不是 v4.5 MINIO 模块支持的后端。

Valkey：Redis 之外的选项

#

Redis 许可证的抓马我写过不少，比如《Redis不开源是"开源"之耻，更是公有云之耻》。后来 Redis 8 又回到了 AGPL，但社区分叉出来的 Valkey 已经自成一派：Linux 基金会背书，主流发行版全都收了。总有用户问：Pigsty 能不能用 Valkey？

现在可以了：redis_type: valkey，一个参数的事。

设计上我们刻意做成了 “无感切换”：装的是 valkey-server / valkey-cli，但配置路径、数据目录、服务名、监控 job、模块参数全部沿用 redis 命名空间。已有的清单、面板、告警规则一行都不用改。注意引擎选择以集群为单位，同一套集群别混着用；存量 Redis 集群要切 Valkey，请先在测试环境演练，数据与复制兼容性自己验证过再动手。顺便说一句，Valkey 官方软件包的水有多深，可以看之前这篇《上游没有的 Bug，为什么会出现在官方包里？》。

这次 Redis/Valkey 的 systemd 单元也顺手改成了 Type=notify，启动超时放宽到 1800 秒，大实例加载数据不会再被 systemd 掐死。拓扑构建、密码处理、移除保护也都加固了一轮。

Kafka：从软件包到模块

#

为什么一个 PostgreSQL 发行版要管 Kafka？因为在真实的数据架构里，PG 旁边十有八九蹲着一套 Kafka：CDC 变更捕获、消息队列、事件流，这些活总得有人干。之前 Pigsty 仓库里就有 Kafka 软件包（还有 kafka_fdw），但部署得自己动手。v4.5 给了它一个完整的 KAFKA 模块。

这套模块基于 Kafka 4.3，纯 KRaft，没有 ZooKeeper，按 Pigsty 的习惯从头写的编排：

• 用 kafka_cluster / kafka_seq 定义集群身份，节点可以是 combined / broker / controller 角色，一份清单可以放多套 Kafka 集群。
• 动态 KRaft 仲裁：控制器动态加入、Broker 准入、成员退役、故障成员三阶段替换，都是剧本化的标准流程。
• 安全侧支持 SCRAM-SHA-512 与 TLS，凭据和证书可以轮换，变更之后自动做分区健康自检。
• 监控给足：JMX Exporter 加 Kafka Exporter，配套告警规则，以及 Overview / Instance / Topic / Consumer 四个 Grafana 面板。
• 危险操作守规矩：kafka-rm.yml 强制要求用 -l 指定范围，停服前校验数据目录与幸存节点；不完整的 --limit 会被直接拒绝，不给 “只动了一半仲裁成员” 留机会。

想试的话有现成模板：conf/demo/kafka.yml。

Kafka 目前是试点模块。有一条架构上的硬约束请记住：Kafka 协议要求客户端能直连每一个 Broker，所以数据平面不能塞在 HAProxy、VIP 或四层负载均衡后面 —— 这不是 Pigsty 的限制，是 Kafka 的天性。

MySQL：没想到吧

#

说好的《PostgreSQL 正在吞噬数据库世界》呢？怎么反手就在 Pigsty 里发了个 MySQL 模块？

冷静。吞噬也得讲先来后到：现实世界里 MySQL 存量巨大，很多用户的处境是新业务上 PG，老业务的 MySQL 还得养着；或者已经下定决心迁移，但迁完之前，这几十套 MySQL 总得有人管。与其让用户为了遗留系统再单独搭一套监控、备份、高可用体系，不如让 Pigsty 的底座顺手把它管起来 —— 反正监控告警、备份恢复、集群编排这些基础设施本来就是通用的。

先圈进来，再慢慢消化，这很合理。

v4.5 的 MYSQL 模块（试点）长这样：

• 锚定 MySQL 8.4 LTS，软件包来自官方社区仓库，配 Percona XtraBackup。
• 支持单机实例，或三节点 InnoDB Cluster（组复制），带 MySQL Shell 与 MySQL Router；成员数只接受 1 或 3，别的免谈。
• 用户与数据库声明式置备（mysql_users / mysql_databases），XtraBackup 定时全量备份，TLS 默认启用。
• mysql_parameters 可以调参，但复制、TLS 与平台保留参数受保护，想用 loose_ / skip_ 这类前缀绕过去是不行的。
• 监控五个面板：Overview / Cluster / Instance / Replication / Alert，mysqld_exporter 接入统一的服务发现与告警。
• 移除剧本 mysql-rm.yml 是所有模块里最保守的：目标主机没有 MySQL 身份就直接失败退出，绝不 “顺手清理”。

demo 模板：conf/demo/mysql.yml。另外，如果你要的其实是 “让 PG 说 MySQL 协议”，Pigsty 里还有 OpenHalo 这个选项。至于 PG 和 MySQL 谁好谁坏，这里就不展开了，展开又是一篇《PostgreSQL vs MySQL 2026》。

零碎清单

#

大件说完了，下面是零碎但值得知道的部分。

FERRET 模块拆分

#

独立的 FERRET 模块和 mongo.yml 剧本移除了。MongoDB 兼容这件事现在拆成两层：PostgreSQL 加 DocumentDB 扩展负责数据层（用 conf/mongo.yml 配置模板），FerretDB 作为 Docker 应用负责协议层。原来的 ferretdb systemd 服务、专属监控和面板不再提供。这样职责更清楚：数据的事归数据库，协议翻译的事归容器。

编排更安全了

#

这个版本在 “剧本不要误伤” 上花了不少功夫，值得单独列一下：

• PGSQL、REDIS、MINIO、KAFKA、MYSQL 的初始化与移除剧本都按显式集群身份（pg_cluster 等参数）选择成员，不再单纯依赖清单分组名。跑错分组的剧本会跳过无关主机，而不是 “顺手” 给它们装点什么。
• PITR 与移除只清理以 /<集群名>/ 为边界的 etcd 子树。以前两个集群名互为前缀时（比如 pg-test 和 pg-test2），清理有机会误删邻居的元数据，现在不会了。
• 初始 pgBackRest 备份只在备份命令确实成功之后才写标记文件，不会再出现 “标记说备过了，其实没有” 的情况。
• 所有模块的移除流程统一为先停服务、再清理数据；Kafka、MySQL 与对象存储还额外检查数据目录、仲裁与幸存成员。
• pgsql.yml 完整剧本现在明确标记为仅用于首次初始化。它会重启 Patroni/PostgreSQL 并重放配置与初始化 SQL，不是日常收敛工具，别在生产集群上整本重跑。
• DBSU 的 SSH 密钥按实际集群成员交换，Citus 这类跨分组拓扑也能正确覆盖；Pigsty 渲染的 systemd 单元统一收进 /etc/systemd/system，敏感配置与特权文件的权限进一步收紧。

这些改动没有一条是新功能，但每一条背后都对应着一类真实的生产事故。

可观测性

#

• 整套 Grafana 面板用 pig 的工具链重新导出为 Dashboard API v2 格式，新增 4 个 Kafka 面板与 5 个 MySQL 面板，Node / PGSQL / Redis / Infra 面板同步刷新。
• pg_exporter 升级到 1.4 系列：为 PG19 预置了订阅、恢复状态、WAL、锁等待与 vacuum 压力等新采集器；PG10 以上增加 pg_xact_age 事务年龄直方图 —— 距离事务号回卷还有多远，现在可以直接画出来。
• MinIO/Silo 面板迁移到 Metrics V3 端点，顺手丢掉了高基数的 bucket 标签样本，大桶用户的时序库会轻松不少。

仓库与供应链

#

• 本地软件仓库改由 SOW 生成 —— 就是 v4.4 结尾预告过的那个仓库管理工具（母猪）。sow create --pigsty 原子生成 DNF/APT 元数据与 SHA-256 完成标记，彻底移除了以前注入的伪造 ModuleMD 元数据。
• 离线软件包现在可以附带版本化的源码包；自建软件包统一使用 SHA-256 固定输入、SPDX 许可证表达式与 1PGSTY release 后缀。
• RPM Exporter 包名从下划线统一为连字符（node_exporter → node-exporter），旧名通过 Provides/Obsoletes 平滑过渡。
• 中国区镜像路由整个刷了一遍：腾讯云优先，华为云、阿里云、中科大按平台兜底。

内核与平台

#

• 默认 PostgreSQL 更新到 18.6；四套标准 Patroni 模板加入 output_plugin_libraries 逻辑解码插件白名单（pgoutput / test_decoding / wal2json），旧版本内核会由 Patroni 自动过滤该参数。
• PG19 beta 模板补上了 pgBackRest 2.59 的备份支持。v4.4 的时候 pgBackRest 还认不出 PG19 的控制文件，现在 PG19 尝鲜环境也能正经做备份了。
• Percona PostgreSQL 18 TDE 启用集群模式；IvorySQL 修复了默认数据库初始化并启用兼容的 WAL 压缩。
• 操作系统基线推进到 Rocky 9.8 / 10.2、Debian 12.15 / 13.6、Ubuntu 22.04.5 / 24.04.4 / 26.04；Docker 基础镜像切到 Debian 13.6。
• 配置模板来到 51 套：新增 demo/kafka、demo/mysql 与八节点仿真环境 ha/octo；ha/trio 改为三节点 Silo 拓扑。
• Vagrant 根盘大小可配置（root_disk，默认 64G），disk 继续表示额外的 /data 数据盘；虚拟机登录 Shell 统一为 Bash。

组件版本一览

#

完整的 Infra 与扩展软件包变更记录见 发布注记。

升级注意

#

从 v4.4 升级之前，请把这份清单过一遍，都是会咬人的变化：

1. minio_type 只接受 silo：协议与磁盘格式兼容，但软件包、二进制、服务名都变了。切换生产对象存储前，备份与回滚验证不能省。
2. ha/trio 对象存储拓扑变了：新模板是三节点单盘 Silo。已有单节点池不能靠加两台机器原地扩容，应新建集群迁移数据。
3. FERRET 拆分：mongo.yml 剧本、mongo_* 参数与专属面板移除，按 Mongo 配置模板加 Docker 应用的方式重新部署。
4. 必须声明集群身份：自定义清单要为目标主机补齐 pg_cluster / redis_cluster / minio_cluster / kafka_cluster / mysql_cluster。
5. pgsql.yml 只用于首次初始化：已初始化集群的日常维护请用精确标签，不要整本重跑。
6. Valkey 是显式选择：不设置 redis_type: valkey 就还是 Redis；切换引擎以集群为单位，先演练再动手。
7. SOW 成为 REPO/CACHE 硬依赖：旧离线包或旧本地仓库里没有 sow 0.3.0 的，先从 Pigsty Infra 仓库补齐。
8. Exporter RPM 改名：外部自动化与私有仓库请从 node_exporter / redis_exporter 等旧名迁移到连字符包名。
9. 五个无许可证扩展移出默认安装组：依赖 emailaddr、explain_ui、oidc_validator、pg_summarize、smlar 的环境需要改为显式安装。
10. HAProxy 单元语义变化：Pigsty 不再渲染 /etc/default/haproxy；如果覆盖 EXTRAOPTS，必须保留 master socket 参数，且不要往里塞 -f。
11. make purge 直接删除 ./data：docker 目录的清理不再有倒计时，也不再接受外部 DATA 变量，执行前自己确认。
12. Kafka 与 MySQL 是试点模块：Kafka 客户端必须能直连各 Broker；MySQL 成员数只接受 1 或 3。

获取 v4.5

#

在一台受支持的全新 Linux 节点上：

curl -fsSL https://repo.pigsty.io/get | bash -s v4.5.0
cd ~/pigsty
./bootstrap
./configure
./install.yml

中国大陆用户可以把 repo.pigsty.io 换成 repo.pigsty.cc。生产环境升级不是覆盖安装：先读上面的升级注意，核对清单身份、备份与实际运行状态，再用明确的 -l 范围滚动操作。

写在最后

#

v4.4 的主题是 “从集成到发行”，这个 v4.5 的主题，大概可以叫 “边界扩张”：往 PG 生态内部看，扩展目录推进到 575；往外看，对象存储、缓存、消息队列、甚至 MySQL，都被收进了同一套编排、监控与交付体系。

有人可能会问：一个 PostgreSQL 发行版，管这么宽干嘛？我的看法是，用户要的从来不是 “一个数据库”，而是一整套能跑业务的数据基础设施。PostgreSQL 是这套基础设施的核心，但核心旁边的东西 —— 缓存、对象存储、消息队列、遗留数据库 —— 同样需要有人用同样的标准管起来。Pigsty 本来就是个猪圈，圈里从来不止一头猪。

下一站是 5.0。九月 PostgreSQL 19 正式发布，Pigsty 5.0 会带着完整的 PG19 支持一起来：pg_exporter 的 PG19 指标、Patroni 模板的参数占位、pgBackRest 的备份支持，这些准备工作在本版都已就位。为企业版保守仓库准备的 sow，也已经在这一版成为正式依赖。剩下的，九月见。

GitHub Release | 发布注记