Pigsty v4.5：575扩展、Silo、Valkey、Kafka与MySQL
内容提要
Pigsty v4.5发布，扩展增至575个，新增pg_lake、pg_jieba等。MINIO模块换为自研Silo分支，REDIS新增Valkey引擎，并推出Kafka与MySQL试点模块。同时加固编排安全、升级监控与仓库工具，为5.0铺路。
延伸解读
升级前必须留意的破坏性变更
从 v4.4 升级到 v4.5 有几处会“咬人”的变化：minio_type 现在只接受 silo，虽然协议与磁盘格式兼容，但软件包、二进制和服务名都变了；ha/trio 对象存储拓扑改为三节点单盘 Silo，已有单节点池无法原地扩容，需新建集群迁移；FERRET 模块拆分，mongo.yml 剧本和专属面板移除；自定义清单必须显式声明集群身份参数；pgsql.yml 仅用于首次初始化，日常维护不要整本重跑。升级前务必逐条核对。
Valkey 与 Kafka、MySQL 的试点定位
Valkey 作为 Redis 的替代引擎，通过 redis_type: valkey 一个参数切换，配置路径、监控 job 等全部沿用 redis 命名空间，但引擎选择以集群为单位，存量集群切换前需在测试环境演练。Kafka 和 MySQL 模块均标记为试点（Beta），Kafka 基于 4.3 纯 KRaft，客户端必须能直连每个 Broker，不能置于负载均衡之后；MySQL 锚定 8.4 LTS，成员数只接受 1 或 3。生产使用需评估风险。
扩展生态与供应链的持续投入
扩展数量从 531 增至 575，新增 pg_lake、pg_jieba、plruby 等，同时将几乎所有 Rust 扩展迁移到 pgrx 0.19.1 并重新构建。移除 pg_analytics 和 spat，五个无许可证扩展移出默认安装组。仓库工具 SOW 成为 REPO/CACHE 硬依赖，本地仓库改由 SOW 生成，移除了伪造的 ModuleMD 元数据，并统一使用 SHA-256 固定输入和 SPDX 许可证表达式。这些改动提升了供应链的可重复性与安全性。
Q&A
Pigsty v4.5 中 PostgreSQL 扩展数量有什么变化？新增了哪些值得关注的扩展？
扩展数量从 v4.4 的 531 个增加到 575 个，净增 44 个。新增的值得关注的扩展包括：pg_lake 全家桶（用 DuckDB 做向量化执行引擎，支持 Iceberg 与 Parquet）、pg_jieba 与 pg_cjk_parser（中文与 CJK 分词）、plruby（Ruby 存储过程语言）、pgmemento（审计与数据变更追踪）、online_advisor（在线索引建议）、pg_turbovec、pgcontext、pg_tiktoken_c、pgmnemo（向量与 RAG 方向）、pgwasm、postbis、qdgc、pg_vault_tde 等。
Pigsty v4.5 为什么用 Silo 替换 MinIO？切换后兼容性如何？
因为 MinIO 上游砍掉了管理界面，社区版接近弃疗，Pigsty 创始人 fork 了一份并修复 CVE，这个分支命名为 Silo。v4.5 中 MINIO 模块现在部署并且只部署 Silo，minio_type 参数唯一合法值是 silo。兼容性方面：S3 与 Admin API、/minio/* 路由、MINIO_* 环境变量、磁盘数据格式全部保持原样，变的只是软件包、二进制与 systemd 服务的名字。但切换生产对象存储前，备份、回滚预案、真实读写验证一样都不能省。
Pigsty v4.5 的 Redis 模块如何支持 Valkey？切换时需要注意什么？
通过设置 redis_type: valkey 即可切换到 Valkey 引擎。设计上做了无感切换：装的是 valkey-server / valkey-cli，但配置路径、数据目录、服务名、监控 job、模块参数全部沿用 redis 命名空间，已有的清单、面板、告警规则一行都不用改。注意引擎选择以集群为单位，同一套集群别混着用；存量 Redis 集群要切 Valkey，请先在测试环境演练，数据与复制兼容性自己验证过再动手。
Pigsty v4.5 新增的 Kafka 模块有哪些主要特性？
Kafka 模块基于 Kafka 4.3，纯 KRaft 模式，没有 ZooKeeper。主要特性包括：用 kafka_cluster / kafka_seq 定义集群身份，节点可以是 combined / broker / controller 角色，一份清单可以放多套 Kafka 集群；动态 KRaft 仲裁（控制器动态加入、Broker 准入、成员退役、故障成员三阶段替换）；安全侧支持 SCRAM-SHA-512 与 TLS，凭据和证书可以轮换；监控提供 JMX Exporter 加 Kafka Exporter，配套告警规则和四个 Grafana 面板；危险操作如 kafka-rm.yml 强制要求用 -l 指定范围。注意 Kafka 协议要求客户端能直连每一个 Broker，数据平面不能塞在 HAProxy、VIP 或四层负载均衡后面。
Pigsty v4.5 为什么引入 MySQL 模块？它支持哪些部署模式？
引入 MySQL 模块是因为现实世界中 MySQL 存量巨大，很多用户新业务上 PG，老业务 MySQL 还得养着，或者迁移完成前需要管理大量 MySQL。与其让用户单独搭建监控、备份、高可用体系，不如让 Pigsty 的底座顺手管起来。v4.5 的 MySQL 模块（试点）锚定 MySQL 8.4 LTS，软件包来自官方社区仓库，配 Percona XtraBackup。支持单机实例，或三节点 InnoDB Cluster（组复制），带 MySQL Shell 与 MySQL Router；成员数只接受 1 或 3。
从 Pigsty v4.4 升级到 v4.5 有哪些重要的注意事项？
升级注意事项包括：minio_type 只接受 silo，切换生产对象存储前需备份与回滚验证；ha/trio 对象存储拓扑变为三节点单盘 Silo，已有单节点池不能原地扩容，应新建集群迁移数据；FERRET 拆分，mongo.yml 剧本、mongo_* 参数与专属面板移除；必须声明集群身份（如 pg_cluster 等）；pgsql.yml 只用于首次初始化；Valkey 是显式选择，需设置 redis_type: valkey；SOW 成为 REPO/CACHE 硬依赖，需确保 sow 0.3.0 存在；Exporter RPM 包名从下划线改为连字符；五个无许可证扩展移出默认安装组；HAProxy 单元语义变化；make purge 直接删除 ./data；Kafka 与 MySQL 是试点模块。
