内容提要
Pigsty v4.4 发布,默认使用 PostgreSQL 18.4,扩展增至 531 个,并支持 PG19 beta。核心更新为 Pig 1.5 重构运维命令行,统一克隆、实例分叉与 PITR 恢复流程,提供计划、校验和结构化输出。新增 Immich、JumpServer、Maybe 模板,更新 Supabase,备份默认改用 Zstandard,VIP 网卡自动识别,并统一构建 PolarDB、IvorySQL 等内核分支。
延伸解读
Pig 1.5 如何降低运维风险
Pig 1.5 将克隆、分叉和 PITR 恢复等高风险操作统一为标准化流程,强制要求先查看计划(--plan)再执行,且破坏性操作必须显式传入 -y/--yes。这避免了因误操作或默认值导致的意外。结构化输出(JSON/YAML)便于自动化工具和 Agent 集成,使 DBA 和脚本能共享同一入口,减少人为错误。
升级前需关注的兼容性变化
v4.4 有多项默认值变更:pgBackRest 压缩算法改为 Zstandard,etcd 后端配额从 16 GiB 降至 8 GiB,VIP 网卡默认值改为 auto,Patroni 日志路径调整。升级前应检查现有配置,保留有意自定义项,并确保 Supabase Analytics 迁移到 _supabase 数据库和 _analytics 模式,避免服务中断。
扩展生态与内核分支的整合意义
扩展数量增至 531 个,新增 pg_ducklake、pg_stat_plans 等,覆盖湖仓、观测和检索场景。同时统一构建 PolarDB、IvorySQL 等内核分支,解决上游包缺失编译参数和平台支持问题。这使不同 PG 内核能接入完整扩展生态,减少零散捆绑,提升可安装性和可升级性,为未来多内核矩阵打下基础。
应用模板的实用场景与限制
新增 Immich、JumpServer、Maybe 模板,分别面向照片管理、堡垒机和个人财务。Immich 依赖 VectorChord 扩展实现智能搜索,但照片原件仍存文件目录,需借助 JuiceFS 挂载对象存储。Supabase 更新涉及十余个组件,升级时需注意 Analytics 独立数据库和密钥适配。这些模板让应用容器化而数据持久化,但需关注组件兼容性。
Q&A
Pigsty v4.4 中 Pig 1.5 主要重构了哪些运维操作?
Pig 1.5 将原本分散在 Ansible、Shell、Patroni 与 pgBackRest 中的数据库克隆、实例分叉和时间点恢复(PITR)等日常运维动作,统一成一套命令行接口,并引入 state → plan → precheck → execute → verify → result → next_actions 的标准化流程,支持人类可读文本和 JSON/YAML 结构化输出。
Pigsty v4.4 新增了哪些应用模板?
新增了 Immich(自托管照片管理)、JumpServer(堡垒机)和 Maybe(个人财务管理)三个应用模板,并更新了 Supabase 模板。
Pigsty v4.4 的备份压缩默认改成了什么?为什么?
默认压缩算法从 LZ4 改为 Zstandard。因为备份仓库更看重压缩比,Zstandard 能在只增加少量解压开销的情况下,将压缩比从 2.x 提升到 3.x,额外节省约三分之一的备份空间。
Pigsty v4.4 如何简化 VIP 网卡配置?
v4.4 将 vip_interface 和 pg_vip_interface 的默认值改为 auto,Pigsty 会根据清单中的节点 IP 自动反查实际网卡,并交给 Keepalived 或 VIP Manager,用户通常无需再手动填写网卡名称。
Pigsty v4.4 中 PostgreSQL 18.4 和 19 beta 的支持情况如何?
PostgreSQL 18.4 已成为生产默认版本;同时提供精简的 PostgreSQL 19 beta 评估模板,但 PG19 beta1 尚未达到生产状态,且 pgBackRest 2.58 无法识别其控制文件格式,因此仅用于尝鲜评估。
Pigsty v4.4 在 PG 内核分支构建上做了哪些统一工作?
v4.4 新增 Babelfish PG18,补齐 pgEdge PG15~18、AgensGraph PG17 与 OrioleDB PG16~18,并为 PolarDB、IvorySQL 提供自行构建的软件包,统一了 FHS 布局(如 PolarDB 包名改为 polardb-17,安装到 /usr/polar-17),还单独打包了 PolarDB 依赖的 PFSD 开发库为 polarstore。