Pigsty v3.6：全能PG發行版的關鍵一步

用戶朋友們，Pigsty v3.6 RC 已經發布了，這個版本經過長達兩個月的烤制，即將新鮮出爐。這將是 Pigsty v4.0 之前的最后一個主要版本，進行了許多重構與改進，為終極全能 PostgreSQL 發行版奠定了一個堅實的基礎。

在 v3.6 中，針對 PostgreSQL，MinIO，Etcd 的部署任務進行了深度優化與重構，支持了一種全新的 PostgreSQL 內核：Percona PG TDE 內核，帶有開箱即用的透明加密功能。 此外，我們還優化了 Supabase 的自建體驗，跟進至最新的官方模板，并且解決了一些官方模板中存在的問題。

針對一些用戶遇到的實際問題，我們徹底移除了冪等劇本中的 “刪庫” 功能，剝離為單獨的刪庫劇本。 并且新增了用于執行時間點恢復的 pgsql-pitr 劇本，幫助您傻瓜式地全自動完成 PITR 恢復。

此外，安裝流程也進一步進行了簡化與加速，從原來的 下載-引導-配置-安裝，變為三步走： 下載，配置，安裝。而且現在默認使用在線安裝，可以跳過本地軟件倉庫的構建過程。

全新內核支持

最近 Percona （那個專業做 MySQL 服務的公司）的 pg_tde 擴展在經過了幾年長跑之后終于正式發布 1.0 GA 版本了。 許多 “企業級” PostgreSQL 發行版都以 “透明加解密” 特性作為一個核心賣點，而 pg_tde 擴展可能是第一個足夠成熟的開源透明加密擴展，為開源 PostgreSQL 提供了一個真正意義上的企業級透明加密解決方案。

不過美中不足的是，目前這個擴展需要在打補丁的 PostgreSQL 內核上才能運行 —— 也就是 Percona 的 Postgres 發行版。當然這可難不倒 Pigsty，我們在它們官宣之后立刻就支持了這個內核分支。

你只需要兩行命令，就可以啟用并安裝它，并且實用 Pigsty 提供的完整 RDS 能力 —— 監控，高可用，PITR，IaC，等等……，和原生 PG 內核一樣。

然后， Pigsty 支持的 PostgreSQL 內核數量已經來到了驚人的 10 個。

Pigsty 已經成為了 PostgreSQL 發行版的發行版，一個 “元發行版”。各家 PostgreSQL 分支內核全都能在 Pigsty 的加持下，成為一個帶有高可用，監控，IaC，PITR 的 “企業級數據庫服務”。

強力擴展更新

除了 Percona 透明加密內核之外，PG 世界中的另一個新秀內核 —— OrioleDB 也發布了 1.5 beta12 版本，Supabase 的 CEO 透露很快就會正式 GA 了。 Pigsty 也在第一時間編譯了 OrioleDB 補丁版本的 PG，以及 OrioleDB 擴展。

除此之外，還有一個有趣的擴展 pgactive，這是一個由 AWS 開發并開源的PG 多活擴展，Jonathan Katz 吹噓說它解決了亞秒級高可用切換的問題。 這個擴展依賴缺失的 pgfeutils ，編譯起來還有點麻煩，所以我也替各位打好開箱即用的二進制包了！而 pigsty 可用的擴展數量也相應來到 423 個。

此外，PG18 beta2，OrioleDB，TimescaleDB，Citus，FerretDB & DocumentDB，DuckDB，ETCD 也都迎來例行版本更新。

另外值得一提的是，現在 Pigsty 的擴展目錄也是用 Next 糊的，觀感比以前好了很多，新地址在：https://ext.pgsty.com[1]

更好的 Supabase

Pigsty v3.6 提供了更流暢的 Supabase 自建體驗。還修復了一些 Supabase 官方模板中的問題，比如，logflare 復制槽不推進的問題， 大量打印錯誤日志的問題，以及 Studio 無法查看兩項 Analytics 日志的問題。

想要自建一套生產級 Supabase 有多簡單？只需要以下幾行命令就可以完成，更詳細的說明請參考 Pigsty 網站上的 Supabase 自建教程。

而且 Pigsty 現在默認使用由 1Panel 提供的的 Docker 鏡像站點，在墻內的下載速度更快了。

目前 Pigsty 和 StackGres 是唯二兩個自建 Supabase 方案的開源供應商，Pigsty 基于裸 Linux 系統交付，而 StackGres 基于 Kubernetes 交付。

更好的 PITR

在之前的版本中，Pigsty 提供了一個 pg-pitr 的腳本，用于 “半自動” 輔助用戶完成 PITR 恢復。 在這個版本中，我們提供了專用的全自動 pgsql-pitr 劇本，用于執行一鍵時間點恢復。

Pigsty 會自動為你暫停高可用切換，關閉 PostgreSQL，生成并執行 pgbackrest PITR 恢復命令，到你指定的目標位點。 校驗之后重新拉起 PostgreSQL，重新啟用高可用切換。你還可以不斷快速重試（因為是原地增量），便于找到真正需要恢復的位點。

此外，新的 PITR 劇本還支持了一種新的用例 —— 用戶不希望在現有集群上原地進行 PITR （怕影響業務）。 而是希望新啟動一個實例（或者摘一個從庫下來）執行 PITR 恢復，然后在這個新實例上抽取數據，手工導入到現有集群中。

更好的 ETCD 管理

Pigsty v3.6 中，對 Etcd 模塊進行了重構，新增了獨立的 etcd-rm.yml 劇本與擴縮容 SOP 腳本。

在此前的版本里面，擴容 etcd / 縮容 etcd 涉及到一系列略顯復雜的命令操作。而在這個版本中，一把梭干就完了：

bin/etcd-add # 創建 etcd 集群，或者刷新現有集群狀態
bni/etcd-add 10.10.10.11 # 擴容 etcd 集群，新增一個成員
bni/etcd-rm # 移除整個 etcd 集群
bni/etcd-add 10.10.10.11 # 將 10.10.10.11 成員從集群中移除

此外， etcd.yml 劇本現在 不再清理現有 ETCD 集群，清理集群的工作現在放在了專門的 roles 與劇本中實現了。因此，etcd 集群的維護變的更加簡單明了，簡單易用了。

更好的 MinIO

Pigsty v3.6 對 MinIO 模塊進行了重構，新增了 Plain HTTP 模式，并且調整了默認的三個桶與默認用戶。

在之前的版本中，Pigsty 默認為 MinIO 啟用 HTTPS，這是通過本地 CA 簽發自簽名證書來實現的，能夠避免內網流量竊聽。 不過這也會帶來一些煩惱，如果 Pigsty 管理節點之外的客戶端，比如容器中的客戶端，需要信任這個 CA 才能訪問 MinIO。

因此在這個版本中，我們新增了一個開關，允許 MinIO 運行在純 HTTP 模式下。 不過切記，PG 備份工具 pgbackrest 是不接受使用 HTTP 模式的 MinIO 的。 如果你還是要用本地 MinIO 來存儲 PG 備份，那么還是需要使用 HTTPS 模式。 只有當你的 MinIO 純粹是給外部服務用的時候，才適合使用 HTTP 模式。

另一個 MinIO 上的改進是默認桶與權限。之前 Pigsty 會默認為 MinIO 創建三個桶：pgsql，infra，redis， 不過實際用到的只有 pgsql 桶。現在 Pigsty 默認只創建三個桶：pgsql，meta，data，并且為 meta 桶與 data 桶創建了兩個新的用戶 s3user_meta 與 s3user_data。 此外，Pigsty 現在還會為每個定義的桶創建一個同名的策略，擁有對相應桶對完整權限，并分配到三個默認用戶上，

通過這樣的設計，像 Supabase / Dify 這樣的應用就可以直接使用這兩個桶了，而不需要再手動創建桶與用戶了。

更簡單的安裝流程

在以前，Pigsty 的安裝步驟分為四步：下載，引導，配置，安裝。其中 “引導” 這一步指的是解壓離線軟件包或者配置上游軟件倉庫，從而安裝 Ansible 與依賴的過程。

在 Pigsty v3.6 中，這個步驟被合并到下載中了。當你執行 Pigsty 安裝腳本時，它會自動執行 ./bootstrap 腳本，嘗試安裝 Ansible。

所以你只需要三步就可以完成 Pigsty 的安裝了。

curl -fsSL https://repo.pigsty.io/get | bash;
cd ~/pigsty; ./configure; ./install.yml;

在這個版本中，我們還把基本所有的配置模板都調整為 單節點 模式。因此，你可以很方便的選用自己想要的配置模板來快速上手。

跳過本地倉庫

在這個版本中，默認的安裝策略發生了變化。在以前，Pigsty 都會在安裝過程中創建一個本地軟倉庫，將所有軟件包都下載到本地，然后再從本地倉庫安裝軟件包。 現在，絕大多數的配置模板都使用了另一種策略：不再先下載到本地，而是直接從互聯網上游安裝。

這里有一些非常明顯的好處，許多用戶反饋的安裝報錯都在本地 Repo 下載和 Nginx 服務拉起的階段 —— 例如 el9.aarch64 系統下直接安裝 patroni-etcd 是沒有問題的。 但如果你嘗試先下載再安裝 patroni-etcd ，就會因為 PGDG 上游的愚蠢配置錯誤導致安裝失敗。 另外，用于提供本地倉庫服務的 Nginx 也經常會因為各種安全策略，防火墻配置等問題導致無法正常啟動。

另一個顯著的好處是，安裝速度顯著提升，因為只有真正需要安裝的包才會被下載安裝，而不是一次性下載所有包。

一個明顯的洞察是，大比例的用戶安裝 Pigsty 是在一臺 Linux 單節點上，“不需要” 本地軟件倉庫提供的多節點一致性。 而需要本地軟件倉庫的用戶，使用多節點高可用安裝模式也可以通過簡單的配置（repo_enabled, node_repo_modules）重新啟用本地倉庫。 或者直接使用默認就啟用本地倉庫的 rich / full 模板。

其他改進

在 Pigsty v3.6 中，我們還對很久沒有更新的 tuned 模塊進行了優化，針對現代硬件與 NVMe 磁盤進行了優化。 移除了一些過時的配置參數，并且新增了針對 NVMe / 虛擬化 SSD 的調度/預讀參數優化。

另外，我還把 Google 新發布的 MCP Toolbox （數據庫 MCP 工具箱）給打包整合到 Pigsty 中了。 這種預置模板 SQL 的方式解決了一部分數據庫安全性的問題，應該可以在一些場景中試點使用。

全新的網站

另一個有趣的更新是 Pigsty 的文檔站點，正如《》所說，Pigsty 現在有了一個全新的文檔站點：https://doc.pgsty.com。[2]

這個站點是用 Next.js 與 Fumadocs 現代前端技術棧打造的。來自蘭天游老板和 Claude Code 的強力助攻，糊出了一個像模像樣的現代文檔站點。

這個文檔站點使用英文作為默認語言，目前已經基本完工，中文部分正在翻譯建設中。如果有感興趣的朋友可以直接在 Github 上 PR 或者提 Issue。

下一步是什么？

PostgreSQL 18 將于今年 9 月份發布，Pigsty 準備在 PG 18 發布后正式發布 v4.0 版本。 v4.0 版本主要計劃有以下幾個方面的改進：

?命令行工具 pig 完整封裝 Ansible 劇本功能，接口初步定型?監控系統全面升級，使用 VictoriaMetrics / VictoriaLogs 替代 Prometheus / Loki?使用 vector 替代過時的 promtail 作為日志收集組件?考慮使用 Caddy 替代 Nginx 作為網站門戶，但還沒決定

Pigsty v4 最大的改動就是日志收集部分，在數據庫模塊上的調整目前已經在 v3.6 完成了。

另一個目標是等新版的英文文檔站足夠成熟，我也準備在海外開始進行一些宣傳與推廣了。 目前來看，生態對 PostgreSQL 的需求非常旺盛，這是個極好的機會，搶占 PostgreSQL 中的 Debian / Ubuntu 發行版的生態位。

v4.x 的主旋律將會是 DBA Agent。 Pigsty 已經擁有了一個 DBA Agent 所需的完整上下文，核心就是這個 PG 最強監控系統。 等文檔中沉淀的領域知識足夠豐富，給 Pig 命令行工具套上 MCP，一個能打的全自動駕駛數據庫 DBA Agent 就誕生了。