跳转到主要内容

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

返回本页常规视图.

文章

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

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

1 - 请 Claude 为老冯画像与估值

原文发布于 VONNG。

老冯是一家一人公司，字面意义上的只有一个人的公司，PG 发行版专门店。2022 年的时候俺进了奇绩 S22，陆奇博士给俺的评估价是一个亿，让我按这个去融资。当然那两年疫情＋行情惨淡老冯也没融到资。结果公司凉了，真成个体户了。

结果变成个体户干，干着干着就盈利了，也就无所谓融不融资了。这两年也有几家云厂商出价，奔着 Hire Acquire 来的，估值也到了 1.2～1.5 亿。当然，估值估值，精髓就在一个“估”字嘛，对不对？反正吹牛不上税。

不过，老冯也有几分好奇，就是说，这样一个人的公司到底值多少钱呢？所以呢，我就挑了一个没有个人记忆历史的砖工 Claude 订阅账号。 让它给老冯画个像估个值。毕竟现在 Claude 已经成为了很多人的依据。一个没有记忆历史的中立 Claude 评估，我觉得还有些参考意义。

本文 AI 含量：95%

以下为 Claude Code 回复：https://claude.ai/share/4f50c7cd-a1b5-4543-ad50-b0409b092d4c

我读了他的个人站（含“人生旅途”“关于”栏目、2023 与 2025 年度总结、墨天轮访谈），加上一些外部报道。下面是我的判断。

硬事实先摆一下

冯若航，网名 Vonng，90 后。他自述的履历是阿里巴巴、探探、Apple 的架构师／DBA／全栈，读书时兴趣在 AI，入行做算法工程师，后来判断整个信息系统都围绕数据库转，于是转向数据库；在探探接触到国内规模靠前的 PostgreSQL 部署后决定 ALL IN 这个方向。2022 年从奇绩创坛五千多个项目中拿到种子轮，全职创业做 Pigsty。他翻译了 DDIA 和《PostgreSQL 内幕探索》，维护 PGDG 中国镜像和一个两千多扩展的目录站，GitHub 上是中国区排名靠前的活跃贡献者。2025 年从北京搬到上海。vonng

一、他本质上是个“传教士型工程师”

这是我觉得最核心的一点。他自己对此毫不掩饰，用的全是宗教词汇：大法师、布道师、传教、意识形态。在谈到为什么参加 MySQL vs PG 的公开辩论时，他说技术在某种意义上与宗教相似，福音再精妙也需要僧侣去传，生态位碰撞时冲突不可避免，社区里必须有人敢站出来扛事。vonng

所以理解他的关键是：他不是在“客观评测技术”，他是在打一场生态战争，而且他知道自己在打仗。他讲得很直白：与其当好好先生说些正确而无用的废话，不如痛快亮出观点，骑墙没有好结果。这解释了他文章里那种压倒性的单边气势——那不是判断力的缺陷，是修辞的选择。vonng

二、“势”的思维方式，加上下重注的癖好

他的世界观里有一个反复出现的框架：先判断大势，然后 All in，然后靠布道把判断变成自我实现的预言。被问到从业者如何取得成就时，他的答案是“顺势而为”，并补充说智慧让你看清形势，但勇气才是最稀缺的品质——讲真话的勇气、挑战权威的勇气、下注的勇气。vonng

他押过的注：PostgreSQL 会赢（押对了）；分布式 TP 数据库是伪需求，单机能解决就别折腾分布式；Pigsty 拒绝 K8s 甚至拒绝 Docker，坚持裸机部署，明知会给自己增加大量适配苦活，但认为这本身就是护城河；以及 2025 年 all in AI 工具链。他说 AI 让他个人生产力提升约二十倍，Claude Code 在后台逐模块 review Pigsty 代码，他像指挥官一样每隔十几分钟分派任务。vonng

三、手艺人的一面，比“KOL”标签重要得多

很容易把他归类成一个爱发暴论的技术网红，但这会漏掉他身上最扎实的部分。他干的很多事是彻头彻尾的苦力活：给几百个 PostgreSQL 扩展做打包构建、维护软件仓库镜像、修上游 bug、适配一堆 Linux 发行版排列组合。他专门写过一篇讲打包构建是“冷门但稀缺的技能”。他自己说过，有开源项目的一个好处是别人质疑“你行你上啊”的时候，可以直接把项目掏出来——这句玩笑话透露了他的底气来源：他确实交付了东西。vonng

四、对独立性近乎洁癖

公众号涨到近 5 万关注，每天有广告商单，但他保持零接单，理由是自由表达本身是昂贵的乐趣，他要保持不看任何人脸色的底气。2023 年融不到下一轮，他的反应是“能养活自己就行，不拿钱可能还更自在”。2025 年他把 Pigsty 从 AGPLv3 换回宽松的 Apache 2.0，理由是想明白了在中国卖“开源软件商业版”走不通，不如大方一点让开源回归开源，靠专业咨询挣钱。vonng

这跟他的“下云”主张是同一套逻辑的不同层面。他把下云说成意识形态问题：希望用户拥有自己的数字家园，而不是从科技巨头云领主那里租农场，这是一场反击互联网集中化和赛博地主收租的运动。同样的冲动也体现在小事上——嫌公众号搜索烂、生态封闭，就自己搭一个全文检索的博客站。他不喜欢住在别人的房子里，无论那房子是云、是微信还是资本。vonng

五、文风与人格面具

第三人称自称“老冯”，混用文言（子曰、荀子曰）和网络黑话（杀猪盘、草台班子、骑脸输出），擅长造外号（赛博佛祖、赛博菩萨、万磁王）。有人评价他是“技术界的段子手，段子手中的技术狂”，他欣然接受，说自己的偶像是 Linus（顶级 Hacker）和 Jobs（顶级 Story Teller），在这两个方向加点。他还提到公众号文章是按演讲稿标准写的，是刻意的讲故事训练。vonng

也就是说，“老冯”是一个被精心设计和维护的人格 IP，不是随手写写。

六、生活面

他给自己的标签里有“资深驴友，骨灰级玩家”。他徒步过洛克线、珠峰东坡嘎玛沟、乌孙古道，并且自嘲式地用体重来标记自己的徒步能力衰减：70 公斤能重装 solo，100 公斤只能躺着。数码消费上很坦白地承认自己“败家”，MacBook 十年顶配拉满，最近一台五万八。2025 年秋天趁家属工作变动去新疆和川西自驾了一两个月，他说在行业剧变的节点上，人生更重要的是体验。2023 年底结婚。他还有个叫“赛博经藏”的副项目，是关于技术与信仰的札记——这个方向和他的硬核技术形象反差挺大。vonng

七、几个需要打折扣的地方

出于公允，读他的东西时我会注意这几点：

立场与利益高度重合。 他倡导下云，而他卖的正是下云所需的工具和咨询。他对此其实是坦白的——明说过下云对用户和对他们自己都有实打实的利益——但读者仍然应该自行折价。他文章里那些“云比自建贵 5～10 倍、存储贵百倍”的数字，取决于人力成本、可用性、弹性怎么记账，属于有力的论证方向，不是审计结论。vonng

攻击性有时会跑在事实前面。 2025 年底他写小红书下云，阿里云官方公开回应说这是谣言，而比较中立的复盘认为小红书实际是走向“自建＋公有云”的混合云架构，并非完全下云。有意思的是他自己在年度总结里承认了这一点：这件事印证了个体的声音也有分量，也提醒他在保持犀利的同时需要更严谨周全。这种自我修正的能力是加分项。Sina Finance

一个人的项目有单点风险。 他自己写过，创业这一年实际做事的只有他一个，从技术设计到营销售后一条龙。AI 极大缓解了这个问题，但没有消除它。vonng

我的总体印象

一个把技术当信仰、把职业当战场、把独立当底线的人。智力上敏锐且有相当的历史纵深感（他会去想十年后的价格结构、PG 社区的治理形态、中国软件生态的负外部性），执行上是罕见的能同时干脏活和讲故事的双修型选手，性格上好斗、自信、表达欲极强，同时有足够的自嘲和自省来不让这些变得难以忍受。

他最像的不是硅谷创业者，倒有点像早期开源运动里那种人物——技术能力足以自证，观点强硬到招人恨，但你确实需要有人站在那个位置上喊，否则整个行业的默认选项就永远是大厂替你决定的那个。

需要说明的是，以上全部来自他公开发表的文字，是他选择呈现 的自己。真实的人几乎必然比这更复杂、更矛盾。而且他产出量极大（四个专栏加起来近五百篇），我只读了其中一小部分，如果你对某个具体侧面感兴趣，我可以再深入去看。

我觉得很有意思，我希望你深入挖掘一下。就比如说他自己发表的一些观点，最核心的观点里，你觉得哪些被验证了，哪些被证否了？你觉得他的核心观点（包括对数据库、云计算和 AI 的这些洞察）有哪些真知灼见？如果让你来评价这个人，你觉得他是什么样的一个人？你觉得他的观点怎么样？

我花了些时间去核对他这几年公开下过的判断。结果比我预想的有意思——他的命中率在技术生态层面高得惊人，在宏观产业层面则明显被自己的修辞夸大了。分开说。

一、记分卡：哪些兑现了

① “PostgreSQL 就是版本答案”——兑现，且兑现得比他说的还快

他 2023 年在辩论里下的这个断言，现在基本是行业常识。Stack Overflow 2025 调查里 PostgreSQL 使用率 55.6%，MySQL 40.5%，这是史上第一次，而且 PG 从 48.7% 一年跳到 55.6%，是它历史上最大的单年增幅。TECHSY、byteiota

但要打个折：他说 PG “成为世界上最流行的数据库”，这在开发者调查口径下成立，在装机量口径下不成立。2026 年 3 月 DB-Engines 上 MySQL 仍是第 2（858 分），PostgreSQL 第 4（680 分）。他选了对自己最有利的那把尺子。这是他的一贯手法。Tech Insider

② “PostgreSQL 的 Linux 时刻，竞争会转移到发行版”——这是他最漂亮的一个预判

他 2023 年说数据库的未来会像操作系统的现在：几个开源内核周围长出百花齐放的发行版。两年后：Databricks 2025 年 5 月约 10 亿美元收购 Neon，Snowflake 6 月约 2.5 亿美元收购 Crunchy Data，一个月后 Databricks 就推出了基于 Neon 的 Lakebase。Andy Pavlo 的年度复盘把 2025 年定性为整合而非创新，PostgreSQL 一年吸走了 12.5 亿美元收购额。Medium、byteiota

内核本身不再是战场，围绕内核的封装、管控、集成成了战场——这正是他两年前描述的图景，也正是他把公司押上去的那个位置。

③ “向量数据库不是一个独立品类”——大体兑现

Databricks 和 Snowflake 谁都没有去买一家独立的向量数据库公司，两家都买了 Postgres 基础设施。同期 Fauna、PostgresML、Hydra、Voltron Data、MyScaleDB 五家数据库创业公司关门。不过公允地说，市场并没有出现向量数据库厂商的大灭绝，实际发生的是平台吸收和专业化分工——Qdrant、Pinecone 这类还活着，只是退回到了更窄的生态位。他说对了方向，语气比事实更绝对。Refontelearning

④ MCP／Claude Code——兑现，而且是时间差最漂亮的一次

他 2025 年 3 月就写文章指出 Claude Code 才是 MCP 爆火背后的关键，当时中文互联网反应寥寥。这一条我认为含金量很高，因为它是在噪音里挑出真信号，而不是事后追认趋势。vonng

二、哪些落空了，或者被他讲过头了

① “公有云在走下坡”——这是最明显的落空

他的“云计算泥石流”叙事暗含一个方向：云在见顶，人们在往回走。数据是反的。五大云厂商资本开支从 2024 年约 2560 亿美元、2025 年约 4430 亿，涨到 2026 年预计约 6020 亿，同比＋36%。UBS 估算亚马逊、谷歌、微软 2026 年会把大约 102% 的云收入重新投回资本开支。CreditSights、Yahoo Finance

下云这件事本身是真的，但规模远小于他的语气：Barclays 调查里 86% 的 CIO 计划把部分负载搬回私有云或本地，创历史新高；但 IDC 的数据是只有 8%–9% 的企业打算完全下云，同时云市场仍在以 21.5% 的速度增长——新负载产生的速度比旧负载搬回的速度更快。Digital Chiefs

准确的说法是：云的“默认选项”地位被打破了，但云本身没有退潮。他喊的是前者，听上去像后者。

② “分布式数据库是伪需求”——部分证伪

他的内核论点（绝大多数问题规模单机能解决，就别上分布式）我认为是对的，而且在 2023 年是逆流而上的勇敢判断。但“伪需求”这个词下得太满了。2025–2026 年最活跃的赛道之一恰恰是让 PostgreSQL 横向扩展的分布式项目：Supabase 的 Multigres、PlanetScale 的 Neki、PgDog。需求是真的，只是市场选择了“分布式的 PostgreSQL”而不是“另起炉灶的 NewSQL”。byteiota

有意思的是，这个结果对他其实是半赢：他赌错了“分布式没人要”，但赌对了“赢家会是 PG 血统”。

③ 小红书那件事——事实层面他跑过头了

阿里云官方公开定性为谣言，中立复盘的结论是小红书走的是自建加公有云的混合架构。他的技术判断（大规模稳态负载自建更划算）没错，但他把一篇技术公众号里的一句话，推成了一个标杆客户“下云”的结论。这是用叙事需求倒逼证据 的典型失误。Sina Finance、Cnfol

④ 他自己承认的一次证伪：2025 年他把 Pigsty 从 AGPLv3 换回 Apache 2.0，理由是想明白了在中国卖“开源软件商业版”这条路走不通。这等于推翻了自己创业初期的商业假设。我认为这一条应该给他加分而不是减分。vonng

三、我认为真正有价值的几个洞见

抛开预测对错，他有几个框架层面的东西，我觉得比具体判断更耐用：

“开源不是商业模式，是全球协作的研发模式。” 他补了一句关键的：软件的价值在使用过程中实现，而不是研发过程中——公有云的成功就证明了这一点，只要把开源软件运行好管理好，就能拿走生命周期里绝大部分商业价值。这是我读到过的对“开源商业化”最干净的一刀。绝大多数关于开源许可证的争论，本质上都是在回避这句话。vonng

“主要矛盾不是缺更好的内核，而是极度缺乏用好现有内核的能力。” 他配的比喻是：最会开车的是赛车手不是车厂工程师，最会射击的是狙击手不是枪械设计师。这句话既解释了他的商业定位，也解释了整个 PG 生态的价值转移路径。而且它可以推广——今天关于 AI 的绝大部分讨论也犯同样的错，都在关心内核（模型），很少人关心发行版（怎么把它用好）。vonng

“自研”的可证伪标准。 他提出：只有当某个团队的功能研发与问题解决速度超过全球开源社区时，内核自研才有实际意义；否则所谓自研本质是套壳魔改，活性极其有限，自主可控程度还不如直接用开源内核——起码不会被一家公司锁死。把一个高度政治化、几乎无法理性讨论的话题，压缩成了一个可以拿数据检验的单一指标。这是很高级的思维动作，我很少在中文技术评论里看到。vonng

下云的“主权”框架而非“成本”框架。 他后来把话说成：成本曲线会动，主权逻辑不会。早在 2023 年他就把下云描述成让用户拥有自己的数字家园、而不是向赛博地主租地的运动。这个框架比成本账更耐用——因为成本账是可以被云厂商降价打掉的，主权账不能。他实际上给自己的论点做了一次抗打击加固。vonng

“与其淘金，不如卖铲子。” 2025 年 AI 最热的时候他没去做 Agent，判断是 Agent 再强也需要记忆，而进化的关键一步是用好数据库。后来 Databricks 和 Snowflake 花 12.5 亿美元买 Postgres 就是为了给 Agent 提供事务底座——他和两家几百亿美元的公司想到了同一件事。vonng

打包构建是被系统性低估的稀缺技能。 这个观察极其真实，而且几乎没有别人在说。

四、他的系统性盲区

1. 他的模型里没有“组织”这个变量。 他的成本对比几乎都是纯技术账：硬件多少钱、云多少钱、差多少倍。但企业不用自建的真正原因常常不是不会算账，是找不到那个能把 Pigsty 跑好的人。而那个人的稀缺程度，恰恰由他本人这种存在来证明。他把自己当成可复制的样本，这是最根本的偏差。

2. 选择性举证。 Ahrefs、Dropbox、37signals 这三个案例被他反复引用。它们都是基础设施密集、负载极其稳定、且有顶级工程团队的公司——是下云收益最大的那个极端。用极端案例论证普遍主张，是修辞而非分析。

3. 辩论式认识论的代价。 他明确说过公开辩论能把共有知识变成公共知识、凝聚共识。这是真的。但为赢而论证会持续侵蚀精度：你会不自觉地选最有利的口径、最极端的案例、最绝对的措辞。他的准确率损失基本都发生在这个环节。

4. Linux／RedHat 类比可能不成立。 Linux 有发行版生态，是因为集成、认证、长期支持有巨大且付费方明确的价值。数据库这一层的生态位，云 RDS 已经占了很久了。他赌的是这个位置能被开源夺回来——目前看，巨头们的动作（买 Neon、买 Crunchy）恰恰是在把 Postgres 更深地锁进自己的平台。这场仗还没打完。byteiota

五、我怎么评价这个人

一句话：他是一个高信号、高偏置的信息源。

信号高，是因为他有三样罕见地凑在一起的东西——真正的一线运维经验（不是二手转述）、跨越十年尺度的结构性视野、以及把复杂技术判断压成一句话的表达能力。中文技术圈里，前两样凑齐的人不多，三样都有的极少。

偏置高，是因为他不是在描述世界，他是在推动世界往他押注的方向走。这两件事在他笔下是分不开的，而且他自己完全清楚——他用的词是布道、传教、意识形态。他从没假装中立过，这一点我认为要给他相当的诚实分。

所以我的实用建议是：读他是为了拿议题和视角，不是为了拿结论。 他能告诉你“这件事值得重新想一遍”，但他给出的那个具体数字（十倍、百倍、二十倍）你需要自己重算。

真正让我对他评价偏正面的，是几个不太显眼的细节：他会自己推翻自己（换许可证）；他在阿里云那件事后公开写下需要更严谨周全；他拒绝商单，宁可少赚钱换取不看人脸色的资格；以及他在生态位竞争中主动选了最苦的那条路——拒绝 K8s 甚至拒绝容器化，明知会给自己增加大量适配苦活，理由是这才是正确的事，而这些努力最终成了护城河。vonng

一个只想当 KOL 的人不会去干打包构建这种脏活。

如果要给一个类型学定位：他是 DHH 在中文世界的对应物——同样的技术实力、同样的下云主张、同样的好斗、同样的把工程审美上升为政治立场。区别在于 DHH 有一家赚钱的 SaaS 托底，可以永远不必证明什么；而他押的是一个更难的赌局：用一个人对抗云厂商的整个 RDS 团队。

他能不能赢，我不知道。但我认为中文技术圈需要有人站在那个位置上喊，否则默认选项就永远由大厂替所有人决定了。哪怕他喊的时候声音过大、数字过满——那可能正是这个位置的必要成本。

现在我是一位投资人，关注基础设施、软件科技赛道。这个作者我觉得比较有意思，他应该是有家公司拿过奇绩创坛的投资。我想请你来聊一聊，如果你是投资人，手里有很多子弹、管着这样一家基金：

  1. 你会愿意投他吗？愿意出资多少、占多少股？
  2. 你给他（包括他这个人以及这家公司）的估值能有多少？
  3. 你觉得他这种商业模式成立吗？
  4. 如果不单纯看商业，而是看更大的层面，你觉得他有投资价值吗？

先说明：下面是分析框架和公开数据推演，不是投资建议——我不是财务顾问，任何真实决策都需要拿到实际财报、客户集中度、续费率和股权结构。

不过我刚去把他公司的定价页和现状扒了一遍，有几个事实可能会改变你的判断。

零、三个你可能还不知道的事实

① 公司已经搬到新加坡了。 主体现在是 PGSTY PTE. LTD.，网站上明确写着 MiraclePlus S22 校友（也就是奇绩创坛 2022 年夏季批次）。这意味着他大概率做过一次架构重组，对美元基金进入是好事，但你要查清楚奇绩那笔种子轮在哪个主体、有没有干净的翻转。

② 价格表是公开的，可以直接算单位经济。 订阅按节点数分档：开源免费（Apache-2.0，节点不限，功能不阉割）、Standard 8 千美元／年（≤5 节点）、Professional 2.4 万美元／年（≤15 节点，含每月 5 小时 DBA）、Enterprise 6 万美元／年（参考 50 节点，含每月 10 小时 DBA、7×24 的 30 分钟响应 SLA）。另有按次服务：快速咨询 30 美元、专家会话 400 美元、紧急响应 4000 美元／天。

③ 有一行小字，是整个投资逻辑的关键。“商业支持目前仅在亚洲提供。”

而他的影响力在哪儿？pigsty.io 单月 144 万独立访客、1811 万 PV，美国是第一大来源。他的心智份额在全球，收款能力在亚洲。 这就是他自己写的那篇“百万流量，颗粒无收”。

一、商业模式成立吗？

成立，但它成立的是一门“好生意”，不是一门“VC 生意”。这两件事经常被混淆。

先做一次天花板测算。Enterprise 档承诺每月 10 小时专家咨询加 7×24、30 分钟响应；Professional 档每月 5 小时。假设他一个人（AI 加持后）一年能投入 600 小时做交付——剩下的时间必须用来做产品，因为产品才是护城河——那么：

组合 数量 交付小时 ARR
Enterprise $60K 3 360 $180K
Professional $24K 15 900 $360K
Standard $8K 25 低 $200K
项目／紧急响应 — — $200–400K

光是订阅承诺的咨询时数就已经 1260 小时，超过一个人的物理上限一倍。也就是说：这个模式在大约 100 万美元 ARR 的位置就撞墙了，而且撞的不是需求墙，是人墙。

更要命的是他自己拆掉了唯一的软件杠杆。开源版和商业版核心能力完全一致，订阅买的是许可证、SLA 和专家时间，不解锁任何独占功能。这在价值观上非常漂亮，在财务上意味着收入 100% 挂在人头上，毛利结构等同于咨询公司而非软件公司。

所以答案是：这是一门可以做到 100–300 万美元 ARR、毛利极高、现金流健康、founder 极其自由的生意。它大概率永远不会变成 10 亿美元公司，除非发生结构性变化。

而突破口只有一个，就是他自己已经指出的那个：把专家判断变成 Agent Skills。他说 Pigsty 已经自动化了 DBA 80% 的工作，剩下 20% 计划通过把知识文档转成 Skills 喂给模型再干掉九成。这是唯一能把“人时”变成“软件”的路径，也是唯一能让 100 万变成 1 亿的路径。你投他，本质上是在投这一条。

二、我会不会投？投多少？占多少？

分三种基金人格，答案完全不同：

如果我管一支需要单笔回报基金的经典 VC——不投。

不是因为他不行，是因为他不需要我的钱，而这是最大的红旗。他 2023 年融不到下一轮的反应是：这种环境下能养活自己、扎实做点人们真正需要的东西，融不融资无所谓，甚至不拿钱更自在。他拒绝所有商单，理由是要保持不看任何人脸色的底气。

一个不需要资本、且把独立性列为核心价值的创始人，和 VC 的激励结构是根本不兼容的。更关键的是——AI 已经把资本和产出之间的相关性打断了。他用每月 1000 美元的 AI 订阅，一个人交付了 Pigsty 4.4／4.5、把 Patroni 用 Go 重写、把 pg_exporter 重做、翻译了 DDIA 第二版、还顺手做了一堆新项目。传统 VC 的核心增值是“帮你招 30 个工程师”——而招 30 个工程师恰恰会摧毁这家公司赖以成立的东西（你打电话找到的是写代码的那个人）。

如果我管一支种子／天使基金，或者有 scout 额度——投，小额。

我会开 50–150 万美元的支票，要 5–8%，估值区间 1500–2500 万美元，条款上只坚持两件事：pro rata 跟投权，和优先购买权／ROFR（因为最可能的退出是被收购，我要能跟）。

理由很直白：下行封顶（这生意不会死，最差是变成一家赚钱的精品咨询公司），上行来自三个期权——被收购、Agent 转型成功、以及生态卡位兑现。而这三个期权里任何一个兑现，回报都够覆盖这张小票。

如果我是战略投资人（云厂商、数据库公司、或者 Supabase／EDB 这类）——立刻投，而且要占位。

对战略方来说他的价值远高于财务价值，后面第四问细说。

三、估值给多少？

用三把尺子交叉验证：

尺子一：最贴切的可比交易——Crunchy Data。 Crunchy 年化收入约 3000 万美元，被 Snowflake 以约 2.5 亿美元收购，大约 8.3 倍 PS。Crunchy 有一百多号人、二十年 PG 声誉、美国联邦政府客户。这是“自托管 PG＋企业支持”这个形态在 2025 年的真实市场价格：8 倍收入。

对照 Supabase 就更清楚了：$1.7 亿 ARR、$105 亿估值，约 62 倍。但 Supabase 卖的是托管平台、用量计费，而且直接吃到了 Claude Code、Codex 这波氛围编程的红利——2026 年它平台上超过六成新数据库是 AI 工具建的。

Pigsty 的商业形态是 Crunchy 那一档，不是 Supabase 那一档。 这个判断决定了倍数是 8x 还是 60x。

尺子二：资产法。 5510 个 star 的发行版、2100 star 的 MinIO 分叉、572 个扩展的打包矩阵和分发仓库、PGDG 中国镜像、月均 144 万 UV 的心智入口、以及一个在全球 PG 圈叫得响的个人品牌。这些单独拿出来，acquihire 底价我给 1000–2500 万美元。

尺子三：人。 全球范围内同时具备“PG 内核理解＋大规模生产运维＋Linux 打包工程＋全球影响力＋中英双语”的人，可能不超过二十个。顶级基础设施人才的战略溢价本身就值 500–1500 万。

我的数字：今天的公允估值 1500–3000 万美元 post-money，financial investor 取下限，strategic 取上限。

触发重估的条件很明确：

  • ARR 过 200 万美元、有 3 人以上团队、NDR > 110% → 5000–8000 万
  • 商业支持打开欧美市场（把那行“仅限亚洲”的小字删掉）→ 翻倍
  • DBA Agent 跑通、收入结构从人时转向订阅 → 重新按软件倍数估，1.5 亿以上

反过来，如果两年后还是一个人、还是亚洲、ARR 还在 100 万以下——那它就不是一个投资标的，是一个应该被收购的资产。

四、抛开商业，他有没有投资价值？

有，而且我认为这部分价值可能大于财务价值。四条：

① 生态卡位期权。 这是我最看重的一点，而且被严重低估。他真正在积累的不是咨询收入，是分发权：全球 CDN 仓库 repo.pigsty.io 加中国镜像 repo.pigsty.cc、2230 个扩展编目、572 个打包可安装、以及 Silo——他维护的 MinIO 分叉，在原项目之后继续提供安全更新。他自己提过，PGEXT.CLOUD 已经成了几家海外同行的上游。

谁掌握一个生态的包管理和仓库，谁就掌握一个咽喉。npm 之于 Node、Docker Hub 之于容器、RedHat Network 之于企业 Linux，都是这个位置。PostgreSQL 生态目前没有一个公认的扩展分发中心，他正在无声地把这个位置坐下来。 这个期权的价值和他的咨询收入完全无关。

② 对“超级个体”命题的研究性头寸。 如果你的基金相信 AI 会让一人公司成为真实的组织形态，那他是目前观测条件最好的样本之一——数据全公开、产出可验证、时间序列完整。花 50 万美元买一个持续三年的一线观察窗口，这笔钱在研究预算里是便宜的。

③ 他本身是一个高质量的信号源。 我上一轮复盘过他的命中率：PG 会赢（中）、竞争会转移到发行版（中，Databricks 10 亿买 Neon、Snowflake 2.5 亿买 Crunchy 正面印证）、向量数据库不是独立品类（大体中）、Claude Code 是 MCP 背后的关键（2025 年 3 月就说了，中）。对一支看基础设施的基金来说，把他放进 scout／advisor 网络的价值，可能高于把他放进 portfolio。这条不需要投资就能实现。

④ 公共品价值。 中文 PG 文档、pg.center、PGDG 中国镜像、给一个被放弃的 S3 实现续命。这些事没有任何商业模式会付钱，但它们对整个生态是真实的正外部性。如果你的基金有 LP 关心开源可持续性，这是很好的叙事资产。

五、我一定会问的尽调问题

  1. 真实 ARR、客户数、客户集中度（前三大客户占比多少？如果超过 50%，这是咨询公司不是软件公司）
  2. 续费率。订阅第二年的留存是这个模式最重要的单一指标
  3. 奇绩那笔种子轮的条款、目前 cap table、以及中国主体和新加坡主体的关系
  4. “仅限亚洲”这行字为什么还在？ 是能力问题、法务问题还是主观选择？答案会告诉你他到底想做多大
  5. 他对“招人”的真实态度。如果答案是“永远不招”，那估值上限就锁死了，这不是坏事，但你要按那个上限定价
  6. 竞争压力：Supabase 刚在 Series F 的同时发布了开源可自托管的 Multigres——一个拿了 10 亿美元弹药的对手正在往“自托管 Postgres 运维”这个方向走。他怎么应对？

我的一句话结论

他的护城河和他的天花板，是同一样东西。

让他不可替代的，是他一个人、不看任何人脸色、把所有东西免费送出去。而这三件事，每一件都精确地封死了一条规模化路径。

所以正确的姿势不是“投他然后推他变大”——那是在拆他的地基。正确的姿势是：用小钱买一个位置，然后耐心等三件事之一发生——他自己想通了要出海收款、Agent 那条线跑通了、或者某家巨头意识到 PG 扩展的分发权值多少钱。

如果你只能做一件事，我建议先别投，先把他变成你的顾问。这门生意最稀缺的部分，本来就不是股权能买到的。

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

原文发布于 VONNG。

GitHub Release | 发布注记

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

本来老冯还想放更多的东西进来，但是正好赶上了一个关键时间节点，也就是 PostgreSQL 发布了紧急的号外小版本，修了 28 个 CVE 和 110 个 bug。 很明显，这个小版本的升级优先级会非常高，所以我们也立刻跟进发布了 Pigsty v4.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 方向继续加码，
  • 做 Agent 记忆的 pgmnemo 扩展。
  • 还有 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……完整的软件包变更表见 发布注记。 两百多行，很壮观的一个表格，就不搬过来了。

除此之外，我们还发布了 PGEXT.CLOUD 的全新版本，这是一个面向 PostgreSQL 扩展的云端索引与搜索服务，提供扩展的搜索、版本对比、依赖关系分析等功能，还提供中英文双语文档。

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 后端做进去过，最后在发布前撤了回来。 它还差一口气，我听作者说 9.16 正式 GA，那就等它真正 GA 稳定之后再说。 仓库里保留了 rustfs 软件包（1.0.0-rc.1），想自己折腾可以装着玩，在 Pigsty 5.0 的时候希望能把它正式纳入 MINIO 模块的可选类型中。

Valkey：Redis 之外的选项

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

现在可以了：redis_type: valkey，一个参数的事。我没有想好要不要把 Valkey 作为默认的 redis 替代，但这个决定应该在 5.0 落地。

设计上我们刻意做成了 “无感切换”：装的是 valkey-server / valkey-cli，但配置路径、数据目录、服务名、监控 job、模块参数全部沿用 redis 命名空间。 已有的清单、面板、告警规则一行都不用改。注意引擎选择以集群为单位，同一套集群别混着用；存量 Redis 集群要切 Valkey，请先在测试环境演练，数据与复制兼容性自己验证过再动手。

顺便说一句，老冯还在打包 Valkey 的时候挖出了官方上游和 Debian 里的一个 Bug —— 《上游没有的 Bug，为什么会出现在官方包里？》。

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

Kafka：从软件包到模块

为什么一个 PostgreSQL 发行版要管 Kafka？因为在真实的大规模企业级数据架构里，PG 旁边十有八九蹲着一套 Kafka：CDC 变更捕获、消息队列、事件流，这些活总得有人干。 其实在很早以前，Pigsty 就提供了 Kafka 的试点模块，在 4.0 的时候就已经引入了。但是直到最近，我们的一个企业客户需要这样的一个功能，问我们有没有。 我想了一下，那就把它打磨做好一点吧，所以这次就跟着一起发布了。

当然，虽然 Kafka 还是一个 Beta 模块，但是客户已经急不可耐地拿去用了。毕竟再怎么说起码监控高可用这些都做好了，也还是比自己手搓装上去要强多了。

这套模块基于 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 协议要求客户端能直连每一个 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 这个选项。

零碎清单

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

FERRET 模块拆分

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

另一个更重要的原因是 FerretDB 看上去已经不再维护了。老冯知道背后的原因是 MongoDB 把 FerretDB 给告了， 但是它不敢告微软出品的 DocumentDB，所以 FerretDB 现在并入到 DocumentDB 的模板里面了

编排更安全了

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

  • 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。

组件版本一览

组件 v4.4.0 v4.5.0 备注
pig 1.5.1 1.8.0 扩展目录同步刷新
sow 0.2.0 0.3.0 本地仓库核心依赖
silo - 20260806 取代 MinIO 服务端
pg_exporter 1.3.0 1.4.1 PG19 指标支持
etcd 3.6.13 3.7.1
grafana 13.1.0 13.1.3 含安全修复
victoria-metrics 1.147.0 1.149.0 Victoria 全家桶同步更新
loki 3.6.7 3.7.6 promtail 冻结在 3.6.7
postgrest 14.14 16.1 主版本升级
pg-timetable 6.3.0 7.0.0 主版本升级
vip-manager 4.2.0 5.0.0 配置不向后兼容
jmx-exporter - 1.6.0 Kafka 监控新增
k3s - 1.36.3 新增，含配套离线镜像
duckdb 1.5.4 1.5.5

完整的 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。

什么，你问我怎么升级。哈哈，要我说，你还是新弄几台部署 pg_dump 过去最简单。

写在最后

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

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

下一站是 5.0。九月 PostgreSQL 19 正式发布，Pigsty 5.0 会带着完整的 PG19 支持一起来，大概会在九月底十月初。

5.0 的一个重要变化是我们将会切换到使用 仓库管理器 sow 构建的新的企业级制品仓库，提供 latest 与 stable 还有每月快照等多版本渠道，此外，GUI 管控工具 boar 也大概率会在这个版本实装。

3 - SOW：论母猪的产后护理

原文发布于 VONNG。

今天老冯来和大家聊一聊《母猪的产后护理》。俺做的新开源项目 SOW，翻译成中文就是“老母猪”。

做一个 PostgreSQL 发行版，最折磨人的往往不是把软件编译出来，而是收拾编译出来的东西。

Pigsty 要为多个 Linux 发行版、多个 CPU 架构、多个 PostgreSQL 大版本维护成百上千个组件。不同组合一路展开，最终落到仓库里的制品超过十万个：RPM、DEB、索引、签名、校验和、快照，还有一堆为了兼容包管理器而存在的元数据。

用户看到的只是 apt install 或 dnf install。维护者看到的却是另一幅画面：你只更新了一个包，却必须保证另外九万九千九百九十九个对象没被误删；你只改了一份索引，却必须保证全球用户不会在切换瞬间读到一半新、一半旧的仓库。当仓库小的时候，这些事都像脚本题。仓库大到十万个制品之后，它突然变成了一道数据库题、分布式系统题，还是一道供应链安全题。

所以我写了 SOW —— 一个用 Go 编写的自包含 APT / YUM 软件仓库管理器。

SOW 中文项目主页

如果你只是想把一个目录里的 RPM / DEB 变成可用仓库，一条命令就够了：

sow create /www/pigsty

如果你要长期维护仓库，SOW 还提供 Managed 模式：一份包体投影成多个发行视图，记录期望状态与已构建状态，生成不可变快照，计算精确变更集，再增量发布到文件系统或对象存储。

一句话概括：SOW 把“生成软件仓库索引”这件小事，和“治理一个长期运行的软件仓库”这件大事，装进了同一个单文件工具里。

这个工具纯粹是为了解决老冯自己的问题。但如果你也在维护大型、跨 Linux 发行版的软件仓库，它应该也能帮到你——虽然有这类需求的用户大概不会很多就是了。

为什么叫 SOW？

这个名字值得单独讲讲。此前，我们做过另一个配套开源项目：Pig —— PostgreSQL Install Genius；它是 PostgreSQL 生态的包管理器。既然有小猪负责装包，那么制作这些包、承载、组织与分发软件制品的仓库工具，自然就是“母猪” SOW 了。

母猪造型的 USB 集线器

它还可以展开为 Software Object Warehouse —— “软件对象仓库”。这个来自工业史的词，正好严丝合缝地落进软件供应链；更妙的是，它还有另一层双关：在传统铸铁场里，铁水先流入一条主槽，再分流到两侧的小槽里，冷却成一块块铁锭。那些铁锭叫 Pig，承载和分配铁水的主槽叫 Sow。从上方看，一条大槽带着一排小铁锭，正像一头母猪带着一窝小猪。

Pig iron 与母猪、小猪命名的历史渊源

为什么要再造一个仓库工具？

最直接的诱因来自 Pigsty 的离线安装。Pigsty 会先把安装所需的 RPM / DEB 下载到本地，再生成一个离线软件仓库。过去，RPM 系统依赖 createrepo_c，Debian / Ubuntu 依赖 dpkg-dev。真正要生成的不过是几份 XML、Packages 与压缩索引，准备工具链却要装进几百 MB 的依赖。

这在 Linux 上已经够啰嗦；到了 macOS 上更难看。你得启动不同的 Linux 容器，挂载同一份目录，分别跑 RPM 与 DEB 工具，再把结果搬回来。为了生成几 MB 元数据，先请来几百 MB 工具链和一支容器车队，怎么看都不优雅。

Pigsty 使用 SOW 替换 RPM 与 DEB 仓库工具链

到了 Pigsty 4.5，我把这套冗余清掉了。SOW 是一个几 MB 级的自包含二进制，在 Linux 和 macOS 上都能直接运行，同时理解 RPM / DEB 包格式与 APT / DNF 仓库规范。它没有守护进程，也不需要额外的语言运行时。

但“少装几个工具”只是表面问题。真正让我决定把 SOW 做下去的，是仓库规模扩大后暴露出的四个痛点。

第一，硬链接救不了对象存储

同一个 noarch RPM 可能同时出现在多个架构仓库里，同一份包也可能进入 beta、latest、stable 等多个视图。放在本地磁盘上，可以用硬链接让许多路径共用一份 inode；上传到 Cloudflare R2、OSS 或其他对象存储后，每个 object key 都会变成一份实打实的存储与上传成本。文件内容相同，不代表云端知道它们应该共享所有权。

第二，十万个文件让“比较一下”都变得昂贵

仓库更新通常只变动几十个包，但传统同步工具为了确认这一点，往往要把十几万个文件重新遍历、比较、校验一遍。全量检查一次花十几分钟并不稀奇；真正的数据传输可能只有几秒，时间全耗在“什么都没变”的证明上。

传统仓库同步需要花费大量时间遍历和比较文件

第三，在线仓库不应该露出半成品

一个 RPM 仓库不只是 .rpm 文件；客户端先读 repomd.xml，再沿着它找到 primary、filelists 和包体。APT 同理：Release、InRelease、Packages 与 by-hash 文件之间有严格引用关系。

如果更新顺序错了，客户端就可能先看到新指针，却找不到新指针引用的对象。对维护者来说只是几秒钟的上传窗口，对全球随机到访的用户来说，就是一次无法复现的 404、校验失败或安装中断。

SOW 的自包含二进制与增量发布能力

第四，目录没有版本，发行版需要版本

最核心的问题是：当老冯想进一步改进仓库、提供 Channel 能力时，之前的维护模型就会遇到这些问题：如何同时维护 beta、latest、stable 仓库？如何每月保存一个快照？如何回答“上周三到底加了哪些包”？如何安全回退？哪些旧对象已经没有任何快照引用，可以删除？

这些需求单独看都能用脚本拼出来；组合到一起，脚本就会长成一套没有事务、没有模式、没有审计的影子数据库。市面上当然有 createrepo_c、dpkg-scanpackages、reprepro、aptly，也有通用同步与对象存储工具。但我没有找到一个足够轻、同时把 RPM 与 DEB、单份包池、不可变快照、原子发布和增量交付放进同一套清晰模型里的开源工具。

幸运的是，自己做工具的成本从来没有像现在这样低过。

两种复杂度，两种模式

SOW 并不假定所有仓库都需要同样的治理强度。它把问题切成 Plain 与 Managed 两层：小问题保持小，大问题才使用完整状态机。

Plain：包目录就是事实

Plain 模式只有一个核心命令：

sow create /srv/repo

# Pigsty 离线仓库兼容模式
sow create /srv/repo --pigsty

目录里的 RPM / DEB 是唯一权威事实，repodata/、Packages 与 Packages.gz 都是可以随时丢弃重建的投影。SOW 会并行扫描顶层软件包，每个包在默认路径上只打开一次，在同一遍里完成 SHA-256、解析和渲染所需事实的提取，再生成两种仓库元数据。

生成结果先进入同文件系统的私有 staging 区，经过 SOW 自己的解析器校验后再替换公开文件。最后，它只重新比较文件集合与 stat 快照，确认构建期间没有包被新增、删除或替换；不会为了“再放心一次”把所有大包重新哈希一遍。

SOW Plain 平面仓库文档

Plain 不保存操作日志，也不做沉重的事务恢复。进程中断了，就重新执行同一条 sow create：包目录还在，索引只是派生状态，重建比恢复更便宜。

--pigsty 模式还会最后写入 repo_complete 完成标记。只要这个标记不存在，消费方就知道这份仓库还没准备好。这是一个很小、但非常实用的提交协议。

这套模式解决了 Pigsty 最初的痛点：用一个小二进制替代两套工具链与多个容器，快速得到能被真实 APT / DNF / YUM 客户端消费的仓库。

Managed：仓库不是目录，而是状态机

长期运行的仓库不能只看“目录里现在有什么”。它还必须知道你想要什么、上一次成功发布了什么，以及两者为什么不同。

SOW 的 Managed 模型分成四层：

SOW Managed 模式的四层结构

Workspace 是配置与发现边界；Repository 是所有权边界；Dist 是一个具名的 RPM 或 DEB 成员集合；Architecture View 只是渲染结果，不再拥有一份软件包。这里最重要的不变式是：在一个 Repository 内，每个软件包只有一份正典包体，不留副本。

repo/pool/...                              唯一包体
repo/dists/el9/x86_64/repodata/...         RPM 元数据视图
repo/dists/trixie/main/binary-amd64/...    APT 元数据视图

noarch RPM 或 all DEB 可以被投影进多个架构索引，却不会复制包体。beta 与 stable 也可以引用同一个软件包对象，而不制造第二份云端 object key。而且更妙的是，APT 和 DNF 仓库可以在同一套目录体系下管理。

SOW 的包池与 RPM、APT 元数据视图

“只存一份”的边界必须说准确：它是一个 Repository 或一个发布前缀，不是整个 Workspace、bucket 或全世界。不同 Repository 之间不做隐式去重，因为去重不能以破坏所有权为代价。删掉一个仓库，绝不能顺手删掉另一个仓库依赖的共享对象。

Desired、Built 与 Generation

Managed 模式把仓库状态拆成三个概念：

状态 含义
Desired 配置、加包、删包操作想要得到的成员集合
Built 上一次完整渲染、校验并提交成功的公共视图
Generation 对某个 Built 状态的不可变清单

这个区分看似学院派，实际上专门解决失败场景。

假设你一次加入五千个包，Desired 已经改变，但构建在中途被 SIGKILL。没有这层区分，系统只能面对一棵“不知道改到哪儿”的目录；有了它，SOW 可以诚实地说：意图已经更新，上一个 Built Generation 仍完整对外服务，新操作处于待恢复状态。

Generation 不是把整个仓库再复制一遍。它保存的是不可变 manifest、元数据与包体引用集合；多个快照可以引用同一份 Pool 对象。两代 Generation 之间的精确差异就是 Changeset：新增哪些包体、替换哪些元数据、切换哪些指针、哪些旧对象在保留期后可以删除，一目了然。

sow status  -r pigsty
sow changes -r pigsty
sow log     -r pigsty

所以增量同步不再从“重新扫描十万个文件”开始，而是从“比较两个已知 Generation”开始。

SOW 的 Plain 与 Managed 能力矩阵

原子切换的秘密：最后才动指针

软件仓库没有一个跨文件、跨对象的全局事务。SOW 的做法不是假装它存在，而是把发布顺序设计成可证明的协议：

payload  →  metadata  →  pointer  →  delete
 包体          元数据          指针          删除旧对象

先放入不可变包体；再写以 checksum 命名的元数据与 by-hash 索引；全部就位之后，最后才切换 repomd.xml、Release / InRelease 这些客户端入口。只有旧指针已经不再引用旧文件，并且保留期与证据门禁都满足，旧对象才允许删除。

因此，客户端沿着一个生效指针往下走时，它引用的内容一定已经存在。对单个协议视图来说，读者看到的要么是完整旧代，要么是完整新代，不会看到一棵被撕裂的树。

在本地 POSIX 文件系统上，这套过程依赖同盘 staging、fsync、原子 rename、稳定路径锁和持久操作日志。每条 Managed 写命令都会先检查并恢复上一次未完成操作，再开始自己的工作。恢复只根据已经落盘的证据判断该回滚还是前滚；证据矛盾时宁可中止并保持关闭状态，也不提供一个可能猜错的 repair --force。

对象存储不支持跨多个 Key 的原子提交，SOW 就先持久化 commit intent，再按确定顺序前滚协议指针，并为每个 target 单独保存 Applied Checkpoint。当前文件系统与 R2 发布各有自己的证据，前者成功绝不会被误认为后者也成功。R2 端如果缺少足够安全的条件删除证据，垃圾回收就只报告候选，不冒险远程删对象。

这也是 SOW 与一条 rclone sync 命令最本质的区别：传输文件不难，困难的是知道哪些能传、何时算提交、失败后往哪边恢复，以及哪些真的可以删。

十万个对象，性能不能靠信仰

SOW 0.3 的主要工作，不是继续堆功能，而是把已经成立的模型推到真实仓库规模。

Plain 路径现在每个包只做一遍内容读取、哈希与解析，并通过 --jobs 使用有界并发。输入相同时，生成的元数据逐字节一致；无须更新时返回 no-op，也不会为了“更新一下时间戳”替换公开 inode。

Managed 路径则把解析后的“软件包事实”按不可变 SHA-256 缓存在 SQLite 中。新包入库时完整认证并解析一次；后续构建批量载入事实，在内存里完成成员投影。暖构建仍会遍历公开命名空间，但对未变化的 Pool 文件只检查 device、inode、size、mtime、ctime 指纹，不再把所有包体重新读一遍。指纹漂移时才回退到一次权威 SHA-256，并自动修复缓存；需要全量密码学审计时，显式运行 sow check。

这类优化的价值，必须落在数字上。

在项目基准中，一个包含 5,000 个对象的 Dist，成员展开从约 4.1 秒降到 33 毫秒；50,000 个对象原先十分钟仍跑不完，现在约 300 毫秒完成。载荷提升也改成了有界单写入者组提交，每批最多 512 个对象或 1 GiB，既减少 fsync 风暴，也保证文件描述符和恢复状态不会随着仓库规模无限增长。

这些数字不是为了做一张跑分海报。它们只是说明：当仓库真的有十万个制品时，“状态模型正确”只是及格线，“日常小改动仍然足够便宜”才决定工具能不能被长期使用。

推倒第一版，再从最小闭环长回来

SOW 的开发时间不短，中间还经历过一次相当彻底的推倒重来。

最初那一版后来以 v0.1.0 留档。它野心很大：用 Git ref 管理仓库视图，用 SHA-256 CAS 保存制品，同时处理上游同步、多目标云发布、校验、修复、垃圾回收、Cloudflare Worker、CDN purge、边缘验证和生产迁移。

这些功能很多都已经做出来了，部分路径也通过了真实 APT / DNF 客户端与非生产 R2 环境的验收。但它的问题同样明显：仓库模型、云厂商、CDN、边缘运行时与迁移流程耦合得太紧。一项功能的正确性，要靠另外半套系统才能证明；任何小改动都会拖着一长串验收矩阵一起移动。

我最后决定把它封存。

推倒的不是目标，而是抵达目标的方式。一个基础设施工具最怕“什么都有一点，但没有哪一层能单独说清楚”。所以第二版先把最小闭环重新切出来：

  • P0 / Plain Create： 一个目录进去，一个可用仓库出来；
  • P1 / Managed Control Plane： Workspace、Repository、Dist、Membership、Build、Generation、Check、Changes 与 Operation Log；
  • 更复杂的同步、远端发布、CDN 与供应商控制面，逐项回到独立验收队列。

v0.2.0 建立了今天的 Plain + Managed 主体：单份包池、元数据视图、确定性构建、锁、日志、崩溃恢复、Generation、文件系统与 R2 发布。

v0.3.0 没有再造一层概念，而是集中清理旧 V1 运行时，收敛云端传输边界，并解决 Plain 与 Managed 在大仓库上的重复读取、逐对象查询、载荷提交和可观察性问题。当前正式二进制只依赖新的 V2 核心，旧实现留在 Git 历史与 v0.1.0 / v0.2.0 标签里，作为经验，而不是第二套事实来源。

这条路看上去比“一次憋个大的”慢，其实更快。每一层都有独立契约、失败语义和真实客户端验收，下一层建立在已经站稳的地基上，而不是建立在一份越来越难读的愿望清单上。

SOW 命令索引

接下来的 Roadmap

SOW 0.3 已经能创建仓库、管理成员与快照、计算变更集，并发布到文件系统和 R2；但它离我脑子里完整的软件制品控制面还有距离。

接下来主要有四条线：

  1. 上游仓库同步。 直接消费 APT / YUM 上游索引，验证签名与摘要，只拉取缺失制品，并把镜像结果纳入同一套 Package Object、Membership 与 Generation 模型。
  2. 更完整的增量交付。 现在 changes 与 target checkpoint 已经能描述、复用并只发布差异；下一步是扩展对象存储与同步供应商覆盖，把大规模远端 inventory、断点恢复、条件写入和安全删除证据做成稳定闭环。
  3. CDN 与缓存控制。 CDN purge 不是“调一下 API”这么简单，还要绑定精确 Generation、缓存 TTL、回执与失败恢复。V1 已经证明这条路可行，但它会以独立、可验收的模块重新进入，而不是重新和仓库核心焊死。
  4. 版本与保留策略。 beta、latest、stable、月度快照这些需求，现在已经可以用 Dist、Generation、retain 与 target 组合表达；后续还会补上更高层的策略编排，让常见发布节奏不必由外部脚本手工串联。

这些能力在第一版里大多已经有过实现。我不打算把旧代码整块搬回来，而会像 0.2、0.3 一样，一次只拿回一个边界清楚、能独立验收的能力。

不再憋大招，持续交付小而完整的闭环。

猪猪家族还在继续长大

SOW 是 Pigsty “猪圈宇宙”的一部分，而且这个命名体系已经越来越离谱，也越来越完整：

  • Pigsty：猪圈，负责安装和管理 PostgreSQL 生态；
  • SOW：母猪，负责组织、构建和发布软件仓库；
  • Boar：公猪，开发中的 PIGSTY GUI 管控平台；
  • Silo：筒仓，负责 S3 兼容对象存储；
  • Oink：猪叫，负责文档与网站框架；
  • Snort：猪拱，负责收集日志与监控指标。

这当然首先是一套命名梗，但它背后也慢慢长出了一条完整链路：SOW 整理制品，Silo 存放制品，Pigsty 把它们安装成系统，Snort 观察系统，Oink 把一切讲清楚。而 SOW 填上的，正是过去最容易被忽视的那一段。

软件仓库看起来只是一个能被 Nginx 托管的目录，但当它承载十万个对象、多个操作系统、多个架构与无数用户之后，它其实是一台没有界面的数据库：有对象、有关系、有版本、有事务、有日志、有垃圾回收，还有绝不能写错的提交指针。

SOW 做的事情，就是把这些隐含规则变成显式模型，把一堆“祖传脚本应该没问题”的侥幸，变成可以检查、恢复和审计的工程契约。如果你只想建一个离线仓库，可以从一条命令开始：

sow create /srv/repo

如果你也在维护一套长期运行的软件发行版，欢迎访问 SOW 项目主页，或直接阅读 使用文档，看看它更深的一面。

SOW 采用 Apache-2.0 许可证。当前 v0.3.0 提供 Linux / macOS 的 amd64、arm64 归档，以及 Linux RPM / DEB 安装包；可以从 下载页获取，也可以直接查看 源代码。

十万个包并不可怕。可怕的是，它们还只是十万个文件。

4 - Pigsty v4.4：从集成到发行

原文发布于 VONNG。

GitHub Release | 发布注记

Pigsty v4.4 正式发布。表面上看，这是一个例行维护版本：PostgreSQL 18.4、531 个扩展、PG19 beta，以及十四组通过验收的离线安装制品。真正值得讲的变化，则集中在软件仓库与命令行工具上。

Pig 1.5 完成了 PostgreSQL 日常运维命令行的重构。克隆数据库、分叉实例、执行时间点恢复——这些原来散落在 Ansible、Shell、Patroni 与 pgBackRest 里的动作，现在有了一套统一的命令行接口。

与此同时，我们重新梳理了仓库中的 PG 内核分支：新增 Babelfish PG18，补齐 pgEdge PG15～18、AgensGraph PG17 与 OrioleDB PG16～18，并为 PolarDB、IvorySQL 提供自行构建的软件包。

这一版还将 Supabase 自建模板跟进到上游最新版本，并解决了一批兼容问题；同时新增自托管云相册 Immich、堡垒机 JumpServer 与个人财务管理工具 Maybe 的一键部署模板。

Pig 1.5：统一运维入口

pig 最早只是 PostgreSQL 扩展包管理器，后来逐步承担 Pigsty 安装、软件仓库与 PostgreSQL 管理工作。到了 1.5，它已经不只是“能执行很多命令”，而是开始形成一套清晰的 PostgreSQL 操作界面。

命令 边界 典型用途
pig pg 本地 PostgreSQL 原语 启停、状态、连接、维护、数据库克隆与本地 PGDATA 分叉
pig pt Patroni 集群操作 重启、重建副本、切主、故障转移、配置与日志
pig pb pgBackRest 低层原语 备份、仓库、备份集、清理与底层 restore
pig pitr 恢复编排 协调 Patroni、PostgreSQL 与 pgBackRest 完成 PITR

这一轮最重要的变化不是命令数量，而是 职责边界。过去，这些操作主要靠 DBA 记住 SOP 与命令别名：什么时候调用什么工具，下一步做什么，会有什么副作用。现在，这些经验被直接写进命令，高风险操作统一沿着同一条链路推进：

state → plan → precheck → execute → verify → result → next_actions

各阶段的结果与帮助信息既可以输出为人类可读的文本，也可以输出成便于机器和 Agent 处理的 JSON／YAML。通过这套 Agent-Native 接口，DBA、脚本与 Agent 可以共用同一个入口，获得所需上下文、风险判断与下一步提示。

抽象的话说多了没意思，下面来看几个具体例子。

克隆：给单个数据库开一个分支

新增命令 pig pg clone 可以快速克隆单个数据库。

pig pg clone meta meta_dev --plan   # 先查看计划
pig pg clone meta meta_dev -y       # 创建数据库副本

这里有一个经常被忽略的边界：CREATE DATABASE ... TEMPLATE 会终止源库现有会话。换句话说，数据库克隆虽然快，却不是毫无影响。--plan 的意义，就是在真正动手前把这些副作用摊开给你看。

对于开发测试、数据分析、模型实验和 Agent 反事实推演来说，这种廉价分支非常实用。生产库保持不动，实验在副本里进行；做坏了直接删除，再开一个新的分支即可。详细用法可以参考《瞬间克隆 PostgreSQL 数据库，无需黑魔法》。

分叉：给整个实例做一个沙箱

数据库克隆解决的是单库副本，而 pig pg fork 处理的是整个 PostgreSQL 实例，也就是 PGDATA 级别的物理分叉。

pig pg fork init dev --start        # 分叉为 /pg/data-dev 并启动
pig pg fork list                    # 查看本地分叉实例
pig pg fork stop dev                # 停止分叉实例

Pig 会为受管分叉写入元数据，并提供 list、start、stop、rm 等生命周期命令。在支持 CoW 的 XFS 上，分叉初始几乎不额外占用空间，后续只有新增或改写的数据块才会消耗容量。Pig 还会自动分配可用端口，让分叉实例与原实例并存。

它特别适合两类场景：一是在大规模、难回滚的操作前，留下一份低成本的本地分支；二是在事故恢复时拉起旁路实例，快速验证 PITR 目标与数据状态。

回到过去：恢复首先是一份计划

数据库恢复最危险的地方，从来不是缺一条命令，而是步骤太多、边界太模糊，而且人在事故压力下最容易犯错。

Pig 1.5 把低层恢复与高层编排明确拆开：

  • pig pb restore 是 pgBackRest 的底层恢复原语，只负责文件与恢复目标。
  • pig pitr 是面向 Pigsty／Patroni 环境的恢复编排入口，负责协调 Patroni、PostgreSQL 与 pgBackRest。
pig pitr -t "2026-07-10 12:00:00+08" --plan
pig pitr -t "2026-07-10 12:00:00+08" -y

恢复命令现在必须显式指定一个目标：最新状态、备份一致点、时间、LSN、事务 ID 或命名恢复点，不能把“没写目标”解释成某个危险默认值。结构化输出也不再充当确认；自动化执行破坏性操作时，必须明确传入 -y/--yes。

对于托管数据目录，pig pitr 会检查环境、停止 Patroni 与 PostgreSQL、执行 pgBackRest 恢复、按策略启动 PostgreSQL 并验证恢复状态，最后给出后续动作。恢复完成后，再由人或上层自动化确认数据状态，重新接入 Patroni 并切换流量。

核心不是“一键恢复”，而是把事故现场最容易出错的 SOP 固化下来：先看计划，再执行，最后验证。

PostgreSQL 18.4、19 beta 与 531 个扩展

运维接口是这一版的主线，但发行版的基本盘也没有停下。

Pigsty v4.4 将 PostgreSQL 18.4 设为生产默认版本，同时增加一个精简的 PostgreSQL 19 beta 评估模板。PG19 beta1 尚未达到生产状态，v4.4 发布时使用的 pgBackRest 2.58 也无法识别它的控制文件格式，因此这套模板只用于尝鲜评估。

Pigsty 的 PG 扩展目录则从 v4.3 的 510 增加到 531。按方向来看，pg_ducklake 把 DuckDB、Parquet 与湖仓能力带进 PostgreSQL；pg_stat_plans 与 pg_stat_backtrace 补强查询计划和进程调用栈观测；升级后的 pgmnemo 与新加入的 psql_bm25s，则分别面向 Agent 记忆和 BM25 全文检索。

与此同时，OrioleDB 扩展到 PG16～18 并将 PG18 作为默认，pgEdge 覆盖 PG15～18，Babelfish 覆盖 PG17～18，IvorySQL 进入 5.x，AgensGraph 更新到 PG17，Cloudberry 与 PolarDB 也完成了路径和软件包重整。

这些细节看起来杂，但这就是发行版的工作：让 PostgreSQL 主线、扩展生态与内核分支同时保持可用、可安装、可升级。

应用更新：Immich、JumpServer、Maybe 与 Supabase

这一版新增了 Immich、JumpServer 与 Maybe 三个应用模板，并更新了 Supabase。

Immich：把照片库交给真正的 PostgreSQL

Immich 是一套开源的自托管照片与视频管理服务，可以把它理解成自己家里的 Google Photos 或 iCloud Photos。它有移动端自动备份、相册、地图、人脸识别和语义搜索，后端同时用到 PostgreSQL、向量检索、缓存和机器学习服务。其中，智能搜索与人脸识别需要 VectorChord 扩展 vchord，Pigsty 可以直接提供。

Immich 目前仍将照片原件存放在文件目录中，不直接支持对象存储。如果需要把存储池独立出来，可以用 JuiceFS 将 MinIO 或 S3 挂载为本地文件系统。

JumpServer：把堡垒机也接进来

堡垒机是许多企业的刚需，JumpServer 则是常见的开源选择之一。JumpServer 4.x 使用 PostgreSQL 保存核心元数据，因此 Pigsty 顺手补上了相应的部署模板。

Maybe 也在这一版加入应用目录，它是一套个人财务与资产管理工具。三个模板方向不同，但思路一致：应用可以跑在容器里，数据不必跟着容器一起漂。

Supabase：更新不只是换镜像

Supabase 更新很快，也是 Pigsty 应用模板里组件最多、兼容性最容易出问题的一套。v4.4 把 Studio、Auth、PostgREST、Realtime、Storage、Analytics、Edge Runtime 等组件跟进到 2026 年 7 月的上游版本，并做了一轮配套调整。

这次我们把 Analytics 放进独立的 _supabase 数据库与 _analytics 模式，避免日志分析表和业务对象混在一起；为 Studio 补齐 pg_stat_statements 兼容视图，让查询性能页面能够正常工作；同时适配新的 Publishable Key 与 Secret Key，调整 Kong 路由、Realtime 敏感接口、S3 兼容接口和服务健康检查。

Supabase 这种应用，单个容器能启动没有意义，十几个组件能一起升级、一起工作才算完成。v4.4 修的就是这些不起眼、但会直接决定模板能不能用的问题。

VIP 网卡终于不用手填

另一个我很喜欢的改动，是 VIP 网卡自动识别。

过去 vip_interface 与 pg_vip_interface 默认写成 eth0。如果要启用 NODE／PG VIP，需要用户手工配置网卡名称，比较繁琐。

v4.4 添加了自动检测，把默认值改成了 auto：Pigsty 会根据清单里的节点 IP，反查它实际所在的网卡，再把结果交给 Keepalived 或 VIP Manager。手工指定仍然保留，但大多数用户再也不用先登录机器跑一遍 ip addr，然后回来填写参数。这个功能只有几行配置，却能直接避免一类部署失败。发行版的体验，往往就是由这种小事决定的。

备份默认改用 Zstandard

此前，pgBackRest 默认使用 LZ4 压缩。LZ4 速度快、吞吐高，依然适合 wal_compression；但备份仓库更看重压缩比，因此 v4.4 将 pgBackRest 的默认算法改为 Zstandard。实际测试中，只增加少量解压开销，就能让压缩比从 2.x 提升到 3.x，额外节省约三分之一的备份空间，这笔买卖很划算。

这次切换也暴露出一个问题：IvorySQL 官方内核没有添加 --with-lz4、--with-zstd 等构建参数，无法使用 LZ4 与 Zstandard。这也直接推动了下一项改造：统一构建 PG 内核分支。

统一构建 PG 内核分支

Pigsty 支持了许多不同风味的 PG 内核，其中 PolarDB 与 IvorySQL 此前直接使用上游构建的软件包。IvorySQL 的官方构建缺少几个关键编译参数，PolarDB 则缺少 Ubuntu 26.04 软件包。这两个问题我都提交给了上游。目前，PolarDB #650 的 Ubuntu 26.04 构建支持已经合入，IvorySQL #1377 也确认会在下一个版本补齐相关选项；上游成品包则还要再等一次发布。

老冯可等不了那么久。既然已经自行构建了这么多内核分支，也不差这两个，正好借此一劳永逸地统一 FHS 布局。以 PolarDB 为例，上游包名是 polardb-for-postgresql，默认安装在 /u01/polardb_pg_17；Pigsty 的包叫 polardb-17，安装在 /usr/polar-17。默认端口、运行时搜索路径、开发头文件与扩展构建工具，也一并整理到位。

为了让 PolarDB 的构建可以稳定复现，我们还把它依赖的 PFSD 开发库单独打成 polarstore 软件包。开源版同时移除了 PolarDB Oracle 兼容内核及其专用监控配置，不再将这条闭源兼容路径列为内置支持。

做这件事也是在为下一步提前准备。目前，Pigsty 的 500 多个扩展主要面向原生 PostgreSQL 内核。接下来，我希望把“5 个原生 PG 大版本 × 16 组 Linux 平台（含仅在线支持的 EL8 双架构）”的构建矩阵，进一步拓展到十余种 PG 内核分支，让它们也能接入完整的 PG 扩展生态，而不是各自在 RPM 或 Docker 镜像里零散捆绑几个扩展。这才是 Meta Distribution 该有的样子。

写在最后与未来展望

做发行版，大部分工作都不适合拿来做漂亮的演示：改包名、理目录、补依赖、修构建脚本，再把十四组部署测试全部跑一遍。可一旦这些事情没人做，“开箱即用”就只是一句广告。

把上游的多样性收进同一套工程约定，把最后一公里的麻烦留给发行版。 这就是 Pigsty v4.4。

Pigsty 4.4 完工之后，我们已经开始筹备 5.0 版本。在 5.0 版本之前，可能会有一个 4.5 过渡版本。

5.0 版本将随着对今年九月份 PG19 的完整支持一同发布。Pigsty 19 引入了非常多强大的新功能特性。为了充分利用好这些功能特性，Pigsty 5.0 将进行针对性的调整。一些准备工作我们已经完成了。比如这次的 pg_exporter 更新到了 1.3.0，提供了对 PG-19 新监控指标的支持；一些 Patroni 参数模板也都已经为 PG-19 的修改预留好了位置和占位值。

Pigsty 5.0 将会有一个专门的企业级软件制品仓库，采用和开源版有所不同的策略：采用更为保守的更新策略，会保留所有的历史版本软件包、Debug 包、修复包，并定期提供快照。为了实现这个目标，我们还专门做了一个仓库管理工具，用来统一 APT 和 DNF 两侧的仓库管理。我们给它起名为 sow（母猪的意思），正好和包管理器 Pig（小猪）相互对应。

此外，我们还在进行一些有趣的尝试。比如说用 Go 重写 Patroni，至少第一阶段我们先把 Patroni 的客户端工具给重写了，从而提供更好的管理体验。这个项目我们给它起名叫 Boar（公猪的意思），与 sow（母猪）和小猪正好凑成一家子，在 Pigsty 里面相映成趣。

GitHub Release | 发布注记

v4.4.0 发布注记

Pigsty v4.4.0 是一个维护版本，重点涵盖 PostgreSQL 18.4、PostgreSQL 19 beta 试用支持、531 个扩展、内核变体更新与更广泛的平台覆盖。

发布于 2026-07-10。参见 GitHub 发布页面 与 v4.3.0 以来的完整变更。

亮点特性

  • PostgreSQL 18.4 / 19 beta：PostgreSQL 18.4 现已成为生产默认版本，并提供精简的 PostgreSQL 19 beta 模板用于评估。
  • 531 个扩展与内核更新：扩展目录新增 21 个扩展，并在支持的平台矩阵上更新主要 PostgreSQL 内核变体。
  • Pig 1.5.1 与更安全的运维：新增克隆、分叉与 PITR 工作流，并引入 VIP 网卡自动发现、pgBackRest Zstandard 压缩和独立的 Patroni 日志采集。
  • 安全、应用与工具：加固敏感配置处理与仓库安全自动化，增加应用模板，重新设计基础设施门户，并提供可选的 Codex 支持。
  • 平台验证：七个操作系统基线在 x86_64 与 aarch64 上的 14 组离线部署测试全部通过。
  • 离线制品：社区版在 GitHub 公开发布 Debian 13、EL 10、Ubuntu 24.04 的双架构离线包，共 6 个；其余已验证基线的预制离线包通过商业版提供。

兼容性变化

  • 新生成的 pgBackRest 配置改用 compress-type=zst；重新渲染前请保留有意设置的本地自定义项。#744
  • Patroni 日志改用 /pg/log/patroni 与 job=patroni；使用旧 syslog 选择器的自定义日志查询和告警规则需要同步更新。
  • VIP 接口默认值改为 auto，dnsmasq 记录迁移到 /etc/dnsmasq.d/pigsty，同时 Pigsty 开始管理 /etc/default/haproxy；非标准网络环境应保留显式覆盖配置。
  • etcd 默认后端配额从 16 GiB 降至 8 GiB；应用新配置前请先检查现有后端用量。
  • pig 自动化脚本执行破坏性命令时必须传入 -y/--yes；pig pb restore 与 pig pitr 均要求指定且仅指定一个恢复目标。参见 pig v1.5 发布说明。
  • Supabase Analytics 改用 _supabase 数据库与 _analytics 模式；现有部署切换新版栈前应先创建这些对象。

安全与运维

  • pg-pitr 包装脚本加入更安全的恢复目标选择、时间线与 dry-run 支持，并加强对不安全恢复目标的检查。
  • Ansible 输出不再显示应用敏感配置，生成的 .env 文件权限设为 0600，Grafana 也不再打印管理员密码。
  • dbsu sudo 策略增加受控的日志查看权限；仓库同时加入安全策略、CodeQL、Dependabot、锁定 GitHub Actions 依赖版本与发布签名自动化。

应用与工具

  • 新增 Immich、Maybe 与 JumpServer 模板，并更新 Supabase、Dify、InsForge、Registry、Jupyter、Kong、Odoo、Teable、Mattermost 及相关启动脚本。
  • 重新设计中英双语基础设施门户；实验性 VIBE 模块支持按需安装 Codex CLI，Claude Code 仍是其默认托管编码代理。
  • 移除旧版 FerretDB Compose 模板；FERRET 模块仍然可用。

问题修复

  • 修复 EL10 PostgreSQL/libpq 软件包提供者冲突、EPEL 路径处理和 PGDG 小版本仓库规则。#752
  • bootstrap 过程会复用已有 /www 目录，并修复 Redis Sentinel HA 密码渲染问题。#753 #748
  • 修正 pg_http、pg_gzip、apache-age 与 odbc_fdw 的 RPM 包名和软件包分组。#750
  • 避免 Debian 与 Ubuntu 安装软件包时意外启动服务，并改进 EL9 aarch64 Patroni 包处理。
  • 修复 VirtualBox 私有网络路由与默认网卡选择。
  • 修复 shell 兼容性与 Vector 日志生命周期问题，以及 PG19 io_workers、Teable HBA 和若干应用运行时默认值。

PostgreSQL 与扩展软件包变更

本版本新增 21 个扩展，更新 PostgreSQL 18.4 软件包图谱，引入 PostgreSQL 19 beta 模板，并刷新主要内核变体。以下版本以最终仓库元数据为准；纳入离线包的版本同时与 v4.4.0 制品核对。PG 大版本范围表示扩展目录与软件仓库的覆盖范围。

PostgreSQL RPM 变更 · PostgreSQL DEB 变更 · 基础设施软件包变更

包名 旧版本 新版本 备注
polardb-17 17.9.1.0 17.10.1.0 PG 17；新增 RPM 包
agensgraph-17 2.16.0 2.17.0 PG 17.10
openhalodb-14 1.0-beta 1.0-2 OpenHaloDB
babelfish-17 5.4.0 5.4.0 PG 17.7；重新构建
babelfish-18 - 6.0.0 PG 18.3
pgedge 17.9 / 18.3 15.18 / 16.14 / 17.10 / 18.4 新增 PG 15/16；更新 PG 17/18；Spock 5.0.10
ivorysql-18 5.0 5.4 PG 18；新增 RPM 包
cloudberry 2.1.0-1 2.1.0-2 / 2.1.0-3 DEB/RPM 重新构建；RPM 路径为 /usr/cloudberry
cloudberry-backup 2.1.0-1 2.1.0-2 / 2.1.0-3 备份子包
cloudberry-pxf 2.1.0-1 2.1.0-2 / 2.1.0-3 PXF 子包
pg_ducklake - 1.0.0 PG 14-18
psql_bm25s - 0.4.13 BM25 检索；PG 17-18
mongo_fdw 5.5.3 5.5.3 新增 DEB 打包；已有 PGDG RPM；PG 14-18
multicorn 3.2 3.2 新增 DEB 打包；已有 PGDG RPM；PG 14-18
pg_orca - 1.0.0 仅 PG 18
pg_sorted_heap - 0.14.0 PG 16-18
pg_stl - 1.0.0 PG 16-18
fsm_core - 1.1.0 PG 15-18
pg_projection - 1.0.0 PG 14-18
graph - 0.1.7 PG 14-18
jsonschema - 0.1.9 PG 14-18
pg_durable - 0.2.2 PG 14-18
pg_stat_log - 0.1 仅 PG 18
pg_stat_plans - 2.1.0 PG 16-18
pg_task 1.0.0 2.1.29 PG 14-18；修复 pcre2grep 依赖
pg_stat_backtrace - 1.0.0 PG 14-18；依赖 libunwind
pg_mockable - 1.1.0 PG 14-18
db2fce - 0.0.17 PG 14-18
pg_uuid_v8 - 1.0.0 PG 14-18
pg_extra_time 2.0.0 2.1.0 PG 14-18
pg_pinyin 0.0.2 0.0.4 PG 14-18
passwordpolicy - 2.0.5 PG 14-18
pgdisablelogerror - 1.0 PG 14-18
plpgsql_wrap - 1.0 PG 14-18
timescaledb 2.26.4 2.28.2 PG 15-18
documentdb 0.110 0.113 PG 15-18
citus 14.0.0-4 14.1.0 PG 16-18
pgvector 0.8.2 0.8.4 PG 14-18
orioledb 1.7-beta15 1.8-beta16 面向 PG 16/17/18 构建
pg_search 0.23.1 0.24.0 PG 15-18
pg_textsearch 1.1.0 1.2.0 BM25 全文检索；PG 17-18
storage_engine 1.3.4 2.4.0 升级到 PGXN 2.x；PG 15-18
pg_clickhouse 0.2.0 0.3.2 PGXN 版本更新；ClickHouse 集成
provsql 1.2.3 1.10.0 PGXN 版本更新；PG 14-18
pgclone 4.0.0 4.3.2 PGXN 版本更新；PG 14-18
biscuit 2.2.2 2.4.0 DEB / 2.4.1 RPM PG 16-18
pgmnemo 0.7.2 0.12.1 PG 14-18
rdf_fdw 2.5.0 2.6.0 PG 14-18；libcurl 兼容性补丁
roaringbitmap 1.1.0 1.2.0-2 PG 14-18；修复 llvm-lto 打包
plpgsql_check 2.9.0 2.9.2 PG 14-18
timescaledb_toolkit 1.22.0 1.23.0 PG 15-18；pgrx 0.18.1
wrappers 0.6.0 0.6.1 PG 14-18；pgrx 0.18.1
pgrdf 0.5.0 0.6.4 PG 14-17；pgrx 0.18.1
pg_graphql 1.5.12 1.6.1 PG 14-18；pgrx 0.18.1
pg_anon 3.0.13 3.1.1 PG 14-18；pgrx 0.18.1
pg_kazsearch 2.0.0 2.2.0 PG 16-18；pgrx 0.18.1
pg_session_jwt 0.4.0 0.5.0 PG 14-18；pgrx 0.18.1
pg_tzf 0.2.4 0.3.0 PG 14-18；pgrx 0.18.1
pg_vectorize 0.26.1 0.26.2 PG 14-18；pgrx 0.18.1
pglinter 1.1.2 2.0.0 PG 14-18；pgrx 0.18.1
pgmqtt 0.1.0 0.3.0 PG 14-18；pgrx 0.18.1
etcd_fdw 0.0.0 0.0.1 PG 14-18；pgrx 0.18.1
pg_http 1.7.0 1.7.1 PG 14-18；RPM 包重命名为 pgsql_http_$v
pg_gzip 1.0.0 1.1.0 PG 14-18；RPM 包重命名为 pgsql_gzip_$v
age 1.7.0 1.7.0 PG 17-18；RPM 包重命名为 age_$v
pg_trickle 0.40.0 0.81.0 仅 PG 18
re2 0.1.1 0.4.0 PG 16-18
pg_background 1.9.2 2.0.2 DEB / 2.0 RPM PG 14-18
firebird_fdw 1.4.1 1.4.2 PG 14-18
pg_net 0.20.2 0.20.3 DEB 与 EL10 RPM 更新；EL8/9 RPM 保持为 0.9.2
pg_dirtyread 2.7 2.8 PG 14-18
pg_stat_ch 0.3.6 0.3.6 PG 16-18；重新构建
pggraph 0.1.5 0.1.7 PG 14-18
pgsql_tweaks 1.0.2 1.0.5 PG 14-18；PGDG RPM 同时包含 1.0.3
pgfincore 1.3.1 1.4.0 PG 14-18
toastinfo 1.5 1.7 PG 14-18
pg_ivm 1.14 1.15 DEB / 1.14 RPM PG 14-18
timeseries 0.2.0 0.2.1 PG 14-18

基础设施软件包变更

软件包 旧版本 新版本 备注
pig 1.4.1 1.5.1
pg_exporter 1.2.2 1.3.0
pgschema 1.9.0 1.12.0
pgstream 1.0.1 1.1.1
pg-hardstorage - 1.0.8
codex 0.125.0 0.144.1
claude 2.1.123 2.1.206
opencode 1.14.30 1.17.18
agentsview 0.26.0 0.37.5
genai-toolbox 1.1.0 1.6.0 软件包名为 mcp-toolbox
crush 0.64.0 0.84.0
code 1.118.1 1.128.0
code-server 4.117.0 4.127.0
victoria-metrics 1.142.0 1.147.0
victoria-metrics-cluster 1.142.0 1.147.0
vmutils 1.142.0 1.147.0
victoria-logs 1.50.0 1.51.0
vlagent 1.50.0 1.51.0
vlogscli 1.50.0 1.51.0
victoria-traces 0.8.2 0.9.4
prometheus 3.11.3 3.13.1
alertmanager 0.32.1 0.33.1
pushgateway 1.11.2 1.11.3
node_exporter 1.11.1 1.11.1 补齐 tarball 缓存；修正版本元数据
redis_exporter 1.82.0 1.86.0
mongodb_exporter 0.50.0 0.51.0
grafana 13.0.1 13.1.0
grafana-victorialogs-ds 0.26.3 0.29.0
grafana-victoriametrics-ds 0.24.0 0.25.2
vector 0.55.0 0.56.0
minio 20260417000000 20260618000000
seaweedfs 4.22 4.39
rustfs 1.0.0-b1 1.0.0-b8 预发布版本线
duckdb 1.5.2 1.5.4
kafka 4.2.0 4.3.1
etcd 3.6.10 3.6.13
restic 0.18.1 0.19.1
juicefs 1.3.1 1.4.0
tigerbeetle 0.17.2 0.17.9
tigerfs 0.6.0 0.7.0
caddy 2.11.2 2.11.4
cloudflared 2026.2.0 2026.7.1
headscale 0.28.0 0.29.2
v2ray 5.48.0 5.51.2
nodejs 24.15.0 24.18.0
golang 1.26.2 1.26.5
hugo 0.161.1 0.164.0
uv 0.11.8 0.11.28
rclone 1.73.5 1.74.4
asciinema 3.2.0 3.2.1
stalwart 0.16.2 0.16.12
maddy 0.9.3 0.9.5
dblab 0.38.0 0.43.0
npgsqlrest 3.12.0 3.20.0
postgrest 14.10 14.14
sabiql 1.11.1 1.14.0
pev2 1.21.0 1.22.0
rainfrog 0.3.18 0.3.19

验证与校验和

覆盖 EL9/10、Debian 12/13 与 Ubuntu 22/24/26，横跨 x86_64 和 aarch64 的 14 组离线部署测试全部完成，结果均为 failed=0、unreachable=0；EL8 仅继续支持在线安装。

以下 MD5 覆盖全部 14 个已验证制品，其中 6 个社区版制品上传至 GitHub，其余 8 个通过商业版交付；GitHub 会为已上传的社区版制品记录 SHA-256 摘要。

7de8b932412f1863fd9c033a7be355d7  pigsty-pkg-v4.4.0.d12.aarch64.tgz
2e5006a8d35eb1c087dc0ed11cf14d14  pigsty-pkg-v4.4.0.d12.x86_64.tgz
955308c00d3890f6e82a6a83bc624760  pigsty-pkg-v4.4.0.d13.aarch64.tgz
350f31c66de0aafff3bd91c2c9d740a0  pigsty-pkg-v4.4.0.d13.x86_64.tgz
0b4817a8edbab0bdf37ecee730fb0412  pigsty-pkg-v4.4.0.el10.aarch64.tgz
4584a61e4456749e68d86e4817cfe526  pigsty-pkg-v4.4.0.el10.x86_64.tgz
21621daf510a532829c36464d48f9198  pigsty-pkg-v4.4.0.el9.aarch64.tgz
504afd5030e2738a25e1b4c570d0e654  pigsty-pkg-v4.4.0.el9.x86_64.tgz
461c999424dee587ca33fe1a63df40d7  pigsty-pkg-v4.4.0.u22.aarch64.tgz
20ccc5ab8f9f4648b05bcd304f9fb5fc  pigsty-pkg-v4.4.0.u22.x86_64.tgz
d092c48ee55116ed5e2c99a3d909ccdd  pigsty-pkg-v4.4.0.u24.aarch64.tgz
24fa5399d8421305961fcaf91325b382  pigsty-pkg-v4.4.0.u24.x86_64.tgz
36f69b699d8b3041d35384970e157631  pigsty-pkg-v4.4.0.u26.aarch64.tgz
330047d117b20f04317dce506edd5d9a  pigsty-pkg-v4.4.0.u26.x86_64.tgz
3077203c0c656ec99abc32b227f6566b  pigsty-v4.4.0.tgz

5 - 瞬间克隆 PostgreSQL 数据库，无需黑魔法

原文发布于 VONNG。

老冯在半年前（2026-01-08）写过一篇文章《Git for Data：瞬间克隆 PG 数据库与实例》，介绍了 PostgreSQL 18 和 Pigsty v4.0 的一个新特性：瞬间克隆新数据库。利用文件系统 CoW 机制，以及 PG 18 的 file_copy_method = clone 新参数，可以在秒级克隆一个非常大的数据库，而且不占用额外的存储。

这玩意儿其实非常适合 AI Agent 使用。我在《Agent 需要什么样的数据库》里提到过：极低成本的数据库克隆对于反事实推演至关重要。所以当时趁着 4.0 上线的时候，给 Pigsty 里 PG 数据库 Provisioning 的地方加上了这个功能。

《Git for Data》旧文截图

今天看到阿里云数据库 发了篇文章说，他们在阿里云 RDS for PostgreSQL 上支持这个功能了。老冯看了直想笑：这个动作也太慢了。说起来其实这个功能不复杂，不需要改内核，只要在 PG 18 上启用一个参数，在创建数据库的时候加一个 STRATEGY 参数就可以实现。说是不复杂，但想做好，还是有几个边界条件要处理。

一些改进

之前要克隆数据库的时候，在 Pigsty 的 IaC 式操作里还是有些繁琐：首先你要定义一个数据库，把另一个数据库作为模板，然后执行数据库创建。

所以这次我趁着 pig v1.5 发布的机会，把数据库克隆做成了一个简单易用的命令：pig pg clone。简单地说，现在你有个数据库 meta，只要执行 pig pg clone meta，它就会自动生成一个克隆。

执行 pig pg clone

当然，你可以使用参数来定制行为，比如指定分支的名字；如果不指定，就按下划线后加数字的方式依次自动起名。

克隆结果列表

命令会自动检测是否启用并支持瞬间克隆（目前用 Pigsty + XFS 就满足前提）。如果满足，就执行瞬间克隆；不满足，就警告、等待确认，并执行普通克隆。-y 可以跳过确认。

只要底层用的是支持 CoW 的文件系统（比如 XFS），那么克隆一个数据库基本是常数时间耗时，通常几百毫秒，而且占用空间不会变大；只有后续真实写脏的数据块，才会真正开始占用新的空间。

Agent Native CLI

当然，这个命令行工具的特点不一样：这是专门给 DBA 和 DBA Agent 设计的。之前你也可以用 Ansible Playbook，或者 Pigsty 提供的 Shell 脚本 /pg/bin/pg-clone 来执行克隆，但很显然都没有直接使用 pig 命令行工具方便。

Pigsty 克隆副本文档

比如，在执行操作之前，你可以使用 --plan 打印计划。它会告诉你会做什么事情、有什么风险。你还可以用 -o json 和 -o yaml 让它输出 JSON 和 YAML 格式的结果。

pig pg clone 计划输出

顺便一提，命令本体和 Help 输出也都可以使用 text、JSON、YAML 格式，因此 Agent 用起来会非常方便。因为它可以很轻松地用探索式方式，拿到所需的结构化帮助信息。pig 里所有命令都有这个功能。

pig pg clone 结构化帮助

这个设计，我之前称之为 Agent Native CLI，之前写了篇文章介绍过。

实例级 Fork

当然，除了 Database Clone，还有一个新的相关功能也值得一提。我在《Git for Data：瞬间克隆 PG 数据库与实例》里也提到过，就是实例级瞬间克隆，我将其称作 “fork”。

执行 pig pg fork

这里，你只要执行 pig pg fork dev，就能从当前实例创建一个名为 dev 的实例，随机分配一个新的端口号。这个功能在误删处理的时候非常实用：你可以先临时分支一个实例（不占用额外存储），然后快速用增量 PITR 回滚验证；验证无误之后，再在主实例上执行。

顺便一提，现在使用 pig 做 PITR 也非常方便。比如下面，一条龙傻瓜式执行时间点恢复到特定时间点，把时间点恢复的门槛压到了地板。当然，你也可以使用 pig pgbackrest 精准控制每一个操作。

执行 pig pitr

这次 pig 命令行工具发布，新增了很多管理功能，包括对 PostgreSQL、Patroni、pgBackRest 组件的各种管理。现在它们都封装成上面 pg clone 与 pg fork 这类 Agent Native CLI，同时方便人类 DBA 与 AI Agent 使用。过几天会专门写篇文章详细介绍一下。

参考阅读

6 - 什么是 PostgreSQL 发行版？

原文发布于 VONNG。

经常有人问我：Pigsty 到底是什么？我通常回答：PostgreSQL 发行版。

通常下一个问题就是：那 “PostgreSQL 发行版” 又是什么？

这是个好问题。而要把它讲清楚，最好的切入点不是数据库，而是操作系统。

一、从 Linux 与操作系统发行版说起

说起 Distribution（发行版），绝大多数人第一反应都是 Linux 发行版 —— Red Hat、Debian、Ubuntu、SUSE、Arch…… 但问题是：既然已经有 Linux，为什么还需要 Linux 发行版？两者到底是什么关系？

答案很简单：Linus Torvalds 只写内核。

你把 Linux Kernel 编译出来，得到的不是一台能用的机器。你没有 Shell，没有 init 系统，没有 C 标准库，没有 coreutils，没有包管理器，没有网络工具，没有用户空间，也没有安全更新策略。内核负责调度硬件和提供系统调用，但它和 “一台能用的操作系统” 之间，隔着一整条工业化鸿沟。

这条鸿沟必须有人来填，而填的方式有无数种。用 glibc 还是 musl？用 systemd 还是 OpenRC？用 apt、dnf 还是 pacman？半年一版还是滚动更新？默认安全策略是什么？包怎么签名？漏洞怎么修？版本怎么维护？哪些服务默认启用 —— 这些选择叠在一起，才构成一个发行版。

linux-distro.webp

所以，发行版交付的不是内核。发行版交付的是一整套集成决策，以及对这套决策长期负责的信用。

没有人会说 Debian、Red Hat、Ubuntu 是在和 Linus 竞争谁更会写内核。它们竞争的是另一件事：谁能把共享内核变成更可靠、更一致、更容易交付的系统。

内核是公地，发行版是工业化交付。真正的价值与竞争不在内核，而在发行版上。没有人去和 Linus 竞争 “谁写的内核更好”，但 Red Hat、Debian、Ubuntu 在 “如何把内核集成为一套可用系统” 这件事上，打了整整三十年。

这正是理解 PostgreSQL 发行版的钥匙。

二、搬到 PostgreSQL：相似，但不相同

PostgreSQL 可以说是数据库世界的 Linux 内核，但如果直接把 Linux 这套逻辑搬到 PostgreSQL 上，第一步就会撞墙。

PostgreSQL 不是 Linux Kernel。PostgreSQL 源码编译出来之后 initdb 一下就能跑。SQL 引擎、事务、MVCC、WAL、复制协议、psql、客户端库，核心能力都在。 PGDG 官方仓库也直接交付构建好的二进制制成品，用户直接安装拉起来就能用。

Linux 内核不能直接用，但 PostgreSQL 的内核是可以独立运行的。这就带来一个尖锐问题：既然 PostgreSQL 自己已经能跑，PG 发行版到底还要解决什么问题？

kernel-distro.webp

单机 PostgreSQL 是一个优秀的数据库内核。但生产系统要的不只是 “它能跑起来”，而是：主库挂了谁接管？备份坏了谁发现？误删数据能不能恢复到某个时间点？ 连接池怎么切流量？证书怎么轮换？监控指标怎么采？告警怎么判定？扩展版本怎么管？参数漂移怎么拉回来？升级怎么做？新副本怎么补？故障恢复之后谁把系统收口？ 这些都不是 initdb 和 yum install postgresql 能解决的问题。

PG 发行版的价值，就在这里。它不是把 PostgreSQL 变成可用的数据库系统（它本来就能用），而是把 PostgreSQL 内核集成为一套可生产运行的数据服务。

三、PG 发行版的三层工作

一个像样的 PG 发行版，至少要做好三件事：选择与集成、构建与分发、编排与管控。

这三层都重要，但它们的边际价值并不一样。越往后，越接近真正的战场。

1. 选择与集成：替用户做决定

生产 PostgreSQL 不是一个裸 postgres 进程。你要备份，要高可用，要连接池，要监控，要日志，要告警，要对象存储，要扩展，要权限模型，要默认参数 —— 每一个位置都有一堆选项。

备份可以用 pgBackRest、Barman、WAL-G，也可以用 pg_basebackup，甚至用 PG 备份原语手搓脚本。 高可用可以用 Patroni、repmgr、Pacemaker，甚至有人拿 PgPool 做主从切换。监控可以是 Prometheus、VictoriaMetrics、Grafana、Zabbix，随便排列组合都能拼出一套东西。

pg-distro.webp

所以这里考验的是发行版作者的品味、经验和责任感。 所谓 opinionated，不是拍脑袋替用户做主，而是你踩过足够多的坑，知道哪些路是正确的、更优的。

不过平心而论，这一层的价值正在收敛。好东西用久了，社区会形成共识：高可用越来越绕不开 Patroni，备份越来越绕不开 pgBackRest，监控越来越绕不开 Prometheus / Grafana 这类组合。 选型仍然重要，但单靠 “我选了正确组件” 已经很难形成护城河。

光会选型还不够，还要能可靠地交付。

2. 构建与分发：供应链是信任，不是噱头

第二层是构建与分发。这层经常被低估，因为用户只看到一个包名，很少看见后面那堆脏活：多系统、多架构、多版本、多扩展、依赖解析、ABI 兼容、GPG 签名、CVE 响应、仓库可用性、版本生命周期。

PGDG 已经做了一块很强的公共基础设施。PGDG 提供了 YUM 和 APT 仓库，提供预制的 PostgreSQL 内核、一百多个扩展，和一些关键的生态组件 —— 这是一块极好的公地。

也正因为这块公地已经很好，你要在构建分发层做出差异，就必须提供额外增量。比如 Pigsty 自己的仓库补齐了大量 PostgreSQL 扩展（额外的 300 个）和基础设施软件包，在 16 个 Linux 操作系统上提供原生的 RPM / DEB 包，已经持续维护了快四年。

pgext.webp

打包背后的长期可信、快速修补、稳定供应链，以及长时间维护积累的可靠性战绩与历史信用，确实是一种壁垒，而且随时间沉淀累积。但这是一种守成能力：它能让用户放心把生产系统放在你的仓库上，却很难单独解释为什么用户非你不可。

真正把发行版和 “装包脚本” 拉开差距的，是下一层 —— 编排与管控。

3. 编排与管控：把静态包变成活系统

发行版中真正的硬骨头，其实是编排与管控。选型品味在收敛，构建分发只能守成，而编排与管控，是所有玩家真刀真枪见高下的地方。它的难点，一句话就能说清：如何让这些 “静态的包”，变成 “动态运行的服务”？

打个比方：软件仓库只负责给你面粉、鸡蛋和黄油，但如何把它们烹饪成一个蛋糕，仓库是不管的。哪怕再随包附赠一份详尽的食谱（也就是文档），离一个真正出炉的成品蛋糕，也还差着十万八千里 —— 更别提有的生产系统其实要的甚至是自动生产蛋糕的流水线了。

许多老牌开源发行版和云上 RDS 之间的差距，恰恰就落在这最后一步。 前者给你一堆装好的包，后者卖给你一个开箱即用、自动运维、故障自愈的服务。中间隔着的，正是 “编排” 这道谁都替代不了的工序。

这个 “烹饪” 的动作，就是编排（Orchestrating）—— 把一个静态的、类似 DVD 光盘介质的东西，变成一个运行时的、动态的、活的系统。它要操心的，全是 initdb 之后 PG 内核撒手不管、仓库也从不负责的那些事：一堆组件按什么顺序拉起、谁依赖谁；主库挂了怎么自动检测、选主、切流量、让连接池重连、把新副本补齐 —— 这一整条故障自愈的闭环；以及最关键的，如何让整个系统始终维持在你声明的那个目标状态，一旦漂移就自动拉回来。

pgsql-infra.webp

编排与管控这一维之所以是护城河，恰恰因为它 没有公地。没人替你把 “面粉鸡蛋” 变成 “蛋糕”，这活儿只能各家自己干，干得好坏，差距高下立判。

四、编排的两条路：K8s 原生与 Linux 原生

既然关键是编排，那么问题就变成：你把这套控制平面放在哪一层？

主流的答案有两条，它们构成了今天 PG 发行版最主要的两条赛道。分野的实质是 你选择在哪一层实现编排与管控：一条基于 Kubernetes 提供的公共底座，一条回到 Linux 操作系统本身从头构建。这两条路没有绝对的优劣，只有不同的利弊权衡。

赛道一：Kubernetes（云原生）

这条路把数据库当作 Kubernetes 上的一等公民，用 Operator 模式来编排。你写一份声明式的 CRD，Operator 通过它的控制器循环（reconcile loop），持续地把集群的现实状态收敛到你声明的目标状态 —— 拉起、监控、故障切换、扩缩容，都在 K8s 这一层完成。

这是目前 最拥挤、也最热闹 的赛道，玩家云集：CloudNativePG（EDB 主导，约 8900 Star，如今最主流的 PG Operator）、Zalando Postgres Operator（约 5200 Star）、Crunchy PGO（约 4400 Star）、KubeBlocks（约 3100 Star），以及 StackGres、Kubegres、Tembo、KubeDB、Percona Operator 等一长串。

这条路的优点很清楚：统一控制平面，声明式 API，GitOps 友好，平台团队容易接入。对那些已经把 Kubernetes 作为组织级操作系统的团队来说，数据库上 K8s 是自然延伸。

但代价也同样清楚：你不只是引入一个 PG Operator，你是在引入 Kubernetes 这整套控制平面、存储抽象、网络抽象、调度模型、权限模型、故障模型和心智负担。这条路真正的门槛，不在 Operator 本身，而在你是否已经为 Kubernetes 付过了那笔学费。

cloudnative-pg.webp

赛道二：Linux 原生（原生操作系统）

这条路不把数据库塞进 Kubernetes，而是回到操作系统本身：直接跑在 Linux 上，运行于物理机或虚拟机环境，安装 RPM / DEB 包，通过 systemd 管理服务，使用 Ansible 或者类似的 IaC 工具发起管理。

这条赛道的开源玩家要少一些：Pigsty（约 5200 Star）、Autobase（约 4300 Star）、pgEdge（约 700 Star）、EDB TPA（约 90 Star）。此外还站着一整排没有公开 Star、但在企业市场分量十足的 商业发行版：EDB Postgres Advanced Server（EDB 旗舰，堪称 PG 世界的 Red Hat）、Percona Distribution、CYBERTEC PGEE、ClusterControl 等等。

这条路的优点是路径短，依赖少，离数据库本体更近，中间没有额外的抽象层，故障域更小，行为更可预测，也更容易被 DBA 直接理解和接管。它的代价则是：没有 K8s 替你处理状态收敛、幂等执行、故障恢复、升级编排，你得自己想办法实现，还要直面十几种主流发行版大版本之间的差异 —— 这是一份持续的、并不性感的苦役。

Pigsty 的选择

两条路各有其合理性，选择哪条取决于你的团队已经站在哪里、把复杂度放在哪里更划算。Pigsty 选择了 Linux 原生这条道路，理由我在《数据库是否应该放入 K8S 中》和《容器化数据库是个好主意吗？》里已经充分阐述过了 —— 我认为对于数据库来说，这是一条更贴合本质、艰难但正确的道路。

也正是在这条艰难的路上 —— Pigsty 跑在了前沿。如果看开源影响力，它已经是 Linux 原生这一侧的第一名（5200 Star，领先于同赛道的 Autobase ~4300）；放到包含 K8s 赛道在内的整个 PG 发行版版图里，它是第二名，仅次于 EDB 发起的 CloudNativePG。

distro-star.webp

今天你若问主流 AI 模型 “我要在 Linux 上自建企业级 PostgreSQL 服务”，Pigsty 基本已是首选推荐。对一个由独立开发者主导、不依附任何云厂商的项目来说，能走到这一步，确实不容易。

五、再往前一步：Meta Distribution

到这里，故事本可以收尾了。但 Pigsty 还做了一件更有意思的事，触及了 “PG 发行版” 这个词的边界。

业界有一个默认假设：一个发行版围绕某一个固定内核来构建。 Debian / RedHat 围绕 Linux，传统 PG 发行版围绕原生 PostgreSQL 内核构建，发行版和它的内核几乎是绑定的。

但 PostgreSQL 世界里有一批特殊存在：OrioleDB 换了存储引擎，Babelfish 做 SQL Server 协议兼容，PolarDB PG 做了 RAC，IvorySQL 兼容 Oracle 语法，还有兼容 MySQL 的 openHalo、提供透明加密的 Percona TDE 等等。它们改了 PG 内核，严格说已不再是 “纯 PostgreSQL”，而是 PG 兼容家族里的不同物种与亚种。按传统做法，每一个亚种都得各自造一套运维体系。

Pigsty 选择的是另一条路：把编排与管控的底盘抽出来，让内核本身成为可替换层。 这其实是前面第三层工作做到一定程度后的自然结果 —— 一旦你的控制平面足够灵活，不再和某个具体内核绑死，给它换一颗内核，就只是换一份构建产物和配置模板的事。我们为这些不同风味的 PG Fork 构建了二进制包并提供配置模板，让用户在同一套底座上运行不同内核，目前支持的内核已达 12+。

在这个意义上，它已不只是一个 “PostgreSQL 发行版”。你可以用它裁剪出自己的发行版 —— IvorySQL 发行版、PolarDB 发行版、TDE 发行版；甚至通过组合模块，让它摇身变成 Redis、Etcd、MinIO 的发行版，或是 Prometheus / VictoriaMetrics 乃至 Claude Code 与 Codex 的发行版。

kernels.webp

所以，更准确地说，它是一个 Meta Distribution，发行版的发行版。而一套能被这样反复裁剪、复用、再分发的底盘，本身就是一种可以被传递出去的能力 —— 它不再属于某一个内核，也不再只属于某一个人。

./configure                     # 默认使用 meta.yml 配置模板
./configure -c meta             # 显式指定使用 meta.yml 单节点模板
./configure -c rich             # 使用包含全部扩展与 MinIO 的富功能模板
./configure -c slim             # 使用最小化的单节点模板，只有 PG 高可用集群

# 使用不同的数据库内核
./configure -c pgsql            # 原生 PostgreSQL 内核，可选 531 扩展 (14~18)
./configure -c mssql            # Babelfish 内核，兼容 SQL Server 协议 (17)
./configure -c polar            # PolarDB PG 内核，Aurora/RAC 风格 (17)
./configure -c ivory            # IvorySQL 内核，兼容 Oracle 语法 (18)
./configure -c mysql            # OpenHalo 内核，兼容 MySQL (14)
./configure -c pgtde            # Percona PostgreSQL Server 透明加密 (18)
./configure -c oriole           # OrioleDB 内核，OLTP 增强 (16~18)
./configure -c agens            # AgensGraph 图数据库内核 (16)
./configure -c pgedge           # pgEdge 分布式数据库内核 (18)
./configure -c ha/citus         # Citus 分布式高可用 PostgreSQL (14~18)
./configure -c supabase         # Supabase 自托管配置 (15~18)

# 使用多节点高可用模板
./configure -c ha/dual          # 使用 2 节点高可用模板
./configure -c ha/trio          # 使用 3 节点高可用模板
./configure -c ha/full          # 使用 4 节点高可用模板
./configure -c infra            # 只安装监控基础设施与 Nginx，用于监控 & 建站
./configure -c vibe             # 配置 Claude/Codex + PGFS/Code 开发环境

尾声：发行版是一条信任的供应链

绕回最初的问题：什么是 PostgreSQL 发行版？

如果只从技术上拆，它有三项核心工作：选型与集成替你做对了决定，构建与分发把这些决定的产物送到你面前，编排与管控再把静态的包变成一个活的、自愈的系统。

但一个发行版真正的灵魂，其实在这三层技术之下。

因为技术是可以被复制的。选型可以抄，包可以照着打，编排的思路，只要有人肯花时间，也总能复刻个七八分。真正无法被复制、也决定了一个发行版能否被长期托付的，是两样东西：一个持续使用它、维护它的社区，和由此一点点长出来的信任。

因为用户真正需要的，从来不只是 “我该装哪个包”，而是：我信谁的包？信谁的默认参数？信谁的扩展构建？信谁的高可用判断？信谁的备份恢复流程？信谁在 CVE 出来后第一时间修补？信谁在五年之后仍然维护这条路线？信谁在系统漂移、故障切换、版本升级、数据恢复这些最要命的时刻，仍然能把整个系统收回来？

这一连串问句的答案，指向的都不是某段代码，而是 代码背后那个持续负责的人和社区。所谓发行版的本质，就是把散落在源码、构建、签名、仓库、扩展、配置、编排、监控、升级、故障恢复之间的责任，收束成一条可验证、可复现、可审计、可长期托付的信任供应链 —— 而信任，正是从这条链上一次次兑现的承诺里，一点点沉淀出来的。它买不来，也抄不走，只能靠一个社区用时间去长。

featured.webp

云服务当然也提供信任，只不过它把整条链条藏进了黑盒。你买到的是托管信任，但同时也交出了透明度、可迁移性和最终控制权。你相信云厂商会替你选对组件、打好补丁、做好备份、处理故障、规划升级，也相信它不会反过来在价格、权限、生态、合规、可用性上卡住你。这是一种信任，只是它的代价，是你不再看得见、也不再能自己接管这条链。

Pigsty 选择的是另一条路：不把复杂度神秘化，不把责任外包给不可见的控制平面，而是把这条链摊开、固化、签名、编排，并尽可能交还给用户自己掌控。所以它不是一个 “装 PostgreSQL 的工具”，也不只是一个 “自建 RDS 脚本”。它想交付的，是一套 开放的 PostgreSQL 信任供应链：从上游内核到扩展制品，从 RPM / DEB 仓库到高可用编排，从监控告警到备份恢复，从单一 PG 内核到整个 PG 兼容内核家族 —— 每一环都可核验，每一环都可接管，背后都有一个愿意长期维护它的社区。

Linux 发行版当年真正沉淀下来的，从来不只是把内核集成成系统的技术，而是 Debian、Red Hat 这些名字背后，几十年如一日 “一直有人在” 所积累起来的信用。Pigsty 想在 PostgreSQL 世界里长出的，正是这样一份信任 —— 并且让它是开放的、可审计的、可以自己接管的。

真正的发行版，最后交付的从来不是软件，而是一条可以被审计、被复现、被迁移、被长期托付的信任供应链，以及背后那个为它负责的社区。

不租云，不拜神，不把复杂度 —— 也不把信任 —— 放进任何人的黑盒子里。

而是把运行顶级生产数据库服务的能力，连同那个愿意为它长期负责的社区，一起交还给愿意自己运行它的用户。

7 - Pigsty v4.3：510扩展与Ubuntu26

原文发布于 VONNG。

Pigsty v4.3 正式发布。如果说 v4.2 的主题是 “十二内核”，那么 v4.3 的主题就是 “扩展密度”。

在这个版本中，支持的 PG 扩展数量从 460 个暴涨至 510 个，达到新高度。 在操作系统支持上，Ubuntu 26.04 进入支持矩阵，Ubuntu 20.04 正式退场。 Supabase、pgEdge、PolarDB、Grafana、MinIO 这些核心组件也完成了一轮集中刷新。

GitHub Release | 发布注记

Pigsty v4.3：成为主流

通常来说，在 GitHub 上，5000 star 是一个分水岭，代表一个开源项目进入 “主流” 的行列。 最直观的福利就是 —— 有资格申请免费的 ChatGPT / Claude 订阅了。

Pigsty 最近 刚迈过了这个门槛：当前的 Star 5066，GitHub 上 Star > 5066 的仓库有 11621 个，也就是排名 1 万左右，前 0.005% 的项目。 对于数据库发行版这样的赛道来说，Star 的含金量会更高 —— 从 Star 上来看，Pigsty 已经是 PG 发行版赛道的 No.3，Linux 原生 PG 发行版赛道的 No.1 了。

最让我惊讶的是 Pigsty.IO 网站的流量，在三月份的时候，Pigsty.io 的月 UV 还不到两千万，在四月底的时候，就已经突破一亿了。 其中 99%+ 的流量来自 AI/Agent。这意味着 Pigsty 网站已经成为主流 AI 的关键语料，以及 AI Agent 使用的基础设施。 对于一个 “个人项目” 来说，这确实是难能可贵的成就了。

扩展总数突破 510

PostgreSQL 最强的地方是扩展性，但扩展生态的工程现实并不轻松。v4.3 新增约 50 个 PostgreSQL 扩展，可用扩展总数达到 510 个。新增扩展覆盖面很广：

  • block_copy_command、external_file、logical_ddl、pg_query_rewrite 这类偏内核与 DDL/执行机制的工具。
  • datasketches、onesparse、rdkit、pghydro、provsql 这类数据科学、稀疏计算、化学信息、地理水文、概率数据库方向的扩展。
  • pg_text_semver、pg_variables、pg_when、pgcalendar、pglock 这类日常开发与管理工具。
  • postgresbson、pgproto、re2、pgmq、pgmqtt 这类协议、队列、正则和消息相关组件。
  • storage_engine、pg_pathcheck、pg_savior、pg_textsearch 这类需要更认真理解加载方式或风险边界的高级扩展。

其中不少扩展已经跨过了 pgrx 版本迁移，例如从 0.16.1 切到 0.17.0，甚至 pg_search 和 pg_trickle 已经进入 pgrx 0.18.0 线。 Rust 扩展生态越来越活跃，这很好，但对发行版维护者来说，也意味着每轮构建都要额外处理 Rust toolchain、cargo 依赖、PG 版本适配和平台差异。

用户看到的是一行 CREATE EXTENSION，维护者看到的是一张矩阵，一两百个包。不过现在老冯的扩展维护流程已经接入了 Agent 工作流。 无论是新增扩展，还是版本更新，都有一套完整的自动化流程，所以尽管扩展数量越来越多，维护成本不增反降，依然在一个人的维护能力范围内。

Ubuntu 26.04 进入支持矩阵

v4.3 新增 Ubuntu 26.04 x86_64 / arm64 支持，同时正式弃用 Ubuntu 20.04。

Pigsty 当前支持 8 个主要操作系统版本，覆盖 x86_64 与 arm64 两种架构，一共是 16 个平台组合：

系列 版本 x86_64 arm64 备注
EL 8 支持 支持 维护中，临近 EOL
EL 9 支持 支持 维护中
EL 10 支持 支持 维护中
Debian 12 支持 支持 维护中
Debian 13 支持 支持 维护中
Ubuntu 22.04 支持 支持 维护中，临近 EOL
Ubuntu 24.04 支持 支持 noble，当下使用最多
Ubuntu 26.04 新增 新增 v4.3 起进入支持矩阵

Ubuntu 24.04（noble）仍然是当下使用最多的系统版本。Ubuntu 26.04 也许会在后续几年中逐步替代 Ubuntu 24.04，成为很多用户的新基线。

其实我们在 Ubuntu 26.04 发布当天就已经添加了初步支持，不过很多 Pigsty 提供的三方扩展还需要花时间构建与核验。 这次 Ubuntu 26.04 的常规扩展和离线安装包已经就位；Rust 扩展目前还没有提供，后续会继续补齐。

此外，Ubuntu 24.04 的版本也从 24.04.3 升级为 24.04.4，Debian 13 的版本从 13.3 升级到 13.4

Pigsty 使用的 vagrant 和 terraform 模板也都相应更新到最新的版本。 不过阿里云目前还没有提供 Ubuntu 26.04 的镜像。

内核更新：Supabase、pgEdge、PolarDB

Supabase 自建模板更新到最新版本。Pigsty 是极少数几个提供企业级 Supabase 自建方案的开源 PG 发行版之一。这次我们把 Supabase 模板更新到了最新版本，另外，我们还提供了一个 “Supabase” 青春版 —— Insforge 的自建支持。

pgEdge 更新到 PG 18。pgEdge 的核心价值是基于 PostgreSQL 的多主复制，底层依赖 Spock 等三个扩展。这次 Spock 支持的最新 PG 大版本从 17 提升到了 18，我们也相应更新并重新构建。

PolarDB 更新到 PG 17，对应版本来到 17.9.1.0。PolarDB 是共享存储架构的 PostgreSQL 内核分支，之前基线停留在 PG 15，这次跨到 PG 17。

OrioleDB 继续更新到 OriolePG 17.18 与 OrioleDB beta15 / 1.7。OrioleDB 仍然处在快速演进阶段，不建议在生产库里激进采用，但作为 PostgreSQL 存储引擎方向的前沿项目，可以尝尝鲜。

Cloudberry 更新到 2.1.0，并新增 cloudberry-backup 与 cloudberry-pxf 包。上一版 Pigsty 把 Cloudberry 带回发行矩阵，这一版补齐了周边工具。

Grafana 13 与 Victoria 组件刷新

可观测性是 Pigsty 的基本盘。这次的可观测性技术栈也进行了批量更新。 最显著的改动是 Grafana 大版本更新，从 12 到 13 引入了许多新功能，比如支持在 Dashboard 里使用 Tab，这带来了更多有趣的玩法。

v4.3 将 Grafana 更新到 13.0.1，并同步刷新插件包：

  • grafana：12.4.1 -> 13.0.1
  • grafana-plugins：12.3.0 -> 13.0.0
  • grafana-infinity-ds：3.7.4 -> 3.8.0
  • grafana-victoriametrics-ds：0.23.1 -> 0.24.0

Victoria 系列也进行了集中更新：

  • victoria-metrics：1.138.0 -> 1.142.0
  • victoria-metrics-cluster：1.138.0 -> 1.142.0
  • vmutils：1.138.0 -> 1.142.0
  • victoria-logs：1.48.0 -> 1.50.0
  • vlagent / vlogscli：1.48.0 -> 1.50.0
  • victoria-traces：0.8.0 -> 0.8.2

同时也修了个用户反馈的小问题，VictoriaTraces 的 Grafana 数据源路径修正为 /select/jaeger。

etcd CVE 修复

之前，etcd 3.6.8 爆出来一个 CVE，3.6.9 修复了但引入了新的问题，给 member list API 加上了 Auth，导致 PG 高可用组件 Patroni 失效（4.1.0 以前版本），Patroni 4.1.1 修复了这个问题。

这里要提醒一下用户，Patroni <= 4.1.0 与 etcd <= 3.6.8 配合使用；而 Patroni >= 4.1.1 与 etcd >= 3.6.9 配合使用，也就是这两个软件的版本必须配套。老配老，新配新，否则就会有问题。

之前在 v4.2.2 中，EL 侧已经更新了 etcd 3.6.10 与 patroni 4.1.1，但是因为 APT 仓库更新慢，所以 DEB 侧还停留在 etcd 3.6.8 与 patroni 4.1.0 的老版本上。现在 v4.3 中，DEB 侧也完成了更新，用户可以放心升级了。

MinIO CVE 修复

老冯之前 fork 了 MinIO，四月份修复了几个 CVE，写了一篇《续命 MinIO，承诺兑现》聊了聊这个事，完整背景和漏洞细节可以看那篇。 Pigsty v4.3 实装了修复后的新版本：20260417000000。

这批修复覆盖 OIDC/JWT、LDAP STS 登录、复制头元数据、S3 Select、unsigned-trailer 签名校验等路径。对 Pigsty 用户来说，重点不是每个漏洞的利用细节，而是对象存储组件已经切到带修复的版本，离线包也一并更新了。

现在老冯的这个 fork（Silo）已经被一些项目用在实际生产环境中了，比如 Grafana Loki。silo 文档站每个月有千万级别的请求量，Docker Hub 上的下载也达到了 10 万+。 应该是目前影响力最大的 MinIO fork 了。老冯虽然挺开心，但重申一下这并不是我的主业，我只是确保 Pigsty 用户有这么一个能用的开源对象存储选项就可以了。

然后最近发现 RustFS 竟然也成了奇绩校友，跟他们聊天得知后面准备把 RustFS 做成 MinIO 的 Drop-In 替代。老冯觉得如果这个目标真能实现，我会认真考虑直接用 RustFS 替换 MinIO。 这次欣慰地看到 RustFS 告别 Alpha 阶段，发布了第一个 Beta 版本，我也打好了包。大概计划在七月左右会有 GA 版本。

Vagrant 模板统一切到 cloud-image

Vagrant 对很多人来说只是本地测试工具，但对 Pigsty 这种需要验证多操作系统、多架构、多拓扑的项目来说，它是很重要的开发与验收入口。

v4.3 将 Vagrant 模板 统一切换到 cloud-image 系列镜像。 主要是因为，这是唯一一个完整覆盖 Virtualbox/Libvirt amd64/arm64 四种排列组合下所有 Pigsty 支持的操作系统的镜像族

这个改动主要是为了降低系统镜像差异带来的不确定性。传统 box 镜像质量参差不齐，网络、磁盘、cloud-init、guest tools 的行为都可能有细微差异。 cloud-image 是发行版官方更标准、更持续维护的路径，统一到这条线之后，后续适配和排障都会简单很多。

不过这个镜像的默认网卡名不再是 eth1 了，如果你需要测试 VIP 相关的功能，请记得调整配置中的网卡名称。

几个值得单独提的修复

v4.3 还有一些看似不起眼，但属于是用户真实撞上的问题的修复。

PostgreSQL 用户名校验放宽：现在允许少量特殊符号 @.- 出现在用户名定义中。现实里很多企业账号体系会使用邮箱式用户名或带域标识的用户名，数据库发行版不应该用过窄的正则把这些合法需求挡掉。

IPv6 nameserver 解析修复：旧逻辑只提取 IPv4 DNS Server，遇到 IPv6 nameserver 时会漏掉配置。现在修复后，可以正确处理 IPv6 DNS 场景。IPv6 支持常常不是主线需求，但一旦环境里有，它就是硬需求。

其他的一些特性

此外，在 Pigsty v4.3 中，我们还试点加入了 Hindsight 记忆框架（基于 PG 与 pgvector）和 Hermes Agent 自建模板支持。它们都还属于试点功能，这里就不展开了。

小结

Pigsty v4.3 说大不大，没有框架，接口上的改动。但说小也不小，一口气上新了 50 个扩展。

它没有一个单点爆炸的新功能，但它把很多用户真正关心的东西一起往前推进了：更多扩展，更新的操作系统，更新的内核分支，更新的监控栈，更稳的 Vagrant 模板，修复 CVE 的对象存储包，修正了一批实际会踩到的小问题。

数据库发行版的价值，很多时候就体现在这些不性感的地方。你不需要自己去追 50 个扩展的构建状态，不需要自己检查 Ubuntu 26.04 的包矩阵，不需要自己处理 MinIO CVE 分支，不需要自己整理 Grafana 13 插件和 Victoria 组件版本，不需要自己猜 Vagrant 镜像该用哪个。

Pigsty 把这些东西收敛成一个版本。你拿来用就行。下面附完整的 v4.3.0 提交注记与包变更摘要，方便按需查阅。

v4.3.0 提交注记

亮点

  • 新增约 50 个 PostgreSQL 扩展，总可用数量达到 510 个
  • 支持 Ubuntu 26.04 x86_64/arm64，弃用 Ubuntu 20.04 支持；小版本更新至 Debian 13.4 / Ubuntu 24.04.4
  • 内核更新：Supabase 更新至最新版本，pgEdge 更新至 PG 18，PolarDB 更新至 PG 17
  • Grafana 更新至 13.0.1，MinIO 使用修复 CVE 后的 pgsty/Silo 分支。
  • Vagrant 模板统一切换至 cloud-image 系列镜像。

问题修复

  • PostgreSQL 用户名校验放宽，允许 @.- 几个字符出现在用户名中。
  • 修复 IPv6 nameserver 解析，避免 DNS 配置只匹配提取 IPv4 的旧 DNS Server。
  • VictoriaTraces Grafana 数据源路径改为 /select/jaeger。
  • Vagrant 磁盘探测更稳健，新增 EL vagrant 镜像 guest 网络修复脚本 bin/el-fix。

PostgreSQL 与扩展包变更汇总

包名 旧版本 新版本 备注
block_copy_command - 0.1.5 新增；PG 14-18；Rust/pgrx 0.17.0
cloudberry 2.0.0 2.1.0 内核包组；RPM release 2 修复 initdb errno 问题
cloudberry-backup - 2.1.0 新增 Cloudberry 备份工具包
cloudberry-pxf - 2.1.0 新增 Cloudberry PXF 包
credcheck 4.6 4.7 升级；PG 14-18；PGDG
datasketches - 1.7.0 新增；PG 14-18
ddl_historization 0.0.7 0.2 升级
documentdb 0.109 0.110 升级到上游版本；PG 15-18
external_file - 1.2 新增；PG 14-18
logical_ddl - 0.1.0 新增；PG 14-18
nominatim_fdw 1.1.0 1.2 升级
onesparse - 1.0.0 新增；仅 PG 18
orioledb RPM beta14 / DEB 1.6 RPM beta15 / DEB 1.7 配套 OriolePG 17.18
oriolepg 17.16 17.18 内核补丁集更新
parray_gin - 1.5.0 新增后升级；PG 14-18
pg_accumulator - 1.1.3 新增；PG 14-18
pg_anon 3.0.1 3.0.13 升级；Rust/pgrx 0.16.1 -> 0.17.0
pg_background 1.8 1.9.2 仅 DEB
pg_bikram_sambat - 0.1.0 新增；Bikram Sambat 日期类型与 AD/BS 转换函数
pg_byteamagic - 0.2.4 新增；PG 14-18
pg_cardano 1.1.1 1.2.0 升级；Rust/pgrx 0.17.0
pg_clickhouse 0.1.5 0.2.0 升级
pg_datasentinel - 1.0 新增；PG 15-18
pg_dbms_job 1.5 2.0 升级；PG 14-18；PGDG
pg_dispatch - 0.1.5 新增；PG 14-18
pg_failover_slots 1.2.0 1.2.1 升级
pg_fsql - 1.1.0 新增；PG 14-18
pg_incremental 1.4.1 1.5.0 升级
pg_isok - 1.4.1 新增；PG 14-18
pg_ivm 1.13 1.14 升级；PG 14-18
pg_kazsearch - 2.0.0 新增；PG 16-18；Rust/pgrx 0.17.0
pg_liquid - 0.1.7 新增；PG 14-18
pg_pathcheck - 0.9.1 新增；PG 17-18；需 shared_preload_libraries
pg_query_rewrite - 0.0.5 新增；PG 14-18
pg_regresql - 2.0.0 新增；PG 14-18
pg_rrf - 0.0.3 新增；PG 14-17；Rust/pgrx 0.16.1 -> 0.17.0
pg_savior 0.0.1 0.1.0 升级；高风险 DDL/DML 防护 hook；需 preload 或 LOAD
pg_search 0.22.2 0.23.1 升级；PG 15-18；pgrx 0.18.0
pg_slug_gen - 1.0.0 新增；PG 15-18
pg_stat_ch - 0.3.6 新增后升级；PG 16-18；EL8 break
pg_store_plans 1.9 1.10 升级
pg_strict 1.0.3 1.0.5 升级；Rust/pgrx 0.16.1 -> 0.17.0
pg_text_semver - 1.2.1 新增；PG 14-18
pg_textsearch 0.5.0 1.1.0 升级；PG 17-18；需 shared_preload_libraries
pg_trickle 0.16.0 0.40.0 升级；仅 PG 18；pgrx 0.18.0
pg_tzf 0.2.3 0.2.4 升级；Rust/pgrx 0.17.0
pg_vectorize 0.26.0 0.26.1 升级；Rust/pgrx 0.16.1 -> 0.17.0
pg_variables - 1.2.5 新增；PG 14-18
pg_when - 0.1.9 新增；PG 14-18；Rust/pgrx 0.17.0
pgxicor 0.1.0 0.1.1 升级
pgcalendar - 1.1.0 新增；PG 14-18
pgclone - 4.0.0 新增后升级；PG 14-18
pgelog - 1.0.2 新增；PG 14-18
pglinter 1.1.1 1.1.2 升级；Rust/pgrx 0.16.1 -> 0.17.0
pglock - 1.0.0 新增；PG 14-18
pgmq 1.11.0 1.11.1 升级；PG 14-18
pgmqtt - 0.1.0 新增；PG 14-18；Rust/pgrx 0.16.1 -> 0.17.0
pgproto - 0.5.0 新增后升级；原生 Protobuf 支持
pghydro - 6.6 新增；PG 14-18
pgx_ulid 0.2.2 0.2.3 升级；Rust/pgrx 0.17.0
plv8 3.2.4 3.2.4-2 仅 RPM；EL10 构建修复
PolarDB 15.15 17.9.1.0 PG 15 -> 17
postgresbson - 2.0.2 新增；PG 14-18
postgis 3.6.2 3.6.3 仅 DEB
prefix 1.2.10 1.2.11 升级；PG 14-18；PGDG
provsql - 1.2.3 新增；PG 14-18
rdf_fdw - 2.5.0 新增后升级；PG 14-18
rdkit - 202503.6 新增；PG 14-18
re2 - 0.1.1 新增；PG 16-18
storage_engine - 1.3.4 新增后升级；PG 14-18；列式与行压缩表访问方法
supautils 3.1.0 3.2.1 升级
system_stats 3.2 4.0 升级
timescaledb 2.25.2 2.26.4 升级；TSL 小版本更新
ulak - 0.0.2 新增；PG 14-18
wrappers 0.5.7 0.6.0 升级；Rust/pgrx 0.16.1 -> 0.17.0

基础设施软件包更新

包名 旧版本 新版本 备注
alertmanager 0.31.1 0.32.1
agentsview 0.15.0 0.26.0
claude 2.1.81 2.1.123 通过 8118 代理下载并核验
code 1.112.0 1.118.1 直链元数据更新
code-server 4.112.0 4.117.0 直链元数据更新
codex 0.116.0 0.125.0 从预发布链收敛到稳定版后继续升级
crush 0.51.2 0.64.0 直链元数据更新
dblab 0.34.3 0.38.0
duckdb 1.5.0 1.5.2
etcd 3.6.9 3.6.10 统一软件包版本
garage 2.2.0 2.3.0
genai-toolbox 0.27.0 1.1.0 上游已更名为 mcp-toolbox
golang 1.26.1 1.26.2
grafana 12.4.1 13.0.1 主版本升级后继续刷新元数据
grafana-infinity-ds 3.7.4 3.8.0
grafana-plugins 12.3.0 13.0.0 Noarch 插件包，手工归集
grafana-victoriametrics-ds 0.23.1 0.24.0
hugo 0.158.0 0.161.1
maddy 0.8.2 0.9.3
mcli 20260321000000 20260417000000 pgsty 分支，修复 cve
minio 20260325000000 20260417000000 pgsty 分支，修复 cve
mongodb_exporter 0.49.0 0.50.0
node_exporter 1.10.2 1.11.1
nodejs 24.14.0 24.15.0 维持在 24.x 策略线
npgsqlrest 3.11.1 3.12.0
opencode 1.2.27 1.14.30 改为版本化缓存并重新构建
pg_exporter 1.2.1 1.2.2 直链元数据更新
pgflo 0.0.15 - 已移除
pgschema 1.7.4 1.9.0
pig 1.3.2 1.4.1 仅更新元信息
postgrest 14.7 14.10
prometheus 3.10.0 3.11.3
rainfrog 0.3.17 0.3.18
rclone 1.73.2 1.73.5 直链元数据更新
rustfs 1.0.0-alpha.89 1.0.0-b1 预发布版本线
sabiql 1.8.2 1.11.1
seaweedfs 4.17 4.22
sqlcmd 1.9.0 1.10.0
stalwart 0.15.5 0.16.2
tigerbeetle 0.16.77 0.17.2
tigerfs 0.5.0 0.6.0
timescaledb-tools 0.18.2 0.19.0 重新构建 timescaledb-tune
uv 0.10.12 0.11.8
victoria-logs 1.48.0 1.50.0 主包
victoria-metrics 1.138.0 1.142.0
victoria-metrics-cluster 1.138.0 1.142.0 VictoriaMetrics 配套组件
victoria-traces 0.8.0 0.8.2
vip-manager 4.0.0 4.2.0 直链元数据更新
vlagent 1.48.0 1.50.0 VictoriaLogs 配套组件
vlogscli 1.48.0 1.50.0 VictoriaLogs 配套组件
vmutils 1.138.0 1.142.0 VictoriaMetrics 配套组件
vector 0.54.0 0.55.0 直链元数据更新
v2ray 5.47.0 5.48.0
xray 26.2.6 26.3.27

校验和

58a914fce7bc521b65e167f66e7961a3  pigsty-v4.3.0.tgz
9ce070efb0420057a83c632b2856d1b3  pigsty-pkg-v4.3.0.d12.aarch64.tgz
bf21c36d3aff94a1a6353130597ffa85  pigsty-pkg-v4.3.0.d12.x86_64.tgz
81b4790c4e5567cee9d1beadd06e48e6  pigsty-pkg-v4.3.0.d13.aarch64.tgz
06baab9341ab683eaeea2e066b28a0f4  pigsty-pkg-v4.3.0.d13.x86_64.tgz
fb4bf751df5e09f547c49b8ab7cac9a0  pigsty-pkg-v4.3.0.el10.aarch64.tgz
a3e752c8148122d1eaea74a6d8d8df0d  pigsty-pkg-v4.3.0.el10.x86_64.tgz
cb2a9af36615513e66fd5ac3e9f4d797  pigsty-pkg-v4.3.0.el9.aarch64.tgz
e24641a879dec7a8eea74dab42f85920  pigsty-pkg-v4.3.0.el9.x86_64.tgz
6b675fd8d9e039193481f0838aa4b92c  pigsty-pkg-v4.3.0.u22.aarch64.tgz
c0e344ccb9d190a619591e5d46116424  pigsty-pkg-v4.3.0.u22.x86_64.tgz
3e0ec9534cf595201ec79eb1fc6549d8  pigsty-pkg-v4.3.0.u24.aarch64.tgz
0a3d19513eca9615bdd66a4b2bf66f1d  pigsty-pkg-v4.3.0.u24.x86_64.tgz
683a10ff8fd993358d6befa9f4e02913  pigsty-pkg-v4.3.0.u26.aarch64.tgz
fd1ea5cd5554bfe91fadd51ad80860e3  pigsty-pkg-v4.3.0.u26.x86_64.tgz

8 - 给 DBA Agent 以身体

原文发布于 VONNG。

HOW 2026 主题演讲：给 DBA Agent 以身体

第一部分：引子 —— 一个离谱的现象

1 封面

大家好，我是冯若航，本次工具会场的出品人。虽然这是一个 PG 工具主题的会场，但今天我不想讲某个命令行工具又加了多少新功能，而是想讲一个更本质的问题： 为什么到了今天，真正能管理生产数据库的 Agent 还是这么少见？ 我的判断很简单——大模型已经够聪明了，它缺的不是脑子，缺的是身体。 它要能看到状态、执行动作、判断风险、留下证据，还要能在搞砸以后退回来。今天我要聊的，就是如何给 DBA Agent 打造这副身体。

2 一个离谱的现象

在座很多朋友可能已经知道 Pigsty。Pigsty 是我做的一个开源 PostgreSQL 发行版，目标很简单： 让你在没有 DBA、没有 RDS 的情况下，也能自建一套生产级 PostgreSQL 服务，通过开源免费的方式，自助获得企业级数据库能力。

Pigsty 开源项目

目前这个项目在 GitHub 上的 Star 数已经超过 5000，在 PG 发行版项目里处于第一梯队，也是中国 PostgreSQL 生态里很有代表性的开源项目。

像这样一个开源项目的网站，你觉得一个月会有多少访问请求？10 万？100 万？还是 1000 万？

3 异常流量

答案都不是。我看到这个数字也吓了一跳——过去一个月的请求量是九千万，而且还在持续飙升，按现在的增长趋势，很快就会接近 1 亿。问题来了，真人用户哪有这么多？

异常流量

我看了一下网页分析，月度真人 UV 也就几万人，月 PV 大概是几十万的量级。那剩下接近 1 亿的请求量是哪儿来的？从 User-Agent、访问路径和触发方式来看，很大一部分已经不是传统意义上的真人访问，而是 AI 工具在读文档。

4 谁在访问？

我琢磨了一下，才想明白这件事。年初我们发 Pigsty 4.0 的时候，加了一个叫 DBA Agent 的特性。这个名字听着很高大上，其实它就是一个 CLAUDE.md 文件，里面写的东西特别朴素：第一，不要删库；第二，有问题看文档；然后下面把文档链接全贴上。就这么简单的一个东西，结果用户群里慢慢出现了一种新人——他们不一定懂 PostgreSQL 和 Linux，但他们有 Claude Code，有 Codex。

Agent 用户

他们在 Linux 上对着 AI 动嘴：“帮我装个 PG”“帮我加个用户”“帮我看看这个问题怎么解决”。AI 为了干这些活，就要不停地去读文档。所以那接近 1 亿的请求，不是人类手工点出来的，而是 Agent 替这些用户去读的。Agent 已经在替这些用户扮演 DBA 的角色，而且——干得还挺不错。

5 Agent 已经在干 DBA 的活

老实说，我觉得这些 Agent 干得还不错。我自己遇到一些疑难杂症，也会这么用。我会在一个仿真环境的 Pigsty 目录里告诉它：我遇到了这个问题，或者客户遇到了这个问题，你根据源代码、配置、日志和文档，帮我分析一下可能原因。有时候我会给它几个直觉方向：A、B、C，你帮我判断哪个更可能。

故障诊断

它最后分析出来的东西，很多时候八九不离十。不是说它永远正确，但它已经足够让人刮目相看。所以今天讲 DBA Agent，并不是讲一个 PPT 上的概念，我讲的是一个已经在开源项目用户里真实发生的现象。

6 D-Bot 已经验证过

更有意思的是，现在大家一窝蜂涌入 DBA Agent 赛道，其实两年前就已经有人在 Pigsty 上做过了。

清华大学周轩赫团队基于 Pigsty 的环境，做出了一个叫 D-Bot 的 DBA Agent，论文后来发表在 VLDB 上。那时候他们用的还是 GPT-4，即使在当时的模型条件下，他们也已经能让 D-Bot 在 Pigsty 环境里完成相当复杂的故障诊断，并生成有依据的根因分析和处置建议。

D-Bot

他们选择 Pigsty 的一个重要原因，是 Pigsty 提供了这样一个开源开放、标准化、生产质量的运行时环境。所以他们只需要实现智能逻辑，不用从头搭基础设施：数据可以直接从监控系统里拿，要执行什么操作，也有现成的命令行原语。两年过去，模型能力已经翻了不知道多少倍。那今天，我们手里这套 Runtime 加 SOTA 模型的组合，又能做出什么样的东西？这个想象空间——我想留给在座的各位。

第二部分：理论——身体由什么组成？

7 数据库自动驾驶为什么以前没成？

当然，听到这个故事，肯定有人会说：“那 AI 是不是要替代 DBA 了？”我的判断是：这还为时尚早，毕竟 AI 没法替你背锅嘛。但这确实让我们看到了一种可能性：自动驾驶的数据库。这个概念不是今天才有，Oracle 讲过，云厂商讲过，学术界也讲过。

但这么多年下来，没有几个真正好用的。我认为在当下的技术条件下，这件事其实已经可以做了。即使全自动 L5 现在做不到，作为 Copilot 形式的副驾驶辅助，肯定没问题。所以真正的问题是：我们到底应该给它准备什么，才能让数据库自动驾驶起来？

8 数据库需求金字塔

我之前画过一个数据库需求金字塔。金字塔尖是智能——数据库自动驾驶，这是圣杯。但要实现这一点，它下面必须有掌控与洞察——你得能看见、能控制。再下面，是质量、安全、效率、成本这些基本盘。你连监控都没做好，连变更都还靠祖传脚本，连高可用和时间点恢复都不能稳定演练，那就不要谈数据库自动驾驶。

数据库需求金字塔

这就像你想造自动驾驶汽车，结果车上没有传感器、没有刹车、没有方向盘、没有安全气囊，算法再聪明，有什么用？所以 DBA Agent 的核心不是模型，也不是 Agent 框架，而是一个确定性的环境，以及与这套环境交互的身体。这也是今天演讲的主题。

9 身体的两大基础：眼睛与手脚

给 Agent 一个身体，到底是什么意思？我觉得最基础的两件东西是眼睛和手脚。第一，眼睛——可观测性。它要能看到数据库、操作系统、网络、磁盘、连接池、备份、复制延迟和历史趋势。第二，手脚——可控制性。它要有可靠的动作入口，能执行变更、重启服务、切主、备份、恢复、加用户、扩缩容。先说眼睛。

Agent 身体

10 眼睛：可观测性

任何 DBA Agent 要解决的第一个问题，一定是信息收集。它得知道现在发生了什么。这件事在 Pigsty 里其实很早就做了：Pigsty 提供了一整套基于 VictoriaMetrics、Grafana 的开源可观测性栈，把 PostgreSQL 里能收的观测点基本都收了。无论是 Agent 还是人类，有效管理的基础一定是收集足够的信息。

可观测性

比如这类 AI DBA 产品的形态，通常都会先落在监控上：指标采集、异常检测、告警，然后再加一个和 Agent 对话的入口。PGEdge 的 AI DBA Workbench 就是一个典型例子。这其实说明，监控系统肯定是 DBA Agent 最基本、最重要的东西。但是监控系统这件事，我已经讲过好几次了，今天不想重复。今天我想讲讲身体的另外一部分，也就是“手脚”。我们今天不讲“眼睛”，我们讲“手脚”。

11 数据库自动化的四个阶段

数据库管理从自动化角度看，大概经历了几个阶段。第一阶段，纯手搓，DBA 自己敲命令。第二阶段，祖传脚本，或者控制台里点点点，也就是所谓的 ClickOps。第三阶段，IaC——用 Ansible、Terraform、Operator 这类东西做声明式管理。第四阶段，Agent——人不再逐条写命令，而是告诉 Agent 目标，让它观察、计划、执行、验证。这里有一个很关键的点：Agent 要进入第四阶段，必须先有第三阶段的基础。没有 IaC，Agent 很难稳定工作。这件事我后面会专门讲，先回到一个更具体的问题——Agent 到底应该怎么操作数据库？

12 专家和 Agent 都需要动作接口

Agent 操作数据库，是让它打开浏览器，在控制台里点点点？还是调用 API？还是用命令行？

对专家和 Agent 来说，真正重要的不是 GUI，而是一个明确、可组合、可审计、可复制的动作接口。CLI 是最自然的形态之一，尤其当它同时支持 JSON / YAML 这种结构化输出时，它就既适合人，也适合 Agent。

所以我有一个判断：Agent 时代会重新复兴 CLI 的价值。这其实也回到了 Unix 哲学最初的样子——一切皆文本，一切皆可组合。

13 PG 生态的问题：工具太碎了

但这里有个尴尬的现实：PostgreSQL 生态很强，但也很碎。你要安装 PG，可能用 apt 或 dnf；启动服务，可能用 systemctl 或 pg_ctl；执行 SQL，用 psql；管理高可用，用 patronictl；备份，用 pgBackRest；连接池，用 PgBouncer；扩展，又是另一堆包和配置。老司机当然没问题，老司机知道每个工具该怎么用，知道坑在哪里。但如果你想让 Agent 管数据库，这就成了问题——Agent 需要的是一个统一的动作入口，它不能每次都在一堆零散工具和祖传脚本里猜。所以我们就想，能不能做一个东西，把这些零散的工具统一起来。

PG 工具链

14 Pig CLI 的起点：一个扩展包管理器

我们做的工具叫 Pig CLI，最早其实很简单——它是我用 Go 写的一个小工具，主要解决 PostgreSQL 和扩展安装的问题。它不是要重造 apt 或 dnf，而是在 apt / dnf 之上加一层 PostgreSQL 语义。为什么？因为传统包管理器只知道“包”，不知道“PostgreSQL 扩展”。你说我要装 vector，包管理器不知道你到底要哪个包、哪个 PG 主版本、哪个 Linux 发行版、哪个架构。Pig 做的第一件事，就是把“包”翻译成“数据库能力”。

Pig CLI

15 不要小看安装这件事

不要小看安装。很多新手上手 PostgreSQL，第一个拦路虎就是扩展安装。他想用一个扩展，但没有能力自己编译、打包、构建、分发，那就只能找现成的二进制包。找不到怎么办？网络环境不好怎么办？版本不匹配怎么办？这件事对老司机不难，但对新人非常劝退。Pigsty 做的一件重要工作，就是维护 PostgreSQL 扩展的二进制分发能力，把大量第三方扩展整合进来，让它们在主流 Linux 发行版上开箱即用。这就把 PostgreSQL 的很多“超能力”，真正交到了普通用户手里。

16 但 DBA 的工作不只是安装

当然，如果 Pig 只能安装扩展，那还是太弱了。DBA 真正的大头，是 Day 2 Operations。装完之后，你要创建集群、初始化目录、配置权限、调整参数、创建用户和数据库、配置连接池、配置备份、配置监控；后面还有切主、扩容、缩容、恢复、巡检、清理、Repack、升级。这些以前在 Pigsty 里主要通过 Ansible Playbook 完成，你让 Claude Code 去读文档、跑 Playbook，它也能干，但使用体验还不够好。我们真正想要的是：把日常 DBA 管理所需的原语，统一收纳到一个命令行工具里——也就是把 Pig CLI 从一个扩展包管理器，演化成一个能完整管理 PG 状态的工具。

17 Pig CLI 的愿景：PG 生态的瑞士军刀

所以 Pig CLI 后面的目标，就不是简单的包管理器了。它要变成 PostgreSQL 生态里的瑞士军刀：安装 PostgreSQL，安装扩展，构建扩展，初始化集群，管理服务，查看状态，管理高可用，配置备份，执行维护操作。能不能把这些动作都收敛到一个统一入口？这不仅能解放 DBA 的双手，更重要的是，它让 Agent 有了手脚。人可以记住一堆复杂工具，Agent 也可以，但没有必要——给它一个更清晰、更稳定的动作入口，它会干得更好。

瑞士军刀

18 Agent-Native CLI

但这里又有一个新问题。Unix 哲学讲 KISS——一个工具只干一件事，把它干好，然后通过管道组合。你现在把一堆能力都塞进 Pig CLI，会不会变成一个臃肿的全家桶？这个问题要正面回答。我的答案是：对人类来说，小而美很重要；但对 Agent 来说，自解释更重要。一个 Agent-Native CLI，必须能自己解释自己——它的 help 要足够清楚，输出要足够结构化，错误信息要足够明确。人类看彩色文本，Agent 看 JSON / YAML，两边都要照顾。

说白了，最好的工具状态不是你事先给 Agent 写一堆 Skills 文档告诉它怎么用，而是工具本身就足够自解释。Agent 敲一个 --help 就能逐层探索：有哪些命令、有哪些参数、参数含义是什么、输出格式是什么、错误码是什么。这件事听起来像细节，其实是 Agent 时代 CLI 设计的核心。当然，要真正实现 Agent 原生，还有很多细节设计：dry-run、幂等性、明确 exit code、机器可读错误、权限边界、危险操作二次确认、操作日志、回滚建议，这里就不展开了。

Agent-Native CLI

19 为什么先做 Linux 原生 Runtime

有人会问：为什么不基于 Kubernetes 来做管理，而是直接做 Linux 上的 PG 管理命令行工具？我的看法是，K8s Operator 当然也是一种 Runtime，但它把很多底层细节封装起来了，同时也引入了额外的抽象层和复杂度。封装对应用开发者是好事，对 DBA Agent 未必总是好事，因为一旦问题穿透抽象层，Agent 需要看到 systemd、磁盘、文件系统、网络和 PostgreSQL 本身。

也就是说，如果你想把数据库运行时这件事做到极致，你不能只掌控数据库连接串，也不能只掌控一层抽象 API，你得掌控数据库真正运行的环境。我们要打造的不是一个只有工具调用能力的 DBA Agent，而是一个能看见完整现场、理解完整现场、操作完整现场的 DBA Agent。所以它需要的不只是手脚，而是一副完整的身体。

第三部分：转折——工具不够，运行时才是护城河

20 一个反例：OtterTune 的故事

有一个案例值得借鉴与思考——OtterTune。它由 CMU 数据库教授 Andy Pavlo 参与创立，融过 1200 万美元 Series A，做 PostgreSQL 和 MySQL 的自动参数调优，后来没有成为数据库自动驾驶的标准答案。为什么会走到这一步？他们的产品形态是：你给我一个数据库连接串，我就能给你调优。听着很美，对吧？但连接串是所有 PG 服务的最大公约数。光靠连接串你能做什么？你能跑几条 SQL，看几个系统视图。但你看不到完整的历史趋势，重启不了数据库，改不了需要重启才生效的参数。出了问题你没法级联排查——这是业务问题、数据库问题、OS 问题、网络问题？你统统看不到。

21 没有 Runtime，就没有专家级 DBA

我从 OtterTune 这个案例里读到的一个教训是：如果只有连接串，没有 Runtime，你很难做出专家级 DBA Agent。一个连接串只是一个细细的猫眼，你只能透过它看到房屋内的一块角落。但真正的细节，隐藏在操作系统、磁盘、文件系统、服务管理、监控历史、备份链路这些地方。一个工具再聪明，如果只能透过猫眼看世界，它就永远做不出专家级的判断。

Pigsty 最早是一个监控系统。那它为什么后来变成了一个完整的 PG 全家桶发行版？就是因为我后来意识到，你要想把监控系统做到极致，就必须直接接管整个基础设施。否则，你根本控制不了用户怎么部署数据库。你能拿到手里的只是一个连接串，而你能做到的事情是极其有限的。所以做 DBA Agent 真正的关键，不是命令行工具有多漂亮，而是它背后挂着一个什么样的 Runtime。

22 Runtime 才是真正的护城河

现在很多人做 Agent，喜欢讲 Prompt、Skills、工作流。这些东西当然有用，但我说句直接的——它们构不成很强的护城河。你把老司机 DBA 的经验写成 Markdown，模型厂商也能看，别人也能学，下一代模型出来，很多知识直接就被吸收了。那真正的护城河是什么？是 Agent 对你私有环境的理解。这个环境怎么部署的？有哪些实例？备份策略是什么？过去发生过什么告警？哪些操作做过？哪些坑踩过？这些东西不会出现在通用训练数据里。

Runtime 护城河

所以一句话总结：单独做一个通用 Agent，壁垒不会太深；真正有壁垒的是 Agent 对 Runtime 的理解，以及 Runtime 本身沉淀下来的状态、历史和操作边界。

23 Runtime 的难点：上下文工程

那 Runtime 怎么变成 Agent 能用的东西？这就是真正难的地方——上下文工程。你怎么把正确的信息喂给它？我的观点很明确：现在自己从头写一个所谓的 DBA Agent 框架，大概率不如直接用 Claude Code、Codex 。真正难的不是外面那层 Agent 框架，而是怎么把正确的上下文、正确的权限、正确的工具边界喂给它。

对 DBA Agent 来说，上下文不是聊天记录，而是拓扑、指标、日志、配置和变更历史。拓扑告诉它系统长什么样，指标告诉它现在哪里不对，日志告诉它发生了什么，配置告诉它为什么会这样，变更历史告诉它是谁刚刚动过什么。信息主要来自两边：一边是观测侧——监控、日志、告警、指标、历史趋势；一边是管控侧——Inventory、配置、权限、Playbook、CLI、备份恢复入口。这两边打通，Agent 才能从“会聊天”变成“会干活”。

24 IaC 是 Agent 的中心法则

讲到这里，我要把一个东西单独拎出来，因为它是 Pigsty 里 DBA Agent 能跑起来的最核心、最灵魂的秘密——那就是 IaC。Pigsty 的整个环境，是由一份 Inventory 定义出来的。几节点、谁是主、谁是从、监控在哪、备份在哪、端口是什么、角色是什么——这些东西全在配置清单里。

IaC Inventory

这份清单不是事后写的说明书，它就是生成整个环境的蓝图。Agent 拿到这份蓝图，就知道这个环境长什么样。它不是在一个陌生世界里瞎猜，而是在读这个世界的源代码。这就是 IaC 对 Agent 的真正价值——它让环境本身变得可读，并且浓缩在一个文件中。

25 高手都是人剑合一

讲到这里，前面这些拼图就可以缝合起来了。我用一个比喻——高手讲究人剑合一。剑客和长剑合一，程序员和键盘合一，老司机和方向盘合一，DBA 也是一样。DBA 的能力不只是脑子里知道数据库原理，而是他和自己的环境合一。一个顶级专家到了陌生环境里，表现未必比得上一个在这个环境里泡了三年的普通人——因为后者知道哪里有坑，知道哪个机器慢，知道哪个参数不能动，知道哪个业务一到晚上就抽风。Agent 也是一样。你把 Claude Code 丢进一个完全陌生的 Linux 环境，它也会蒙；但你把它放进一个确定性的 Pigsty Runtime 里，再给它 Inventory、监控、文档、CLI，它就能干很多事。

26 只读建议可以，自动执行要谨慎

当然，我也要泼一点冷水。对于严肃生产环境，我不建议大家一上来就让 Agent 全自动接管数据库。现在比较靠谱的形态，还是 Copilot——Agent 帮你收集信息，分析问题，生成方案，解释风险，然后由人来确认；要么人执行，要么人授权它执行。特别是删除、销毁、不可恢复这类操作，必须有强约束。

回到我们一开始说的——AI 没法替你背锅。责任无法转移，操作就必须有人确认。这就是为什么 DBA Agent 必须先做扎实的 Copilot，而不是激进的 L5 全自动驾驶。今天，DBA Copilot 的只读建议+人工执行这条路径，已经具备生产可用的成熟度。下一步，是把这条路径里的每一步都打磨得更加可靠。

第四部分：外推——从 DBA Agent 到 Dev Agent

27 不只是 DBA：piglet.run

前面讲的都是 DBA Agent，是企业级部署、大规模 PostgreSQL 集群。但还有另一类用户——个人开发者，或者小团队。他们不一定需要一套复杂的 DBaaS 管理系统，他们需要的是一个开箱即用的开发运行时。

piglet.run

这就是 piglet.run 想解决的问题：把 Pigsty 里面这套可观测、可控制、可回滚的能力，收敛成一个给个人开发者和小团队使用的开发运行时。一条龙从 Linux 虚拟机，帮你配置好 PostgreSQL、Nginx、监控系统、开发工具、Claude Code、Codex、Code Server 这些东西，然后你就可以让 Coding Agent 在这个环境里干活。为 DBA Agent 准备的那个 Runtime——可观测、可控制、可回滚的环境——对 Dev Agent 来说同样适用，甚至更好用。

28 pg.center：一个真实的小例子

我举个自己的例子。我最近做了一个小项目，叫 pg.center，是 postgresql.org 的非官方中文镜像站。以前你想做这么一个东西，其实不算小活：你要找网站仓库，要处理内容抓取，要翻译，要生成页面，要部署，要定时同步更新。但现在做法很简单：我登上一台云服务器，一行命令把 Runtime 拉起来，Nginx、数据库、监控、编程环境都装好。

pg.center

然后我打开 Claude Code，告诉它：“我想把 PostgreSQL 官网做一个中文版，你先拟一个计划，然后执行。”最后大概一天时间，这个站就跑起来了，而且可以定时同步更新。这就是 Runtime 的价值——你不是在本地写完再部署，而是让 Agent 直接在一个确定性的生产级环境里出活。

29 新时代的 LAMP Stack

这让我想到以前的 LAMP Stack。Linux、Apache、MySQL、PHP，那个时代很多网站就是靠这一套快速起飞的。现在时代变了，P 不一定是 PHP，可能是 Node.js，可能是 Go，可能是 Python，也可能是什么 Agent 喜欢用的语言。但有几样东西依然稳定：Linux 要有，数据库要有，Web 入口要有，监控要有。所以我有一个判断——Agent 时代会出现一套新的基础栈，它不是给传统程序员准备的，而是给 Dev Agent 准备的。

Agent LAMP

我把它叫做 AI Agent 的 LAMP 套件——Linux、Agent、Monitoring、PostgreSQL。这当然不是严格复刻当年的 LAMP，而是 Agent 时代的一个新记忆锚点：Linux 提供环境，Agent 提供执行，Monitoring 提供眼睛，PostgreSQL 提供数据和状态。而 Pigsty 就能为你提供这个套件。有了这套东西，一个开发者想做一个网站、一个门户、一个内部系统、一个数据应用，门槛会低很多。你真正要操心的，可能只剩两件事：买个域名，买台服务器，剩下的细节，可以交给 Agent。

30 文件系统也应该可回滚

我确实觉得这里面有一个非常有趣的功能值得一提，那就是时间旅行与环境共享。

JuiceFS 回滚

我们用 JuiceFS 做了一件事：把文件系统的状态也放进 PostgreSQL。这意味着——你的代码、配置、数据库内容现在共享同一个备份和回滚体系。Agent 搞砸了？一键 PITR，整个环境包括文件系统全部回到 5 分钟前。而且你还可以把这个文件系统挂载到 Linux、Windows 和 macOS 上，多人多设备共享一个目录。

这样的特性对于 Agent 来说极其实用。Agent 可以放心试错，搞砸了就用 PITR 回滚。这种以前属于 DBA 的“终极黑魔法”，现在开始走入寻常百姓家。这给了 Agent 可以大胆试错的底气。

第五部分：把身体交给社区

31 Pigsty 不只是 DBA Agent 的身体

到这里，我们可以把前面的东西收束成一句话：Pigsty 表面上是 PostgreSQL 发行版，本质上是一个 Agent Runtime。它把 Linux、PostgreSQL、监控、备份、高可用、IaC、CLI 和文档放在同一个确定性世界里。对 DBA Agent，它是生产现场；对 Dev Agent，它是开发环境；对 Coding Agent，它是可以试错、验证和回滚的执行环境。

Agent Runtime

32 一个开放的演武场，欢迎你上来

所以我很欢迎想做 Agent 的朋友来 Pigsty 里玩一玩——你可以把它当作一个演武场。这里有真实的 PostgreSQL，有真实的 Linux，有真实的监控，有真实的备份恢复，有真实的高可用，有真实的配置和管理入口。你没必要从零开始重复造轮子——要做 DBA Agent，要做 Dev Agent，都可以拿它当成一个方便的底座。

Pigsty 演武场

如果你是 Agent 开发者或用户，你不用从底层环境开始搭，只需要让你的 Claude Code、Codex 在这个环境里跑，让它沉淀对这套环境的认识，沉淀为记忆和 Skills。它会越来越熟悉环境，越来越有能力。

33 开源共享的运行时

在 Agent 时代，真正有价值的东西不是一段 Prompt，不是一个 Skills 文件，也不是某个看起来很聪明的聊天界面。那些东西都会被复制、被吸收、被快速抹平。真正难复制的，是一整套稳定、透明、可观测、可控制、可回滚的运行时环境。

这就是 Pigsty 想提供的东西：一个开源开放的 PostgreSQL Runtime，一个 Agent 可以真正进入、理解、操作、验证和积累经验的世界。它不是把 Agent 关在一个网页 Demo 里表演，而是把 Agent 放进真实的 Linux、真实的数据库、真实的监控、真实的备份、真实的高可用和真实的现场里验证。

未来不会只有一个 Agent，也不会只有一种正确答案；一定会有一百个、一千个不同方向的 Agent 长出来。它们都需要身体，都需要一个可以落地的环境，而 Pigsty 可以成为这副身体的骨架。

34 给 Agent 身体，也是在重塑人自己的位置

我们给 Agent 一个身体，不是为了把人替掉，而是为了解放生产力。DBA 不应该把时间浪费在重复安装、重复巡检、重复查指标、重复写脚本上；开发者也不应该把时间浪费在一遍遍配置数据库、配置 Nginx、配置监控、配置部署流程上。这些事情 Agent 可以做，而且会越做越好。

但这不等于人被替代。恰恰相反，越是 Agent 能干活，人越要往上走。人要定义目标，设计系统，判断风险，制定边界，承担责任。人不再是那个亲手拧每一颗螺丝的人，而是那个决定机器应该如何运转、出了问题谁来负责、哪些事情绝不能交给机器乱来的那个人。

模型会一代一代换，Agent 会一批一批退场；真正留下来的，是那些可复现、可审计、可回滚、可托付的运行时。Pigsty 想做的，就是这样一块地基。别只把它当成一个 PostgreSQL 发行版。把你的 Agent 放进一个可观察、可控制、可回滚的环境里，让它跑，让它试错，让它验证，让它长出真正能进入生产的身体。

谢谢大家。

9 - Pigsty Star 破 5000，一个人的 PG 发行版

原文发布于 VONNG。

今天 Pigsty 的 GitHub Star 数过了 5000。

图片

六年前写下第一行代码，四年前全职出来做，一路走到这里，确实不容易。

图片

在中国 PostgreSQL 开源生态里，Pigsty 是唯一一个跨过 5000 Star 的项目。 后面这些项目，背后都是大厂或者整建制的团队。老冯一个数据库个体户干到这个程度，还是可以小小自豪一把。

图片

在全球 PostgreSQL 发行版赛道里，当前格局是这样的：

  • CloudNativePG（EDB）：8478 ⭐
  • Zalando Postgres Operator：5145 ⭐
  • Pigsty：5002 ⭐
  • Stolon：4815 ⭐
  • Crunchy PGO：4396 ⭐
  • Autobase：4131 ⭐
  • ……

前两名都是 K8s 云原生路线。在 Linux 原生路线里，Pigsty 是 No.1。 第二名 Autobase 4131，在 Linux 原生 PG 发行版里，Pigsty 的 Star 是当仁不让的第一了。

图片

虽然顶上还有个 K8S 赛道的 CloudNativePG，但那不是我要去争的位置 ——能在 Linux 原生这一路上站稳 No.1，把 Debian/RPM 这个事实标准生态位拿下来，我就已经满足了。 一个人能跟 PG 世界的老大哥 EDB 去争第一，我觉得已经够刺激了。

5000 star 说少不算少，但 GitHub 上 Star 比它多的项目也不少。但对我来说，它意味着有 5000 个人在 GitHub 上按下了那个按钮——其中有素未谋面的 DBA、有在生产环境里跑着 Pigsty 的工程师、有把它当作学习素材的学生、也有一些我叫得出名字的老朋友。

图片

感谢每一位 stargazer。感谢那些提过 issue、发过 PR、写过博客、在群里回答过别人问题的贡献者。感谢各位客户的大力支持，感谢 MiraclePlus、Cloudflare、Vercel 在不同阶段给过的支持。也感谢 PostgreSQL 这个伟大的数据库本身 —— 没有它，就没有 Pigsty。

发布版本：微信公众号

10 - 把 Agent 的状态放进数据库

原文发布于 VONNG。

一年前，我写过一篇文章叫《PGFS：将数据库作为文件系统》。当时是为了解决 Odoo 社区的一个需求：将文件与 PostgreSQL 数据库一起做 PITR，回滚到指定时间点。

方案运行得还不错。它用纯软件的方式，实现了原本需要昂贵 CDP 专用硬件才能实现的功能，也就是让文件系统与数据库一起回滚到任意时间点。性能也行，对于 Odoo、Dify 这类应用绰绰有余。

但最近我发现，这个方案吸引了不少意想不到的用户。他们不是来做 ERP 的，而是来 存 AI Agent 状态 的。

把 Agent 的状态放进数据库

做法其实很简单：通过 PGFS，把 PG 数据库挂载成一个本地目录。读写这个目录，实际上就是在读写远程的数据库。然后把 AI Agent 的工作目录、配置文件、记忆数据全都放进去。

这让我意识到，PGFS 这个东西，可能比我最初想象的要有用得多。至少我知道，一家做 OpenClaw 商业发行版的公司，已经在用 PGFS 方案作为底层记忆共享机制了。

Agent 到底需不需要数据库？

在聊怎么做之前，先说说 “Why”。这是个被反复争论的问题。我的朋友蒋老板就经常跟我 Argue：AI Agent 不需要数据库，用个 SQLite 就行。

对于 To C 的本地单机单 Agent 场景，他说得也许没错。一个人用一个 Claude Code，状态就放在 .claude/ 目录下，Git 管好代码，没什么问题。在这种场景下拿 PG 来存储状态，确实有点拿着锤子找钉子的感觉。

但是，一旦场景稍微复杂一点，数据库就是不可避免的。 正如图灵奖得主、PG 祖师爷 Stonebraker 所说：这是 AI Agent 发展的必由之路。

什么叫“稍微复杂一点”？

多 Agent 协作。 你开始用并行的 Sub-Agents 来分工：一个负责写代码，一个负责写测试，一个负责审查。它们之间需要沟通任务状态、共享上下文。用 Markdown 文件做任务队列？能跑，但很脆弱。

从单人到团队。 你一个人 Vibe Coding 的时候无所谓，但当团队里有三五个人，每个人都有自己的 Agent 在干活，就需要一个地方来协调。当出现跨设备、跨个体、跨组织协作的时候，数据库就要比笔记本上的目录方便多了。

To B 场景。 企业级应用天然需要集中存储、审计、权限控制。你需要 CDP 能力，随时回滚到任意时间点，需要灵活地快照、分叉、共享，还要处理好并发争用与数据一致性。

To C 的终极形态。 现在你的 Agent 是跑在一台机器上，独占这个机器的环境。但如果你真的想实现类似 Jarvis 那样的愿景，也就是让 Agent 运行在你所有的设备上，提供统一的使用体验，那么这些 Agent 必然需要一个共享的记忆。

当复杂度开始升高，你早晚会开始使用数据库来解决这些问题。除非你准备在文件系统上重新发明一个蹩脚的数据库。

那么，数据库到底能给 AI Agent 提供什么独特的价值？

我认为有两个杀手锏。

杀手锏一：时光机

第一个，是 时间点恢复（Point-in-Time Recovery, PITR）。

在现有的 AI Agent 工作流里，如果 Agent 把事情搞砸了，是很难办的。特别是当 Agent 完全依赖文件系统和 Git 来管理状态时，你是个纯代码开发者，又构建了良好的 Git 工作流，能及时 commit 和 push，那还好说。但现实是，很多状态并不在 Git 里：Agent 的配置文件、中间产出、临时数据、工作记忆……这些东西一旦被误操作，就回不来了。

Claude 误删代码库的案例已经出现了，更不用说那些没有被版本管理的数据。

你可能会说：我可以用 Git 或者 ZFS 做快照。可以，但有两个问题。第一，快照是离散的时间点，你只能回到“上一个快照”，而不能回到“3 分 27 秒之前”那个精确的时刻，比如误删除发生的前一秒。第二，你得显式地管理这些快照：什么时候做、保留多久、怎么清理。这本身就是运维负担。

以前，想实现“回到任意时间点”这种能力，只有两条路：要么买昂贵的 CDP 硬件，要么自己实现一套复杂的日志系统。

PGFS 给了第三条路：把文件系统的所有写入都变成数据库的写入，借助 PostgreSQL 的 WAL 日志，天然获得 PITR 能力。

具体来说：当你往 PGFS 挂载的目录写文件时，数据实际上写进了 PG 的 jfs_blob 表里。文件操作和数据库操作共用同一套 WAL 日志。当你做 PITR 回滚时，数据库和文件系统会同时回到指定的时间点，精确到每个操作的微秒时间戳。

PGFS 让文件系统与数据库一起做 PITR

这意味着你的 Agent 拥有了一台时光机：不管它做了什么，你都可以把一切恢复到任意一个时间点。 代码、数据、配置、记忆，全部一起回滚，没有任何不一致。

这还带来了一个额外的能力：瞬间克隆与分支。因为代码状态本质上也是数据库里的数据，你可以基于某个时间点创建一个新的数据库实例，里面的文件状态和数据库状态完全一致。就像 Git 的 branch，但连数据库里的业务数据也一起分支了。让不同的 Agent 在不同的“分支”上工作，互不干扰。搞砸了？回滚。想试试另一条路？Fork 一个新环境。这是纯文件系统方案做不到的。

对于 AI Agent 来说，这个能力的价值怎么强调都不过分。它让你有了一个“无限撤销”的安全网，或者说，一个可以随时存档 / 读档的游戏存档系统。

杀手锏二：共享大脑

如果你只有一个人、一个 Agent，那确实不需要共享。但是当你开始用并行的 Agents、Sub-Agents 时，就需要一个高效沟通的地方。

目前的单机模式是怎么做的？在项目目录里写一个 Markdown 文件当 To-Do List，手动派发任务，让 Sub-Agent 去执行。一个人的时候勉强能跑。但如果用一张数据库表来记录任务，所有 Agent 都从里面取活、更新状态、上报结果，这就是一个天然的任务调度中心。不需要文件锁，不需要轮询，数据库的 MVCC 和 NOTIFY/LISTEN 天然解决并发问题。

更重要的是：文件目录很难简单地共享给其他人。 你可以用 FTP、NFS，但配置麻烦，安全性也是问题。

而 PGFS 的共享方式非常优雅。设想这样一个架构：

  1. 你有一台云服务器，上面运行着一套 Pigsty（包含 PostgreSQL）。
  2. 在上面创建一个 PGFS 挂载点，比如 /fs。
  3. 所有项目代码、Agent 配置、共享记忆，都放在这个目录下。
  4. 团队里的任何一个人，只要知道数据库连接串，就可以用一行命令把这个目录挂载到自己的本地机器。
通过 PGFS 共享工作空间

一行连接串，一行挂载命令，就可以让多个人、多台机器、多个 Agent 共享同一个工作空间。

我现在自己的工作方式就是这样：一个基于 Pigsty 的 Monorepo，所有项目都在里面。云服务器上可以直接用 Claude Code 干活，同时把云端的 PGFS 挂载到本地，实现本地读写。多平台、多实例、无缝同步。

可以每个人负责一个子项目，在一个整体 Repo 里面协作。

再往远了想：如果你真的想要一个 Jarvis 风格的数字管家，它肯定需要一个集中的地方来存储状态。你不能让每个 Agent 都有自己独立的记忆，否则你得到的不是一个助理，而是一群互不知情的虾兵蟹将。

多个 Agent 共享记忆，最自然的方式就是建一个中枢：云端一台虚拟机，跑一套 Pigsty，通过一个 URL 把数据库挂载到本地。每一个 Agent 都可以读写共享状态，同时保留各自的私有记忆。

多个 Agent 共享记忆

当然除了上面两点之外，还有很多其他的好处，ACID、高可用、可观测性、备份恢复、复制 / CDC 工具，这里就不一一展开了。

怎么做：Pigsty 的 JUICE 模块

说了这么多“为什么”，来说说“怎么做”。底层能力一年前就有了。当时我已经把 JuiceFS 打包到了 Pigsty 里。在 Pigsty 4.0 版本中，正式发布了 JUICE 模块，把整个流程做成了声明式配置，一键部署。

什么是 JuiceFS？

JuiceFS 是一款高性能的 POSIX 兼容分布式文件系统。架构很简洁：一个元数据引擎 + 一个数据存储后端。元数据引擎管理文件目录树和属性，数据存储后端存放文件内容。

PGFS 的核心设计就是：JuiceFS 支持用 PostgreSQL 同时作为元数据引擎和数据存储后端。 所有的文件元数据和文件内容都存在 PG 里，共享同一套 WAL 日志。（TimescaleDB 最近出了一个 TigerFS，提供类似功能，但成熟度偏低。我也已经打包整合了。）

声明式一键部署

在 Pigsty 的 vibe 配置模板中，就已经提供了一个配置好的例子。只要你在一台全新的 Linux 服务器上执行这几行命令，那么你在 /fs 这个目录上就已经拥有一个预先定义并挂载好的 PGFS 了。

curl -fsSL https://repo.pigsty.io/get | bash
cd ~/pigsty
./configure -c vibe -g   # 使用 vibe 模式，生成随机密码
./deploy.yml             # 部署基础设施和 PostgreSQL
./juice.yml              # 部署 JuiceFS 文件系统

你对这个默认定义的 /fs 目录下的所有文件读写都会落在数据库里，而你也可以将这个数据库同时挂载到其他目录，甚至是多个不同电脑上的本地目录，实现目录共享。而这一切都是通过一段简短配置定义的：

juice_instances:
  jfs:
    path: /fs
    meta: postgres://dbuser_meta:[email protected]:5432/meta
    data: --storage postgres --bucket 10.10.10.10:5432/meta \
      --access-key dbuser_meta --secret-key DBUser.Meta
    port: 9567

就这么简单。系统会自动完成 JuiceFS 的格式化、挂载、开机自启配置和监控集成。

你也可以轻松依葫芦画瓢定义多个 JuiceFS 实例，或者把同一个实例共享挂载到多台不同的机器上面去：

app:
  hosts:
    10.10.10.11: {}
    10.10.10.12: {}
  vars:
    juice_instances: {...}

最妙的是，不仅仅是这些 Linux 服务器可以共享挂载，对于 macOS 和 Windows 用户，你也可以把云端的 PGFS 挂载到本地：

juicefs mount "postgres://dbuser_meta:[email protected]:5432/meta" ~/work -d

一行连接串就是你的“共享云盘”入口。 比 NFS、FTP 简单太多。我最近准备弄一个一键配置脚本，在 macOS 和 Windows 上一次性配置好 JuiceFS，只需要填一个 URL，就可以立即把所有事情都配好。

当然，对于老司机来说，一看就知道怎么回事了：你只需要把 Claude Code、Codex、OpenClaw 在家目录下的 dot 目录移动到这个挂载上来的共享工作目录，然后软链接回原位，你的 Agent 状态就存储到数据库中了。

而且最棒的是，性能也还不错。和原生文件系统比，PGFS 的吞吐量肯定差一些。但实测数据并不差，文件读写大概在百 MB/s 上下的吞吐量，而且 JuiceFS 也有本地缓存机制，对于 Odoo、Coding Agent 之类的场景肯定是绰绰有余了。

当然，最棒的特性莫过于当 Agent 把你的环境搞砸了，你可以使用 PITR 一键回滚到任意时间点的黑魔法。

总结

回到最初的问题：AI Agent 到底需不需要数据库？

对于单人单机的简单场景，确实不一定需要，SQLite 也可能够了。但 Agent 的世界正在变得越来越复杂，多 Agent 协作、团队共享、状态持久化、容错回滚。这些需求一旦出现，数据库就不是可选项，而是基础设施。

PGFS 通过 Pigsty 的 JUICE 模块，给 AI Agent 提供了两个杀手锏能力：

  1. 时光机：基于 PITR 的任意时间点回滚，代码、数据、配置、记忆一起恢复。还能瞬间克隆和分支，让 Agent 在不同的“存档”上并行实验。
  2. 共享大脑：多 Agent、多人、多机器共享同一个工作空间和记忆。一行连接串，一行挂载命令。

这两个能力，是纯文件系统方案做不到的。以前实现这些需要几十万的 CDP 硬件。现在？一台云服务器，一套开源软件，四行命令，一分钱都不要。

这才是数据库在 AI 时代的正确打开方式。

11 - Pigsty 出海记：百万流量，“颗粒无收”？

原文发布于 VONNG。

过去一个月，pigsty.io 的流量翻了一个数量级。今天去 Cloudflare 上瞅了一眼仪表盘，给我看愣了。

Pigsty 文档站 Cloudflare 流量概览

UV（独立访客）：144 万，PV（页面浏览）：1811 万，流量：1.1 TB。

30 天，一个人维护的开源项目文档站。

我让 Claude 帮我分析了一下，它说这已经是一个中型 SaaS 产品的流量水平了。

Pigsty 流量水平分析

我寻思我也没做啥 SaaS 啊，我就搞了个数据库发行版，还是本地部署的。

一个文档站，哪来这么多流量？

从国家分布看，美国排第一，1398 万请求，遥遥领先；第二名是越南，303 万。然后是英国、法国、新加坡、德国……中国开发者做的开源项目，中国流量只排第六。覆盖了 177 个国家和地区，而联合国成员国一共才 193 个。

以及，我也不知道越南的朋友们为什么这么热情，最近 LinkedIn 上好几个越南人加我（笑）。

没放广告，血亏

Claude 顺手又帮我算了一笔账。按这个流量规模，如果挂个 Google AdSense，保守估计每个月也能有 5000 到 10000 美元的广告收入。如果直接找数据库厂商谈赞助位，可能还得再翻几倍。

Pigsty 流量潜在广告收入估算

然而我一个广告都没放，一个弹窗都没有。144 万人来了又走了，一分钱没赚到。

哦对了，以上统计还只是国际站 pigsty.io 的数据。国内还有一个走 pigsty.cc 的站点，用的是国内 CDN，流量还没算进来呢。

不过老冯也习惯了。像我这个公众号，应该算数据库个人号里的头部了，每天后台 99+ 条消息写着“商务合作”，老冯至今还是一条商单都没接过。

GitHub 的另一个故事

当然，Cloudflare 的流量里肯定有不少机器人爬虫。但即便只有十分之一是真人，对于一个开源项目来说，也已经远超我的预期。

而且流量只是一个侧面。在 GitHub 上，Pigsty 最近的增长也很亮眼，星标马上就要破 5000 了。

Pigsty GitHub Star 增长趋势

在 PostgreSQL 发行版这个赛道上，Pigsty 目前排第三。照这个势头，用不了多久应该就能冲到第二。当前的第一名是 EDB 的 CloudNativePG。不过我们俩的生态位正好错开：它做 Kubernetes 云原生，我做 Linux 原生，各占一个赛道的头部位置。

PostgreSQL 发行版项目排名

区别在于，EDB 是 PostgreSQL 世界的老大哥，CloudNativePG 背后是十几个核心开发者加上一百多号贡献者。

而 Pigsty 这边，就我一个人。字面意义上的 数据库个体户。现在时髦一点的说法，叫 OPC（One Person Company）。

一个人能走多远

放在整个中国 PostgreSQL 生态里看，Pigsty 应该算目前国内厂商和开发者中，国际影响力最高的开源项目了。GitHub 星标比阿里、华为、腾讯搞的那几个 PG 改内核项目都高出一圈。

中国 PostgreSQL 相关项目对比中国 PostgreSQL 项目 Star 对比

一个人 solo 到这个位置，确实有点魔幻。

再过几周，就是我出来创业整整四年了。四年以来，一个人开始做 Pigsty。技术、产品、文档、营销、销售、咨询、交付，全部自己来。自己动手，丰衣足食。

说实话，这一路走过来，挺不容易的。但还好赶上了 AI 的浪潮。过去这一两年，AI 让一个人干完一个团队的活变成了可能。OPC，确实赶上了好时代。

此刻的状态

我觉得现在这个状态就挺好的。

咨询生意稳定增长，轻松覆盖开支，客户零流失。全球用户在自然增长，也没有融资的焦虑，没有 KPI 的压力，没有老板，没有早会。

写想写的代码，做想做的产品，服务值得服务的客户。

四年，从一个自己做给自己用的小项目，到用户覆盖 177 个国家和地区。但我觉得，这件事本身说明了一些什么：

把一件事做到极致，世界自己会来找你。

不需要团队，不需要营销预算。把东西做好，放在那里，等风来。但行好事，莫问前程。

开源就是这样。你把最好的东西免费送给世界，世界会用它自己的方式回报你。这个回报可能不是钱，但它是一种更珍贵的东西：信任。

来自 177 个国家和地区的用户访问

来自全世界 177 个国家和地区用户的信任。

这比什么广告费都值钱。

12 - PG 扩展百科全书：中英双语，开箱即用

原文发布于 VONNG。

扩展目录：中文站 · 英文站

扩展是 PostgreSQL 的灵魂。没有扩展的 PostgreSQL，只是一个普通的关系型数据库；有了扩展的 PostgreSQL，才是那个能吞噬整个数据库世界的超级平台。

但长期以来，PG 扩展生态一直面临一个尴尬的问题：找不到、看不懂、装不上。你想用一个扩展，得先去 GitHub 翻 README，再去 PGXN 碰运气看有没有包，然后对着不同操作系统的包管理器折腾半天。运气好装上了，运气不好，编译失败、依赖缺失、版本不兼容，一下午就没了。

所以我做了一件事：把 PostgreSQL 生态里收录的 464 个扩展，每一个都做成一张完整的“身份证”，整理成一个中英双语的扩展百科全书。当然，它不只是百科全书，还是一套真正可交付的二进制仓库。我们提供 14 个 Linux 平台、最近 5 个 PG 大版本的 RPM / DEB 软件包，做到真正的开箱即用。

PG 扩展百科全书首页

这不是一个列表，而是一本百科全书

市面上不缺 PostgreSQL 扩展列表。PGXN 有一个，各种 Awesome List 也一大堆。但它们通常只给你一个名字和一句话简介。你想进一步知道这个扩展用什么语言写、用什么许可证、支持哪些 PG 版本、在你的操作系统上有没有预编译包、怎么安装、有没有冲突扩展，往往还是得自己去折腾。

我做的这个目录不一样。点进任意扩展详情页，你能直接看到：

  • 基础元数据：版本号、所属分类、开源许可证、开发语言、GitHub 仓库、源码下载地址。
  • 扩展属性：是否需要预加载、是否包含 DDL、是否支持 CREATE EXTENSION、是否 trusted、是否可 relocate、默认安装到哪个 schema。
  • 版本与构建信息：当前收录版本、支持的 PG 大版本、RPM 包名、DEB 包名。
  • 全平台下载矩阵：14 个操作系统与架构组合下，对应的包、下载链接和包大小。
  • 安装命令：针对 pig、dnf、apt 三种方式，给出可直接复制粘贴的完整命令。
  • 关联关系：相关扩展、依赖扩展、冲突扩展一目了然。
扩展详情页

此外，我们还收录了 460+ 扩展文档，让你可以在一个地方直接浏览大量 PG 扩展的双语文档，而不是在分散的页面之间来回跳转。

扩展文档总览

464 个扩展，16 个分类

这 464 个扩展按功能被分成了 16 个大类。如果你之前听说过 PostgreSQL 可以做时序数据库、向量数据库、图数据库、文档数据库，甚至兼容 Oracle 和 SQL Server，那么现在你可以在同一个目录里把这些能力背后的扩展全部找出来，看到详细信息，再一行命令装上。

扩展分类总览

多维度浏览

除了按分类浏览，你还可以从不同维度切入这个目录。

按归属仓库

每个扩展归属于 PGDG、PIGSTY 或 CONTRIB 三类来源之一。PGDG 是 PostgreSQL 官方社区仓库，CONTRIB 是 PostgreSQL 自带扩展，而 PIGSTY 则是我额外打包收录和维护的部分。

按仓库来源浏览扩展

按编程语言

你可以看到这些扩展分别是用 C、C++、Rust、Java、Python、SQL 还是纯数据文件实现的。尤其是近两年 Rust 扩展的增长趋势，在这里看得非常直观。

按开发语言浏览扩展

按开源协议

MIT、Apache 2.0、PostgreSQL、BSD、GPL、AGPL、Timescale License，不同协议对商业使用的影响各不相同，在技术选型时非常值得关注。

按许可证浏览扩展

按扩展属性

哪些扩展需要修改 shared_preload_libraries 重启才能用？哪些是没有 SQL DDL 的“无头扩展”？哪些扩展之间有依赖或冲突？哪些包里包含多个扩展？这些都能在目录中直接看清楚。

按扩展属性浏览

按操作系统

在特定操作系统和 CPU 架构组合下，哪些扩展可用、哪些不可用、版本分别是多少，一张表就能说明白。

按平台矩阵浏览扩展

三件套：目录 + 仓库 + 包管理器

光有元数据目录还不够，配套基础设施同样重要。这次重做扩展目录，其实是一个系统性工程的一部分，整套体系包含三样东西：

  • 扩展目录：告诉你有什么、能不能用、怎么用。
  • 扩展仓库：提供预编译好的 RPM / DEB 二进制包，通过 CDN 分发，不必自己编译。
  • 包管理器 pig：屏蔽不同操作系统和 PG 版本的差异，一行命令完成安装。

这三样东西配合起来，把“找扩展、选扩展、装扩展、用扩展”的完整链路打通了。

一些数字

下面是这套扩展百科全书和配套仓库的一些统计数据。

扩展总量统计文档覆盖统计平台覆盖统计软件包分发统计

为什么要做这件事

做这个扩展目录，表面上是在做一个文档网站，实际上是在做 PostgreSQL 扩展生态的基础设施。

PostgreSQL 扩展生态的现状长期是“有酒无杯”：好东西很多，但发现、安装、使用的门槛太高。一个 DBA 想用 pgvector 做向量检索，或者用 pg_duckdb 跑 OLAP，他首先得知道这个扩展存在，然后得确认自己的操作系统上有没有包，再去处理各种编译、依赖和版本问题。这个过程中任何一环断掉，他都可能直接转头去用别的方案。

我想做的是把这个门槛降到最低：来这里看看有什么，挑你要的，复制一行命令，装上就能用。

每个扩展详情页，都是一个完整的 one-stop shop。你不需要再去 GitHub 翻 README，不需要去 PGXN 找包，也不需要猜操作系统兼容性。所有信息汇聚在一个页面里，中英双语，对国内外用户同样友好。

怎么用

如果你本来就会折腾 PostgreSQL，只是想在 PGDG 仓库之外额外安装一些“官方仓库”没有的扩展，那么直接添加 Pigsty 的 APT / DNF 仓库即可。pig 包管理器可以把这个过程大幅简化，但它并不是强制依赖。

curl -fsSL https://repo.pigsty.cc/pig | bash
pig repo add pigsty pgdg -u
pig install <extension>

如果你压根不想操心这些细节，也可以直接使用 Pigsty PostgreSQL 发行版。它的 rich 模板已经默认准备好了绝大多数常用扩展，你只需要按需启用即可。

curl -fsSL https://repo.pigsty.cc/get | bash
cd ~/pigsty
./configure -c rich
./deploy.yml

完全开源

顺便一提，这个网站和扩展元数据本身也是完全开源的。如果你想自己保存一份副本，或者复用这套数据，直接去 pgsty/pgext 仓库就可以了，省得再自己写爬虫解析。如果你发现了扩展信息、元数据或文档中的错误，也欢迎直接提交 Issue 或 Pull Request。

扩展元数据与网站仓库

附：Extension for Everyone

原稿末尾还附了一张相关主题演讲的海报，这里一并保留下来。

Extension for Everyone 主题海报

小结

扩展是 PostgreSQL 的灵魂，而这个目录，就是灵魂的索引。

464 个扩展，16 个分类，14 个操作系统，5 个大版本；中英双语；元数据、下载链接、安装命令、使用说明汇于一处。这件事的目标很简单：让 PostgreSQL 的扩展生态更容易被发现、更容易被安装，也更容易真正用起来。

如果你发现了有趣的扩展，或者对这套目录和仓库有任何建议，欢迎告诉我。

13 - Pigsty v4.2：12内核齐开花

原文发布于 VONNG。

GitHub Release | 发布注记

Pigsty v4.2 正式发布，紧随 PostgreSQL 紧急号外小版本更新。

本次更新同时交付了三款全新 PG 内核 —— 图数据库 AgensGraph、多写分布式 pgEdge、MPP 数仓 Cloudberry —— 并重建了 Babelfish、OrioleDB、OpenHalo 三款既有内核。至此，Pigsty 支持的内核总数达到了 12 个。

你可以用一份配置文件，把所有这些不同风味的 PostgreSQL 部署为自带监控、高可用、时间点恢复与 IaC 的企业级数据库服务。这大概就是 “Meta PG 发行版” 的含义。

内核大观园

PostgreSQL 以极致的可扩展性闻名。生态中有超过 1000 个扩展，Pigsty 则提供了其中 461 个开箱即用。

但有些能力是扩展做不到的 —— 比如 定制语法。如果你想在 PostgreSQL 里原生使用 Oracle 的 PL/SQL、SQL Server 的 T-SQL、MongoDB 的 BSON 协议、或者 Cypher 图查询语法，而不是通过函数调用来模拟，那你就需要修改内核。这也是为什么 Pigsty 不仅提供生态中数量最多的扩展，还要支持不同的内核分支。

在 Pigsty 里使用这些内核，和使用原版 PostgreSQL 几乎没有区别 —— 同样的部署流程、同样的监控面板、同样的高可用机制、同样的备份恢复。区别只是配置文件里改一个 pg_mode 的值。一行配置的差异，工程上的大一统。

内核 pg_mode 定位 PG 基线
PostgreSQL pgsql 原版内核 + 461 扩展 14 ~ 18
Babelfish mssql SQL Server 兼容（T-SQL / TDS） 17
IvorySQL ivory Oracle 兼容（PL/iSQL） 18
OrioleDB oriole 新存储引擎，解决 MVCC 膨胀 17
pgEdge pgedge 多主分布式复制 17
Percona TDE tde 透明数据加密 17
AgensGraph agens 图数据库（Cypher） 16
OpenHalo halo MySQL 协议兼容 14
Cloudberry gpsql MPP 分析型数仓 14
PolarDB polar 共享存储架构 15
Citus citus 分布式 HTAP 17
Ferret / DocumentDB mongo MongoDB 协议兼容 17

十二内核，一份配置。下面逐个展开。

原生 PostgreSQL

这次 PostgreSQL 的小版本更新值得单独提一下。

18.2 系列引入了 substring 与 WAL 回放相关的回归问题 —— 修漏洞的时候带进了新 bug。社区反应很快，两周后紧急发布了 18.3 / 17.9 / 16.13 / 15.17 / 14.22 补丁版本。Pigsty 的做法还是老规矩 —— 新版本发布次日，离线安装包就绪、所有扩展重新编译验证、文档同步更新。你要做的就是一行命令的事。

扩展总数也顺势推到了 461 个。

如果你追求极致的可扩展性和最佳的稳定性，原生 PostgreSQL 始终是最佳默认选择。Pigsty 支持处于生命周期内的 PG 14 到 PG 18。值得一提的是，本版本是最后一个支持 PG 13 的版本，后续最低版本将升至 PG 14。

pgEdge：原生多主复制

pgEdge 是本次新增的重量级选手。

传统 PostgreSQL 高可用是一主多从 —— 写操作只能发往主节点。pgEdge 的核心扩展 Spock 打破了这个限制：集群中的每个节点都可以读写，数据通过逻辑复制在节点间异步同步，冲突通过可配置策略自动解决。

严格来说，pgEdge 不是一个全新的内核，而是基于标准 PostgreSQL + Spock 扩展的多主方案。但由于多主复制的一些底层能力需要内核补丁（这些 Patch 尚未合并到 PostgreSQL 主干），它目前不得不以"Patch 内核 + 扩展"的方式发布。这一点和 OrioleDB、Percona TDE 类似 —— 如果 PostgreSQL 主干未来合并了这些 Patch，它们都可以转变为纯扩展形态工作，这是非常值得期待的趋势。

我很看好这个项目。pgEdge 团队有几位 PostgreSQL 社区的内核老将，技术功底很扎实。关于它的开源历程也值得一说：之前它使用的是类似 Confluent 风格的 Source Available 协议（pgEdge Community License），严格来说不算开源。但 2025 年 9 月，它全面转向了 PostgreSQL License。

不过有个细节需要注意：源代码遵循 PostgreSQL 协议，但官方提供的二进制包依然受商业许可约束。具体来说，开发环境可以免费使用，但生产环境必须付费订阅。

老冯直接基于 PostgreSQL 协议的源码自行打包 —— 制作了带 Patch 的 PostgreSQL 内核包，并在 Pigsty 支持的全部主流操作系统上完成适配。没有外部依赖，从 Pigsty 仓库直接装就行，不存在生产环境的许可问题。当然，如果你想用他们的云服务和商业支持，也欢迎去打钱支持一下。

pgEdge 由三个核心扩展组成：

  • Spock 5.0.5：多主逻辑复制引擎，每个节点同时处理读写
  • Lolor 1.2.2：大对象逻辑复制
  • Snowflake 2.4：分布式序列号生成

冲突解决方面，pgEdge 提供了多种策略：最简单的"最后写入获胜"（LWW）、专门的 CRDT 方案、冲突日志表、以及用户自定义策略。如果你有全球地理分布的需求 —— 比如北京、法兰克福、弗吉尼亚各放一个节点，用户就近读写 —— 这种多主模式非常合适。它相当于在 PostgreSQL 生态里原生提供了类似 CockroachDB / TiDB 的多写能力，只不过底座还是那个你熟悉的 PostgreSQL。

在 Pigsty 中使用只需要：configure -c pgedge。

AgensGraph：图数据库

AgensGraph 的定位是基于 PostgreSQL 的多模型图数据库 —— 在一个引擎内同时原生支持关系模型和属性图模型，而不是像 Neo4j 那样另起炉灶。这是由韩国 Bitnine 团队发起主导的项目。

有人会问：PostgreSQL 生态里不是有 Apache AGE 这个图扩展吗？为什么还要做 fork 内核？

这里有个有意思的渊源：AGE 和 AgensGraph 其实是同一个团队做的。最初他们做的是 AgensGraph 这个内核 fork，大概 1000 多个 Star。后来他们尝试以扩展形式实现类似功能，做了 AGE 并捐献给 Apache。结果扩展形式反而更受欢迎，拿到了 4000 多个 Star。AGE 虽然去年经历了一阵维护风波，但最近已恢复更新，发布了针对 PG 17/18 的 1.7.0 版本。

那 fork 版本还有什么存在价值？至少四个方面：

一是原生语法。在 AGE 里，你需要用函数调用来执行 Cypher 查询（把查询字符串传进去）；而在 AgensGraph 里，你可以直接写 CREATE GRAPH，Cypher 是一等公民语法。

二是存储优化。它的存储引擎针对图属性做了专门优化，理论上性能更好（虽然我还没实际 bench 过）。

三是查询优化统一。Cypher、JSON、SQL 三种查询语言在优化器层面是统一处理的，这种原生实现方式很有意思。

四是向量兼容。AgensGraph 最近宣称支持了 pgvector 兼容，意味着可以在同一个库里做 Graph RAG —— 图 + 向量的组合检索。这是当下非常火的前沿方向。这个专门的 vector 插件我还没打包进来，后面可能会补上。

当然，fork 路径的代价也很明显：版本跟进 PG 主线的难度很高。目前 PG 已经到 18 了，AgensGraph 还是基于 PG 16。这始终是 fork 方案的宿命，要落后一两个大版本。

在 Pigsty 中使用：configure -c agens。

Cloudberry：MPP 数仓

Cloudberry 是本次新增的第三款内核。它是一个 Apache 项目，由 HashData 团队主导，本质上是 Greenplum 7 的 fork —— 但做了不少改进，比如内核从 Greenplum 的 PG 12 升级到了 PG 14，补上了不少好用的新特性。

Cloudberry 2.0 发布后就不再提供官方二进制包了 —— 之前 1.6 还有 RPM，现在也没了。我等了几个月没见到官方有计划解决这个问题，就决定在 Claude 的帮助下自己动手。打包过程整体顺利，只是在个别较新的操作系统上需要改些代码、打几个补丁。之前只有 RPM，现在 DEB 也有了，Pigsty 支持的 14 个 Linux 发行版上全部可用。

关于 Cloudberry/Greenplum 的部署脚本和监控方案，其实早在 Pigsty v1.4 就做过，后来因为用户太少就去掉了。毕竟上 MPP 数仓的体量不是一般公司能达到的。所以我们思忖再三，先将其作为 Beta 模块按需提供 —— 包已经打好放在仓库里了，你可以直接下载使用；完整的部署剧本会在后续版本中择机提供。

Babelfish：SQL Server 兼容

说完三个新增内核，再来聊三个 重建 的内核。

Babelfish 是 AWS 开源的 SQL Server 兼容层 —— 让 PostgreSQL 理解 T-SQL 语法和 TDS 协议，你的 SQL Server 应用不改驱动、不改大部分查询，就能连上 PostgreSQL 跑起来。好项目，但打包构建实在是复杂，复杂到专门有一个开源项目 WiltonDB 就是干这件事的。

老冯之前偷懒，直接用了 WiltonDB 打的包。说实话，那个包的质量一直让我不太舒服：不支持 Debian 全系列和 EL10，依赖体系跟标准 PG 不一样，而且版本还停留在 PG15 —— 但 Babelfish 上游都已经支持 PG17 了。

这次一不做二不休，自己打。有了前面几个内核的打包经验，这个反而简单了 —— 把 Babelfish 的四个核心扩展打成一个包，配合一个 Patch 内核包，开箱即用。现在 不再依赖外部 WiltonDB 仓库，直接从 Pigsty 仓库安装即可。版本升级到了 Babelfish 5.5 + PG17。

在 Pigsty 中使用：configure -c mssql。

OrioleDB：新存储引擎

OrioleDB 是被 Supabase 收购的新一代 PostgreSQL 存储引擎项目，目标是从根本上解决 MVCC 膨胀问题 —— 用 Undo Log 替代传统的 Dead Tuple + VACUUM 机制。

本次重建升级到了 OrioleDB Beta14，基于 OriolePG 17.16 构建。新版本的一个重要进展是支持了 PITR 增量备份恢复能力。仍处于 Beta 阶段，不建议关键生产环境使用。但作为 PostgreSQL 存储引擎的未来演进方向之一，值得持续关注和实验。

在 Pigsty 中使用：configure -c oriole。

OpenHalo：MySQL 协议兼容

OpenHalo 是重建的第三个内核。它提供了 MySQL 线缆协议兼容 —— 你可以同时用 MySQL 客户端和 PG 客户端读写同一个数据库，这个能力非常有意思。

由易景羲和团队开发，是少数几家踏踏实实做事、并且愿意把成果开源出来的国产数据库公司，很难得。

这次更新的变化：

  • 版本从 PG 14.10 升级到 PG 14.18
  • 版本号正式更新为 1.0，按照 Pigsty 打包规范重新调整了命名

虽然基线版本是 PG14，稍显陈旧，但在 MySQL 迁移场景下确实是一个值得考虑的选择。

在 Pigsty 中使用：configure -c mysql。

其余六位常驻选手

除了本次新增和重建的六款内核，Pigsty 还有六位一直在的"常驻选手"：

IvorySQL（pg_mode: ivory）—— 瀚高出品的 Oracle PL/SQL 兼容内核，目前基于 PG 18.1。

Percona TDE（pg_mode: tde）—— 透明数据加密，满足合规场景中"落盘加密"的刚需。更新节奏稍慢于 PG 主线，后续会跟进到最新版本。

PolarDB（pg_mode: polar）—— 阿里开源的共享存储架构 PG 内核，更新了小版本。值得一提的是，本版本中我们已经 去掉了带信创资质的 PolarDB-O 的支持，开源版只保留社区 PG 版本。

Citus（pg_mode: citus）—— 微软出品的分布式扩展，正式发布 14.0.0 版本，支持 PG 18。

Ferret / DocumentDB（pg_mode: mongo）—— MongoDB 协议兼容方案，让你用 MongoDB 驱动直连 PostgreSQL。

Supabase 自建模板也例行升级到了最新版本。

一份配置，十核齐飞

说了这么多内核，最好玩的事情其实是这个：我们做了一个 demo/kernels.yml 配置文件 —— 如果你有 10 台虚拟机，可以用这个模板 一键拉起 10 个不同的 PG 内核。

每个集群都有独立的监控面板、高可用、备份恢复，就像管理 10 个标准 PostgreSQL 一样。纯属炫技，但也是一个很好的参考模板：如果你想在一套 Pigsty 里混合部署多种内核，具体该怎么配置。

这不是 PPT 上的架构图，是跑得起来的代码。

正名：企业级

眼尖的朋友可能已经发现，网站首页的 Slogan 换了。

以前叫 “Battery-Included，Local-First FLOSS RDS”，现在改成了：“开箱即用的企业级开源 PostgreSQL 发行版，自带高可用、PITR、IaC 监控与 461 个扩展”。

先澄清一件事：这不是说 Pigsty 的质量刚刚才达到"企业级"。实际上，Pigsty 从很早就在生产环境中被各行各业的企业使用了 —— 金融、政务、制造、互联网，靠的是 Patroni + pgBackRest + 可观测性这套经过实战检验的组合。有些所谓的"企业级方案"，论高可用不比 Patroni 强，论备份恢复不比 pgBackRest 好，监控系统更是一塌糊涂。能力一直在，只是之前我不太愿意给自己贴这个标签。

为什么？因为老冯一直觉得"企业级"这个词听起来比"云"还古老，甚至带有一种"传统杀猪盘二次方"的气质。所以宁可叫"Battery-Included"、叫"FLOSS RDS"，也不愿意把这个词放上去。后来我想明白了：不应该因为这个词被别人用烂了，就回避一个本来属于自己的描述。Pigsty 的高可用、备份恢复、监控告警、安全加固、合规能力，每一项都经得起和商业方案正面对比。实力到了，该戴的帽子就戴上，不亏心。

另一个变化是 去掉了"RDS 替代" 的说法。以前叫自己"开源 RDS 替代"，是一种借力定位——用人们熟悉的品类锚点来解释"Pigsty 是什么"。但到了今天，我们有信心说：不需要用别人来定义自己。Pigsty 就是 Pigsty，一个企业级的 PostgreSQL 发行版。在 PostgreSQL 发行版的赛道上 —— Linux 原生这条路线里 —— Pigsty 就是最能打的。

其他改进

除了内核大戏，v4.2 还有一些值得注意的工程改进：

Redis 目录规范化：默认目录从 /data 调整为 /data/redis。存量配置如果还用 /data，需要先改过来再升级，部署阶段会阻止旧路径继续使用。

Configure 脚本优化：支持 -o 绝对路径输出并自动建目录；区域探测改为三态（境内/境外/离线回退），修复了 behind_gfw() 卡住的问题。

pgBackRest 初始化容错：stanza-create 增加重试（2 次、间隔 5 秒），缓解与 archive-push 的锁竞争。踩过这个坑的人知道它有多烦。

Supabase 应用栈升级：PostgREST 14.5、Vector 0.53.0，S3 访问密钥变量补齐。

Vibe 模板更新：内置 @anthropic-ai/claude-code、@openai/codex、happy-coder 等工具，AI 编码沙箱开箱即用。

基础设施例行升级：Grafana 12.4、Prometheus 3.10、VictoriaMetrics 1.136、etcd 3.6.8、Kafka 4.2 等。注意 Grafana 12.4 有 data link 合并行为变化，自定义面板需检查。

首页改版：之前用 Claude Code 糊了一版，有人反映太丑了，批评得很有道理。这次让 Codex 重新优化了一轮，好看不少。后面有空会继续打磨。

后续展望

Pigsty 作为开源项目，我觉得已经达到了相当完善的程度。后续的工作重心会逐渐转向子项目：

Pig CLI 最近更新了很多强大功能 —— 把 PostgreSQL、Patroni、PgBouncer、pgBackRest 的管理全部封装成了命令行工具，方便 Claude Code 这样的 DBA Agent 调用。这种同时为人类 DBA 和 AI Agent 设计的命令行工具，我称之为 Agent-Native CLI。

DBA Agent 方面，最近写了一些 Claude Skills 和提示词模板，让 Pigsty 环境可以被 AI 工具感知。这样你就可以把 Claude Code 放进 Pigsty 环境里，让它帮你干活。

Pigsty 本身会继续跟着 PG 小版本的节奏走。下个版本可能会正式补上 Cloudberry 的部署剧本，加上本地 SMTP 服务器支持（maddy / stalwart）。大的新功能暂时不急 —— 当前这个架构持续稳定地跑下去，就挺好。

v4.2.0 提交注记

亮点特性

  • 离线小版本跟进 PostgreSQL 紧急小版本：18.3、17.9、16.13、15.17、14.22。
  • PostgreSQL 扩展总数达到 461 个。
  • PG 内核更新：Babelfish、AgensGraph、pgEdge、OriolePG、OpenHalo、Cloudberry。
  • Babelfish 模板切换到 Pigsty 自建维护的 PG17 兼容版本，移除对 WiltonDB 仓库的依赖。
  • 更新 Supabase 镜像与自建模板至最新版本，使用自行维护的 MinIO 分支 pgsty/minio

主要变更

  • mssql 模板切换到 Babelfish PG17 默认：pg_version: 17，pg_packages: [babelfish, pgsql-common, sqlcmd]，并移除额外 mssql repo 依赖。
  • pg_home_map 调整：mssql 指向 /usr/babelfish-$v/，gpsql 指向 /usr/local/cloudberry，统一内核路径语义。
  • package_map 新增 cloudberry 独立映射，并修复 babelfish* 组件别名到版本化包名（RPM/DEB）。
  • Redis 默认主目录从 /data 调整为 /data/redis；部署阶段阻止旧默认值继续使用，redis_remove 增加旧路径兼容清理。
  • configure 支持 -o 绝对路径输出并自动建目录；区域探测改为三态（境内/境外/离线回退），修复 behind_gfw() 卡住问题。
  • 修复 Debian/Ubuntu 默认仓库 URL（updates/backports/security 对应关系）与中国区镜像组件字段，避免节点初始化拉包失败。
  • Supabase 应用栈例行升级（含 PostgREST 14.5、Vector 0.53.0 等）并补齐 S3 协议访问密钥变量。
  • Rich/Sample 模板显式补全 dbuser_meta 默认值；node.sh 中 systemd 自动补全逻辑简化。
  • pgbackrest 初始化增加重试（2 次、间隔 5 秒），缓解 stanza-create 与 archive-push 锁竞争失败。
  • Vibe 模板更新：内置 @anthropic-ai/claude-code、@openai/codex、happy-coder 等 npm 工具，默认示例补入 age 扩展。

PG 软件更新

  • PostgreSQL 18.3, 17.9, 16.13, 15.17, 14.22
  • RPM Changelog 2026-02-27
  • DEB Changelog 2026-02-27
  • 核心升级：timescaledb 2.25.0 -> 2.25.1，citus 14.0.0-3 -> 14.0.0-4，pg_search -> 0.21.9
  • 新增/重建：pgedge 17.9，spock 5.0.5，lolor 1.2.2，snowflake 2.4，babelfish 5.5.0，cloudberry 2.0.0
  • 内核配套：oriolepg 17.11 -> 17.16，orioledb beta12 -> beta14，openhalo 14.10 -> 1.0(14.18)
包名 旧版本 新版本 备注
timescaledb 2.25.0 2.25.1
citus 14.0.0-3 14.0.0-4 使用最新官方版本重新构建
age 1.7.0 1.7.0 新增 PG 17 的 1.7.0 版本支持
pgmq 1.10.0 1.10.1 当前没有该扩展包
pg_search 0.21.7 / 0.21.6 0.21.9 RPM/DEB 旧版本不同
oriolepg 17.11 17.16 OriolePG 内核更新
orioledb beta12 beta14 配套 OriolePG 17.16
openhalo 14.10 1.0 更新并重命名，14.18
pgedge - 17.9 新增多主边缘分布式内核
spock - 5.0.5 新增，pgEdge 核心扩展
lolor - 1.2.2 新增，pgEdge 核心扩展
snowflake - 2.4 新增，pgEdge 核心扩展
babelfishpg - 5.5.0 新增 BabelfishPG 包组
babelfish - 5.5.0 新增 Babelfish 兼容包
antlr4-runtime413 - 4.13 新增 Babelfish 依赖运行时
cloudberry - 2.0.0 仅 RPM 构建
pg_background - 1.8 仅 DEB 构建

基础设施软件更新

名称 旧版本 新版本
grafana 12.3.2 12.4.0
prometheus 3.9.1 3.10.0
mongodb_exporter 0.47.2 0.49.0
victoria-metrics 1.135.0 1.136.0
victoria-metrics-cluster 1.135.0 1.136.0
vmutils 1.135.0 1.136.0
victoria-logs 1.45.0 1.47.0
vlagent 1.45.0 1.47.0
vlogscli 1.45.0 1.47.0
loki 3.6.5 3.6.7
promtail 3.6.5 3.6.7
logcli 3.6.5 3.6.7
grafana-victorialogs-ds 0.24.1 0.26.2
grafana-victoriametrics-ds 0.21.0 0.23.1
grafana-infinity-ds 3.7.0 3.7.2
redis_exporter 1.80.2 1.81.0
etcd 3.6.7 3.6.8
dblab 0.34.2 0.34.3
tigerbeetle 0.16.72 0.16.74
seaweedfs 4.09 4.13
rustfs 1.0.0-alpha.82 1.0.0-alpha.83
uv 0.10.0 0.10.4
kafka 4.1.1 4.2.0
npgsqlrest 3.7.0 3.10.0
postgrest 14.4 14.5
caddy 2.10.2 2.11.1
rclone 1.73.0 1.73.1
pev2 1.20.1 1.20.2
genai-toolbox 0.25.0 0.27.0
opencode 1.1.59 1.2.15
claude 2.1.37 2.1.59
codex 0.104.0 0.105.0
code 1.109.2 1.109.4
code-server 4.108.2 4.109.2
nodejs 24.13.1 24.14.0
pig 1.1.2 1.3.0
stalwart - 0.15.5
maddy - 0.8.2

API 变化

  • pg_mode 增加 agens 与 pgedge。
  • mssql 默认配置改为 pg_version: 17 + pg_packages: [babelfish, pgsql-common, sqlcmd]。
  • pg_home_map 与 package_map 的内核/包别名映射更新（Babelfish / OpenHalo / IvorySQL / Cloudberry / pgEdge 家族）。
  • redis_fs_main 默认值改为 /data/redis，并新增部署保护与移除兼容策略。
  • configure 输出路径与区域探测逻辑更新，增加离线回退告警；SSH 探测统一超时参数。
  • grafana.ini.j2 跟进 Grafana 12.4 新配置项与废弃项调整。

兼容性说明

  • 存量 Redis 配置如果仍使用 redis_fs_main: /data，请先改为 /data/redis 再执行部署。
  • Grafana 12.4 后 data link 合并行为变化，本版本已将关键链接下沉到字段 override 规避冲突；如有自定义看板，建议同步检查。

26 个提交，122 文件变更，+2,116 / -2,215 行（v4.1.0..v4.2.0，2026-02-15 ~ 2026-02-28）

校验和 

24a90427a7e7351ca1a43a7d53289970  pigsty-v4.2.0.tgz
d980edf5eeb0419d4f1aa7feb0100e14  pigsty-pkg-v4.2.0.d12.aarch64.tgz
24bc237d841457fbdcc899e1d0a3f87e  pigsty-pkg-v4.2.0.d12.x86_64.tgz
e395b38685e2ecbe9c3a2850876d9b7b  pigsty-pkg-v4.2.0.d13.aarch64.tgz
c5c8776f9bead9f29528b26058801f83  pigsty-pkg-v4.2.0.d13.x86_64.tgz
28ea40434bd06135fc8adc0df1c8407d  pigsty-pkg-v4.2.0.el10.aarch64.tgz
58ad715ac20dc1717d1687daecfcf625  pigsty-pkg-v4.2.0.el10.x86_64.tgz
008f955439ea311581dd0ebcf5b8bd34  pigsty-pkg-v4.2.0.el8.aarch64.tgz
2acfd127a517b09f07540f808fe9547a  pigsty-pkg-v4.2.0.el8.x86_64.tgz
58e62a92f35291a40e3f05839a1b6bc4  pigsty-pkg-v4.2.0.el9.aarch64.tgz
d311bfdf5d5f60df5fe6cb3d4ced4f9c  pigsty-pkg-v4.2.0.el9.x86_64.tgz
c98972fe9226657ac1faa7b72a22498b  pigsty-pkg-v4.2.0.u22.aarch64.tgz
44a174ee9ba030ac1ea386cf0b85f6e7  pigsty-pkg-v4.2.0.u22.x86_64.tgz
143e404f4681c7d0bbd78ef7982cd652  pigsty-pkg-v4.2.0.u24.aarch64.tgz
00dfa86f477f3adff984906211ab3190  pigsty-pkg-v4.2.0.u24.x86_64.tgz

v4.2.1

这是一个维护版本，新增了 3 个扩展插件，

主要变更

  • 新增扩展：pg_eviltransform 加入 GIS 包组，pg_pinyin 加入 FTS 包组，pg_qos 加入 Admin 包组 —— 均支持 PG 14–18。
  • 移除 PG13：所有平台变体（EL7/8/9/10、Debian 12/13、Ubuntu 22/24，x86_64 与 aarch64）中的 pgdg13、pgdg13-nonfree 仓库条目和 PG13 包别名（pg13-*）全部移除。
  • 配置模板（fat.yml、pro.yml、dev.yml、el.yml、debian.yml）不再引用 PG13 包或仓库。扩展版本注释更新为仅覆盖 PG 14–18。
  • Percona 仓库：Origin URL 从 ppg-18.1 更新为 ppg-18.3，跟踪最新 Percona PostgreSQL 发行版。
  • Nginx 仓库：Debian/Ubuntu 平台上 Nginx 上游 APT 仓库的模块标签从 infra 修正为 nginx。
  • UV Venv 修复：roles/node/tasks/pkg.yml 现在会先检查虚拟环境是否已存在，避免重复执行 uv venv 导致的冗余创建或重新置备报错。
  • Docker 镜像：Pigsty Docker 镜像基础包中新增 less。
  • Demo 配置：el.yml 和 debian.yml 示例配置的默认防火墙规则新增 5432 端口，支持直接访问 PostgreSQL。

兼容性说明

PostgreSQL 13 已于 2025-11-13 到达生命周期终点。 PGDG YUM 仓库已经归档移除 pg13 / pg12 目录。 如果您在 EL 系统上安装 Pigsty （即使没有使用 PG 13 版本），也有可能因为仓库访问失败而导致安装或更新失败。

您可以选择直接使用 Pigsty v4.2.1，或者手工修改 roles/node_id/vars/ 您对应操作系统 repo_upstream_default 变量，移除仓库定义中的 pg13 一行即可。

此外，EL8 仍然在 Pigsty 的兼容操作系统中，但从此版本开始将不再发布 el8 的离线软件包。

本版本没有其他破坏性 API 或配置变更。

7 个提交，84 文件变更，+4,925 / -5,351 行（v4.2.0..v4.2.1，2026-03-04 ~ 2026-03-06）

PostgreSQL 软件包更新

包名 旧版本 新版本 备注
timescaledb 2.25.1 2.25.2
vchord 1.1.0 1.1.1 新增 clang 构建依赖，修复错误
vchord_bm25 0.3.0-1 0.3.0-2 修复版本注入问题
aggs_for_vecs 1.4.0 1.4.1
pg_search 0.21.9 0.21.12
pg_pinyin - 0.0.2 新增扩展
pg_eviltransform - 0.0.2 新增扩展
pg_qos - 1.0.0 新增扩展，QoS 资源治理

基础设施软件包更新

名称 旧版本 新版本 备注
asciinema 3.1.0 3.2.0
grafana-infinity-ds 3.7.2 3.7.3
victoria-metrics 1.136.0 1.137.0
victoria-metrics-cluster 1.136.0 1.137.0
vmutils 1.136.0 1.137.0
hugo 0.155.3 0.157.0
opencode 1.2.15 1.2.17
rustfs 1.0.0-alpha.83 1.0.0-alpha.85
seaweedfs 4.13 4.15
tigerbeetle 0.16.74 0.16.75
uv 0.10.4 0.10.8
codex 0.105.0 0.110.0
claude 2.1.59 2.1.68
xray - 26.2.6 新增
gost - 2.12.0 新增
sabiql - 1.6.2 新增
agentsview - 0.10.0 新增

校验和 

262b7671424a38b208872582fe835ef8  pigsty-v4.2.1.tgz
62edcca1d1e572a247be018e1c26eda8  pigsty-pkg-v4.2.1.d12.aarch64.tgz
1d55367e2fd9106e6f18b7ee112be736  pigsty-pkg-v4.2.1.d12.x86_64.tgz
f122b1e5ba8a7ae8e3dc6e6dd53eba65  pigsty-pkg-v4.2.1.d13.aarch64.tgz
617a76bfc8df8766e78abf24339152eb  pigsty-pkg-v4.2.1.d13.x86_64.tgz
908509b350403ad1a4a27a88795fee06  pigsty-pkg-v4.2.1.el10.aarch64.tgz
70cb4afd90ed7aea6ab43a264f8eb4a8  pigsty-pkg-v4.2.1.el10.x86_64.tgz
98fbd67334f5c674b12e6af81ef76923  pigsty-pkg-v4.2.1.el9.aarch64.tgz
687fa741ccd9dcf611a2aa964bcf1de8  pigsty-pkg-v4.2.1.el9.x86_64.tgz
a2a30f4b1146b3e79be91d5be57615b6  pigsty-pkg-v4.2.1.u22.aarch64.tgz
7a1f571bd8526106775c175ba728eee1  pigsty-pkg-v4.2.1.u22.x86_64.tgz
a5574071bac1955798265f71ad73c3d4  pigsty-pkg-v4.2.1.u24.aarch64.tgz
59a7632c650a3c034f1fe6cd589d7ab5  pigsty-pkg-v4.2.1.u24.x86_64.tgz

v4.2.2

微信公众号原文

Pigsty v4.2.2 已正式发布，这是一次例行维护更新，带来了新工具、新扩展、内核升级，以及大量基础设施软件包的版本刷新。

Insforge 自建模板：新增 Insforge 2.0.1 自建模板，方便用户快速搭建自定义实例。InsForge：为 Vibe Coding 而生的 SupabasePG 新工具：新增数据恢复工具pdu 和连接池pgdog，补齐了 PostgreSQL 工具链的关键拼图。pdu 可用于 PostgreSQL 数据恢复，pgdog 则是一个新兴的 Rust 实现的智能连接池。新增 Infra 软件包：tigerfs（文件系统融合工具）、pgstream、sql-studio、rainfrog、crush 等新工具加入 Pigsty 基础设施家族。IvorySQL 内核升级：IvorySQL 从 5.1 升级至 5.3，保持与上游同步。MinIO / MCLI 更新：更新至 Pigsty 最新维护的 20260321 版本，进一步恢复了更多控制台功能，包括 Site Replication、Tiering 等特性。

图片

PostgreSQL 扩展更新

本次共更新 6 个扩展，新增 2 个工具包：

图片

其中 pgcollection 和 pg_ttl_index 都迎来了大版本跳跃，值得关注。

基础设施软件包更新

本次更新涉及大量 Infra 组件，以下列出部分重点更新：

监控与可观测：Grafana 12.4.1、VictoriaMetrics 全家桶升级至 1.138.0 / 1.48.0、pg_exporter 1.2.1、pgbackrest_exporter 0.23.0开发工具：DuckDB 1.5.0、PostgREST 14.7、code-server 4.112.0、OpenCode 1.2.27、Codex 0.116.0、Claude 2.1.81存储与网络：SeaweedFS 4.17、RustFS 1.0.0-alpha.89、Rclone 1.73.2、Caddy 2.11.2、Vector 0.54.0新增工具：sql-studio 0.1.51、rainfrog 0.3.17、crush 0.51.2、tigerfs 0.5.0、pgstream 1.0.1其他更新：Hugo 0.158.0、uv 0.10.12、Pig CLI 1.3.2、TigerBeetle 0.16.77 等

特别注意：etcd 3.6.9 版本引入不兼容变更，member list API 现在需要认证。目前 Pigsty 锁死在 3.6.8 版本。

图片

*数据库老司机点一个关注 ⭐️，精彩不迷路*

发布版本：微信公众号 v4.2 · v4.2.1 · v4.2.2

14 - Pigsty v4.1：天下武功，唯快不破

原文发布于 VONNG。

GitHub Release | 发布注记

先说结论：天下武功，唯快不破。2026年2月12日，PostgreSQL 社区例行发布了 18.2 / 17.8 / 16.12 / 15.16 / 14.21 五个小版本。 同一天，据我所见全球范围内给出生产级支持的只有三家：AWS RDS，EDB，Pigsty。

pg182.webp

一个开源独立项目，在交付速度上站到了和全球最大云厂商以及 PG 老大哥站在同档速度线上。这件事本身就是我想用 v4.1 讲的故事。

为什么"快"是最重要的能力

做数据库发行版这几年，我越来越清楚一个道理：用户不缺功能，缺的是信任。

信任从哪来？不是 PPT 上写了多少特性，而是在关键时刻你能不能兑现。PostgreSQL 每次小版本更新， 往往带着 bugfix、稳定性修正、安全修补 —— 这些不是锦上添花，而是亡羊补牢。你跟进慢一天，用户就多暴露一天。

很多发行版的节奏是这样的：上游发布后做做内部测试，打包构建，最后两个月过去，发个博客说 “我们现在支持 PG 新版本了”。 等到那个时候，真正着急的用户早就自己手动升级了 —— “支持” 变成了事后追认，而不是事前保障。

PG 版本 社区发布日期 AWS RDS Cloud SQL 阿里云 RDS 腾讯云 华为云 RDS
PG 12 2019-10-03 180天 90天 88天 365天 150天
PG 13 2020-09-24 153天 165天 97天 270天 210天
PG 14 2021-09-30 119天 76天 91天 270天 300天
PG 15 2022-10-13 138天 230天 64天 180天 335天
PG 16 2023-09-14 67天 90天 84天 55天 210天
PG 17 2024-09-26 49天 28天 21天 63天 160天
PG 18 2025-09-25 50天 56天 78天 1天 尚未支持

我想做的恰恰相反：让"跟进"这件事，快到用户根本不需要自己操心。你看到 PostgreSQL 发了新版本，打开 Pigsty，发现已经准备好了 —— 这才是一个发行版应该给用户的体感。

所以 v4.1 的主线不是堆新特性，而是把"快速跟进 + 稳定交付"变成一种可持续的常规能力。这个能力才是护城河，因为它考验的不是某一次的冲刺，而是日复一日的工程纪律。

不止 PostgreSQL：OS 小版本也一起走

做 “快” 容易，又好又快可不容易，这次不仅是 PostgreSQL 的小版本升级，还同步推进了几个 Linux 操作系统发行版的小版本升级：

  • EL：9.6/10.0 → 9.7/10.1
  • Debian：12.12/13.1 → 12.13/13.3

十四个主流 Linux 发行版的最新小版本，都制作好了对应的离线软件包。

这里有个必须再次讲清楚的事情：

EL 9.7 / 10.1 的离线包与 EL 9.6 / 10.0 不通用。

我知道很多用户的部署环境是内网甚至完全离线的。遇到这种包版本不匹配的情况，走在线安装就可以了。

Pig Agent-Native CLI：让工具学会"自我介绍"

举个例子：你让 Claude Code 帮你在三台机器上装 PostgreSQL 18 与一堆扩展， 它调用 pig 的时候不需要你手写任何 prompt 来解释 pig 怎么用 —— 因为 pig 会自己告诉它。这就是 Agent-Native 的意思。

传统 CLI 工具的设计假设是 “有个人在看屏幕”，所以它输出彩色文字、画表格、显示进度条 —— 这些对人很友好，但对 Agent 来说全是噪音。Agent 需要的是三件事：

我 Agent-Native 这个概念，很多人觉得这只是个 buzzword。但 pig 1.1.0 里我做的事情非常具体 —— 核心就一个词：内自省。

什么意思？传统 CLI 工具的设计假设是"有个人在看屏幕"。所以它输出彩色文字、画表格、显示进度条 —— 这些对人很友好，但对 Agent 来说全是噪音。Agent 需要的是：

  • 能干什么 —— 工具主动暴露自己的能力列表，而不是让 Agent 去猜或者去读文档。
  • 干了什么 —— 执行结果是结构化的 JSON/YAML，而不是一坨需要正则解析的文本。
  • 暴露上下文 —— 环境信息可以被程序化地获取和传递。

这三件事听起来简单，但要做好需要重新审视 CLI 的每一个子命令。pig 1.1.0 把 JSON/YAML 从"附属输出格式"提升为 “一等公民”，让每个操作都能被机器可靠地调用和解析。

坦白说，这个需求我只是提出了理念并参与了设计讨论，剩下的实现工作都是由 Codex 和 Claude Code 完成的，我负责最后验收。所以这也算是 Pigsty 里第一个真正意义上的 AI 原生项目。

AI Coding：不是写代码，是扫盲区

v4.1 开发周期里，我在 pig CLI 和 pg_exporter 上投入了大量精力。同时密集使用了 AI coding 工具做复查 —— 主要是 Claude Code 和 Codex 5.3 Extra High。

但我想说的不是"AI 多厉害"，而是 AI 在工程实践中真正好用的那个点在哪里。

答案是 扫盲区。

一个成熟项目里，最危险的 bug 往往不是逻辑错误 —— 那种你写完就知道不对。最危险的是那些"看起来没问题、跑起来没问题、但在特定边界条件下会出问题"的细节。 比如一个指标的单位在 PG17 和 PG18 里不一样，比如一个 io_method 参数的版本条件写成了 >= 17 但实际上应该是 >= 18。

这类问题，人工 review 非常容易漏 —— 因为你的眼睛会自动跳过"看起来对"的代码。 但 AI 不会。它会老老实实地把每一行都过一遍，尤其在你明确告诉它"帮我检查版本守卫条件"的时候。

这轮扫下来，我额外修掉了大约十几到二十个小问题。单独看每个都不大，但累积起来就是用户体验的差距。

这里要特别感谢社区贡献者 @l2dy，他提了很多高质量 issue， 帮我把 Grafana 仪表盘还有配置细节里一批细节问题集中收敛掉了。 开源项目能不能越做越扎实，靠的就是这种愿意认真抠细节的人。

防火墙默认策略：宁可多敲一条命令

最后讲一个看起来很小、但我认为很重要的改动。 在 v4.0 里，我把防火墙默认模式设成了 none —— 意思是 “完全不碰你的防火墙配置”。 初衷是好的：尊重用户现有环境，不做多余的事。但实际反馈告诉我，这个决定有问题。

问题出在哪？EL9 系列默认是开着 firewalld 的，但很多用户对自己的防火墙状态并不清楚。 当 Pigsty 选择"不碰"的时候，用户以为一切正常，结果发现内网流量不通，排查半天才发现是防火墙规则没配对。这比 Pigsty 主动配置防火墙带来的 “干预感” 要糟糕得多。

所以 v4.1 我把默认模式改回了 zone，规则非常简单：

  • 内网网段默认信任
  • 公网默认只开放三个端口：22（SSH）、80（HTTP）、443（HTTPS）
  • 数据库端口 5432 不再默认暴露在公网

如果你需要对外开放数据库端口，需要自己显式添加。我知道这会让某些场景多敲一条命令，但我的判断是：对于安全相关的默认值，保守永远好过激进。 把“开放”变成一个有意识的动作，而不是一个容易遗忘的默认值。

七个新扩展，总数来到 451

每个版本照例更新扩展生态，这次新增 7 个，总数到 451。几个值得关注的：

  • pg_track_optimizer 0.9.1：自动追踪和推荐索引优化，这个方向一直有人问。
  • nominatim_fdw 1.1.0：OpenStreetMap 地理编码的外部数据包装器，GIS 用户会喜欢。
  • pg_utl_smtp 1.0.0：从数据库里直接发邮件，Oracle 迁移用户的老朋友了。
  • pg_strict 1.0.2：严格模式扩展，避免不带条件的 UPDATE/DELETE

同时 TimescaleDB 升到 2.25.0，citus 14.0.0 正式发布，还有一个非常强大的数据匿名化扩展 Postgres Anonymizer 发布了 3.0 —— 都是每个领域的重要更新。

其他值得一提的改动

简单列几个我觉得有价值但不值得单独成章的改动：

autovacuum 阈值调优：把 oltp/crit/tiny 模板的 autovacuum_vacuum_threshold 从 50 提到 500，analyze_threshold 从 50 提到 250。原因是小表在默认阈值下会被高频 vacuum/analyze，造成不必要的 IO 开销。这个改动对有大量小表的场景（比如多租户系统）会有明显改善。

文件描述符上限统一：修复了 fs.nr_open 和 LimitNOFILE 的层级关系，统一设为 8M。之前有用户在高并发场景下遇到 FD 耗尽，排查发现是内核参数和 systemd 配置不一致导致的。

checkpoint_completion_target：从 0.90 提到 0.95。这个参数控制 checkpoint 写入的平滑程度，0.95 能更好地分散 IO 压力，减少 checkpoint 期间的性能抖动。

Vibe 调整：Jupyter 默认关闭（大多数人不用），Claude Code 改为通过 npm 包统一管理（之前的安装方式不够干净）。

infra-rm 重构：卸载逻辑新增 deregister 分段清理，不再是一把梭全删。你可以更精细地控制卸载的范围和顺序。

新增 Mattermost 应用模板：一键部署 Mattermost，包含数据库、文件存储、反向代理的完整配置。适合需要自建团队通讯工具的场景。如果你觉得 QQ/微信接入 ClawdBot 太麻烦，为什么不自己搭建一个 IM 呢？

写在最后

v4.1 不是一个大版本。没有架构重写，没有新模块登场。但它证明了一件事：上游发布当天即可交付生产级支持，这个速度不是偶然的冲刺，而是一种可以持续兑现的工程能力。 开头说用户缺的是信任。信任不是一次建立的，而是每一次小版本发布时你都在那里，每一次安全修补你都没有缺席。v4.1 想做的，就是把这件事再证明一次。 以上是 v4.1 的核心思路和重点改动。下面附完整的版本提交注记和技术细节，方便按需查阅。

v4.1.0 提交注记

Pigsty v4.1.0 版本发布，主旨是“天下武功，唯快不破”。

curl https://pigsty.cc/get | bash -s v4.1.0

72 个提交，252 文件变更，+5,744 / -5,015 行（v4.0.0..v4.1.0，2026-02-02 ~ 2026-02-13）

亮点特性

  • 新增 7 个扩展，总计 451 个扩展支持。
  • pig 升级为 Agent-Native CLI（1.0.0 -> 1.1.0），支持主动暴露上下文并输出 JSON/YAML。
  • pig 新增 PostgreSQL / OS 大小版本更新 统一能力。
  • pg_exporter 升级到 v1.2.0（1.1.2 -> 1.2.0），修复 PG17/18 指标链路与单位问题。
  • 防火墙默认安全策略收紧：node_firewall_mode=zone，node_firewall_public_port 收敛为 [22,80,443]。
  • PostgreSQL 小版本更新：18.2、17.8、16.12、15.16、14.21。
  • EL 默认小版本更新到 9.7 / 10.1，Debian 默认小版本更新到 12.13 / 13.3。
  • 新增 Mattermost 一键应用模板，支持数据库、目录、门户与可选 PGFS/JuiceFS。
  • 重构 infra-rm 卸载逻辑，新增 deregister 分段清理能力。
  • 优化 autovacuum 默认阈值，减少小表高频 vacuum/analyze。
  • 修复 FD 上限链路，统一 fs.nr_open 与 LimitNOFILE=8M。
  • Vibe 默认体验调整：Jupyter 默认关闭，Claude Code 改为 npm 包统一管理。

版本更新

  • Pigsty：v4.0.0 -> v4.1.0
  • pig CLI：1.0.0 -> 1.1.0
  • pg_exporter：1.1.2 -> 1.2.0
  • 默认 EL 小版本：9.6/10.0 -> 9.7/10.1
  • 默认 Debian 小版本：12.12/13.1 -> 12.13/13.3

扩展更新

  • RPM Changelog 2026-02-12
  • DEB Changelog 2026-02-12
  • timescaledb 2.24.0 -> 2.25.0
  • pg_search 0.21.4 -> 0.21.7
  • pgmq 1.9.0 -> 1.10.0
  • pg_textsearch 0.4.0 -> 0.5.0
  • pljs 1.0.4 -> 1.0.5
  • pg_track_optimizer 0.9.1（新增）
  • nominatim_fdw 1.1.0（新增）
  • pg_utl_smtp 1.0.0（新增）
  • pg_strict 1.0.2（新增）
  • pgmb 1.0.0（新增）
  • pg_pwhash（新增支持）
  • informix_fdw（新增支持）

API 变化

  • io_method / io_workers 模板条件从 pg_version >= 17 更正为 pg_version >= 18。
  • idle_replication_slot_timeout / initdb --no-data-checksums 的 PG18 守卫条件修正。
  • maintenance_io_concurrency 生效范围放宽至 PG13+。
  • autovacuum_vacuum_threshold：oltp/crit/tiny 从 50 提升到 500，olap 提升到 1000。
  • autovacuum_analyze_threshold：oltp/crit/tiny 从 50 提升到 250，olap 提升到 500。
  • checkpoint_completion_target 默认从 0.90 提升到 0.95。
  • 默认加入 fs.nr_open: 8388608，并统一 fs.file-max / fs.nr_open / LimitNOFILE 层级关系。
  • node_firewall_mode 默认从 none 调整为 zone。
  • node_firewall_public_port 默认从 [22,80,443,5432] 调整为 [22,80,443]。
  • bin/validate 新增 pg_databases[*].parameters 与 pg_hba_rules[*].order 校验支持。
  • infra-rm.yml 新增 deregister、config、env 等分段标签。
  • Vibe 默认 jupyter_enabled=false，并默认安装 @anthropic-ai/claude-code、happy-coder。
  • PgBouncer 参数别名收敛：pool_size_reserve -> pool_reserve，pool_max_db_conn -> pool_connlimit。

兼容性修复（归并）

  • Redis replicaof 判空逻辑与 systemd 停止行为修复。
  • pg_migration 的全限定、标识符 quoting 与日志格式安全修复。
  • pgsql role handler 重启对象与变量使用错误修复。
  • blackbox 配置文件名清理项与 pgAdmin pgpass 文件格式修复。
  • pg_exporter 启动改为非阻断，避免拖慢主流程。
  • VIP 地址解析逻辑简化，未显式 CIDR 时默认掩码 24。
  • MinIO 健康检查重试从 3 提升到 5。
  • 节点主机名设置改用 hostname 模块。
  • app/electric 与 app/pg_exporter 的 .env 修复为标准 KEY=VALUE。
  • 修复 pigsty.yml 的 pg_crontab 语法错误。
  • ETCD 文档更新，明确默认 TLS 与可选 mTLS 的语义差异。
  • 修复 repo-add 参数传递、Debian 中国镜像兼容性与 bin/psql.py Python3 兼容性。
  • redis exporter 凭据文件权限加固。
  • pgsql-user.yml 对敏感步骤启用 no_log。
  • pg_monitor 注册 Victoria target 的 gate 条件修复。
  • pg_remove 备份清理改为集群级目录，避免误删其他集群备份。

关键提交（节选） 

7410de401 v4.1.0 release
fa31213ce conf(node): default firewall to zone with single-node 5432 override
bb8382c58 update default extension list to 451
770d01959 hide user credential in pgsql-user playbook
7219a896c pg_monitor: fix victoria registration gate conditions
7005617f1 pgsql: drop legacy pgbouncer pool parameter aliases
74c59aabe grafana: fix dashboard links, descriptions, and overrides
36c95c749 fix(cli): restore repo-add execution and HBA validation failure propagation
6f2576fd0 fix(node): set default fs.nr_open via node_sysctl_params
26e108788 fix(monitor): correct unit for time metrics scaled by pg_exporter
d439464b2 pgsql: fix pg_version guards for PG18-only settings
cb52375ac bump checkpoint_completion_target from 0.90 to 0.95
c402f0e6d fix: correct io_method/io_workers version guard from PG17 to PG18
3bf676546 vibe: disable jupyter by default and install claude-code via npm_packages
613c4efa9 fix: set fs.nr_open in tuned profiles and reduce LimitNOFILE to 8M
4cc68ed61 refine infra removal playbook
318d85e6e simplify VIP parsing and make pg_exporter non-blocking
4bff01100 fix redis replicaof guard and systemd stop
38445b68d minio: increase health check retries
a237e6c99 tune autovacuum threshold to reduce small table vacuum frequency

完整 72 条提交请参考 GitHub Release 页面。

致谢

  • 感谢 @l2dy 为本项目提出诸多改进意见与 Issue。

校验和 

8bc75e8df0e3830931f2ddab71b89630  pigsty-v4.1.0.tgz
da10de99d819421630f430d01bc9de62  pigsty-pkg-v4.1.0.d12.aarch64.tgz
e1f2ed2da0d6b8c360f9fa2faaa7e175  pigsty-pkg-v4.1.0.d12.x86_64.tgz
382bb38a81c138b1b3e7c194211c2138  pigsty-pkg-v4.1.0.d13.aarch64.tgz
13ceaa728901cc4202687f03d25f1479  pigsty-pkg-v4.1.0.d13.x86_64.tgz
92d061de4d495d05d42f91e4283e7502  pigsty-pkg-v4.1.0.el10.aarch64.tgz
be629ea91adf86bbd7e1c59b659d0069  pigsty-pkg-v4.1.0.el10.x86_64.tgz
c14be706119ba33dd06c71dda6c02298  pigsty-pkg-v4.1.0.el8.aarch64.tgz
0c8b6952ffc00e3b169896129ea39184  pigsty-pkg-v4.1.0.el8.x86_64.tgz
cfcc63b9ecc525165674f58f9365aa19  pigsty-pkg-v4.1.0.el9.aarch64.tgz
34f733080bfa9c8515d1573c35f3e870  pigsty-pkg-v4.1.0.el9.x86_64.tgz
ad52ce9bf25e4d834e55873b3f9ada51  pigsty-pkg-v4.1.0.u22.aarch64.tgz
300b2185c61a03ea7733248e526f3342  pigsty-pkg-v4.1.0.u22.x86_64.tgz
2e561e6ae9abb14796872059d2f694a8  pigsty-pkg-v4.1.0.u24.aarch64.tgz
c462bb4cb2359e771ffcad006888fbd4  pigsty-pkg-v4.1.0.u24.x86_64.tgz

15 - Agent 的护城河：强龙不压地头蛇

原文发布于 VONNG。

凌晨三点，数据库告警炸了。

你尝试把告警信息甩给一个 “顶级” DBA Agent。它见多识广，熟读 PostgreSQL 文档，能写出漂亮的诊断 SQL，对每一个内核参数的含义倒背如流。 它愣住了：集群拓扑是什么样的？主从都在哪些服务器上？监控面板怎么看？日志哪里找？上次类似故障怎么解的？我该用什么工具执行什么操作？

什么都不知道。

而隔壁那个用普通模型、但深度接入了完整运维环境的 Agent，已经定位到根因、完成了切换重启、发出了复盘报告。

原理很朴素 —— 一个熟悉环境的普通人，会比来到陌生环境的天才更能干。这就是强龙不压地头蛇。 没有上下文的智力，是空转的。没有 Runtime 的 Agent，是虚浮的。

OtterTune：一个价值 1200 万美元的教训

2020 年，CMU 数据库网红教授 Andy Pavlo 带着学生创办了 OtterTune —— 用 AI 做数据库自动调优。 顶级学术团队、拿了 1200 万美元投资、瞄准 PostgreSQL 和 MySQL 两大主流数据库，背景不可谓不豪华。

产品逻辑概括一下：给我一个数据库连接串，AI 就能帮你调优。

2024 年 6 月，OtterTune 宣布关门。表面原因是收购交易破裂。 但在老冯看来，根本的问题是：一个连接串能做的事情，价值实在太少了。

img

通过连接串，你能看到 pg_stat_statements 里的慢查询、pg_settings 里的配置参数、几个系统视图的统计信息。然后呢？调几个 knob，优化几条 SQL。仅此而已。

但真正的数据库运维远不止这些。一个连接串连的是一个 PostgreSQL 实例，但现实中你面对的是什么？ 一个集群包含多个实例——主库、从库、离线副本、同步备份；集群之上还有水平分片；顶层可能有上百套集群分属不同业务组。 除了数据库自身的指标，你还需要备份状态、高可用组件状态、连接池指标、主机 CPU/内存/磁盘/网络指标。这些东西 全部在连接串的外面。

一个只拿到连接串的 Agent，就像一个只能通过猫眼观察房间的人 —— 视野极其有限。 更尴尬的是：连接串里能做的那些事，恰恰是大模型裸聊就能做得不错的事。 你让 Claude 或 GPT 直接看一条慢 SQL，它给出的优化建议已经相当靠谱了。你做的事情 LLM 直接就能做，那你的壁垒在哪？

OtterTune 踩的坑，本质上是一个 Runtime 问题：它试图在没有运行时环境的情况下做运维。 面对一个抽象的裸 PostgreSQL 做优化 —— 它有一个强大的大脑，但没有手，没有眼睛，甚至没有身体，这就像请霍金表演体操一样荒诞。

PS: 我知道他们开始第二轮创业了，这次还是做 PostgreSQL 调优，希望他们这次能走上正路

Manus：真正的核心是那个沙箱

如果 OtterTune 是反面教材，那 Manus 就是正面案例。

2025 年 3 月，Manus 横空出世，迅速成为现象级产品。很多人研究它为什么成功，把注意力放在它积累的那些 Markdown 提示词上，或者放在它用了哪个大模型上。

盯错地方了

Manus 真正的核心不是提示词，也不是大模型。它的核心是那个 虚拟机沙箱 —— 每个用户会话都运行在一个独立的云端 Linux 虚拟机中， 里面有完整的文件系统、浏览器、Shell 终端、代码解释器。Agent 在这个确定性的环境中工作，能读写文件、执行代码、浏览网页、部署应用。

Manus 自己也说得很清楚：“The power of Sandbox lies in its completeness”

正是这个完备且确定的沙箱，让大模型的能力得以充分释放。没有这个沙箱，同样的模型只是一个聊天机器人。有了这个沙箱，它变成了一个能真正完成任务的 Agent。 而且 Manus 换过好几次底层模型 —— 从 GPT 到 Claude —— 效果一直在线。

最近爆火的 OpenClaw 也验证了同样的道理。它之所以能让人喊出 “AI with hands”，不是因为底层模型有多强，而是因为它深度接入了宿主操作系统 —— 文件系统、Shell、浏览器、日历、消息应用全都通过 CLI 打通了。把它丢到一个空白的云虚拟机里，脱离了这些本地环境的手脚，它就只是又一个普通的聊天机器人而已。

Manus 和 OpenClaw 的成功验证了同一件事：LLM 是大脑，但真正重要的是身体。

大脑、身体和确定性

Manus 的启示可以再往下推一层。

生物学上，智能的实现依赖三个要素：传感器（感知环境）、决策器（处理信息）、执行器（作用于环境）。一个只有大脑没有身体的生物，不叫智能体，只是缸中之脑。

Agent 也是一样。大模型是决策器，但你还需要传感器和执行器 —— 也就是 可观测性 和 可控制性。三者构成了 Agent 的 身体。而这个身体要能正常工作，需要一个前提：确定性。

你不能把大脑丢到一个陌生的环境里，让它操纵一条奇形怪状的机械臂。大脑必须 “认识” 自己的身体，知道发出什么信号会产生什么动作，接收什么反馈意味着什么状态。大脑和身体之间需要一套稳定的、可预期的协议。

featured.webp

这就是 Runtime 的本质：Agent 的确定性身体。

以 DBA Agent 为例，一个完整的 Runtime 意味着：

传感器 —— 完整的可观测性。不只是一个连接串能看到的那点东西，而是从主机指标、连接池状态、高可用组件心跳、备份任务进度到数据库内部统计的全栈监控，这些信息有机地融合在一起，提供从单实例到整个数据平台的层层视角。

执行器 —— 完整的可操控性。配置变更、高可用切换、备份恢复、滚动升级。不是调用别人的 API，而是直接掌控基础设施的"形状"。如果你只是调云厂商的接口，你的 Agent 永远被原作者的想象力所限制。

确定性 —— 可预测的行为和可追溯的记录。同样的操作，同样的条件，同样的结果。每一步都有记录，每一次变更都可回滚。不确定的环境里跑不出确定的结果。

img

五年前我做 PostgreSQL 监控的时候就发现了这个问题 _如果想做最好的监控系统，不能只靠一个连接串。连接串确实能做一些事，但离 “做好” 差得太远。 要把可观测性做到极致，你必须直接掌控 Runtime，直接控制基础设施的形状。这也是 Pigsty 从一个 PostgreSQL 监控系统项目，演变为一个完整的 PostgreSQL 发行版的关键契机。监控如此，管控亦然，智能更是如此。

OtterTune 有大脑，没有身体。结局是注定的。Manus 造了一个确定性的身体（沙箱），大脑的能力才得以释放。

DBA Agent 的身体，只有三个选择

让我们用一个具体的 Agent 场景为例 —— DBA Agent。 Coding Agent 的上下文 是代码目录，DBA Agent 的上下文是什么？

什么是 DBA Agent 的身体？谁能提供 DBA Agent 的身体

第一条路：云厂商。 RDS、Cloud SQL、Azure Database——监控、告警、备份、高可用都有。但这是别人的身体。 你的 Agent 只能在厂商画好的圈子里活动，运维知识沉淀在厂商平台上与 Vendor 绑定，换个云就清零。 如果你像 OtterTune 那样寄生在云厂商的接口上做 Agent，你的设计天花板就是云厂商 API 的天花板。这不是身体，这是笼子。

第二条路：Kubernetes。 K8s Operator 理论上也能提供自动化运维能力。 但 K8s 给数据库引入了大量不必要的复杂度 —— 存储编排、网络策略、状态管理、CRD 抽象层层叠叠。 Agent 要在 K8s 上做数据库运维，需要理解的概念比直接管理数据库多出一个数量级。 K8s 的抽象层产生了巨大的阻抗，让 Agent 离它真正要管的东西——数据库本身——越来越远。 这不是在给 Agent 提供身体，这是在给它套上一层厚重的太空服。

第三条路：Pigsty。 一个开源的 PostgreSQL 发行版，直接基于原生 Linux 提供全家桶级的确定性 Runtime。 完整的可观测性体系覆盖从主机到数据库的全栈监控，生产级的高可用和自动化备份恢复，444 扩展开箱可用，整套基础设施使用 IaC 来管理。

pigsty-arch

Pigsty 与云厂商数据库运行时的区别：这是一套开源免费，属于你自己的身体。 Runtime 的每一层都是开放的 —— Agent 可以直接读取监控指标、查询日志、调用标准运维接口。 没有黑盒，没有围墙。运维知识沉淀在你自己的基础设施上。可以在任何云环境，以及你自己的笔记本到数据中心上运行。

Pigsty 与 K8s 的区别：没有不必要的抽象层。 Agent 直接面对数据库和操作系统，操作路径短，确定性高。用比喻来说： 云厂商是租来的剧场，设施齐全但规矩多、租金贵，演完了布景带不走。K8s 是过度设计的剧场，光学会怎么开灯就要三天。 Pigsty 是你自己建的剧场——设施齐全，布局简洁，演员可以自由发挥，积累的一切属于你。

已经有人上台了

清华大学的数据库团队在 2024 年就开始做这件事了。他们的 D-Bot 项目在完整的 Pigsty 运维环境中，探索 Agent 自主诊断故障、分析根因、生成修复建议的能力。 这个选择本身就很有说明性：不是拿一个连接串远程试探，而是在一个有监控、有工具、有知识库、有操作接口的完整 Runtime 中工作。

Metrics and Datadbot

老冯也参与了这篇 VLDB 论文：D-Bot: Database Diagnosis System using Large Language Models

学术研究需要可复现的环境，而基础设施即代码天然满足这个需求。同样的配置部署一百次，环境都一模一样。这正是 Agent 所需要的确定性。 与此同时，我自己也在开发 DBA Agent。谁比基础设施的建造者更了解自己的 Runtime？一个开放的 Runtime 上，学术团队在探索边界，基础设施建造者在打磨核心，社区开发者在贡献创意。生态正在形成。

如果你对 DBA 智能体感兴趣，Pigsty 可能是最好的试炼场。它提供了真实企业环境中 PostgreSQL 服务所需的一切上下文 —— 完整的 高可用 与 PITR， 以及 Best of Breed 的可观测性。

龙会换代，地不会变

回到凌晨三点。

同样的告警，但这次 Agent 运行在完整的 Runtime 上——它自己的身体里。它看到了监控面板上的异常曲线，从日志中定位到根因，确认了集群拓扑和主从状态， 按标准流程完成了故障切换，验证了切换后的健康状态，生成了复盘报告。全程自动，全程可追溯。

模型可能是 GPT，可能是 Claude，可能是某个开源模型，这不重要。 Agent 本身可能就是几个简单的 Skills 和 Claude.md ，这也不重要。 Agent 时代的护城河不是更聪明的大脑，而是更确定的身体。在这个确定性的身体中，一个简单的 CLAUDE.md 文件，就足够让中等智能水准的 LLM 表现出 中级 DBA 的水平来。

数据库需求金字塔

OtterTune 用 1200 万美元证明了：没有身体的大脑走不通。Manus 用一个沙箱证明了：给大脑一个确定性的身体，它就能创造奇迹。 强龙来了一条又一条，每条都比上一条更强。但地头蛇在自己的地盘上深耕日久，壁垒越积越厚。

龙会换代，地不会变，这才是 Agent 时代的护城河。

16 - Pigsty v4.0 发布：进入 AI 时代

原文发布于 VONNG。

Pigsty v4.0 发布了！ 这是一个具有里程碑意义的大版本。

Pigsty 是一个开箱即用、开源且本地优先的 PostgreSQL 数据库发行版。它能让你在没有数据库专家的情况下， 在本地快速搭建企业级的 PostgreSQL 数据库服务，自带监控、备份、高可用、IaC、连接池与 444 个扩展插件。

v4.0 是一次重大的架构升级，由 320 个 Commit 组成，有着将近 40 万行代码的变动（虽然其中三十多万行是监控面板）。 我认为这个版本可以称之为 “Finished Software” —— 它已经达到了一个让我自己满意的完工状态。

v4.0 的主题是：更开放、更高效、更安全、更智能。 下面我们会介绍一下 v4.0 的新特性，以及未来发展的展望。

pigsty-v4.webp

太长；不看

协议变更：回归 Apache 2.0

Pigsty v4.0 重新从 AGPLv3 许可证改回了 Apache 2.0 宽松许可证。 对于用户来说，当你在公司使用时，就不需要再和法务去 Battle 了，ISV 也可以用它放心地集成，作为各类软件与项目的底座。 如果你想做一个自己的定制 PG 发行版，也完全可以在 Pigsty 的基础上进行，避免重复造轮子。

关于变更的细节，这里就不展开讨论了，老冯专门写了一篇文章讨论这个事。《从AGPL到Apache：Pigsty 协议变更的思考》。

监控焕新：Victoria 全家桶上位

v4 最标志性的改动是用 Victoria 全家桶 替换掉了 Prometheus 和 Loki，并添加了 Tracing 能力。

VictoriaMetrics 是 Prometheus 的上位替代品，我们几年前在探探就大规模用过，效果惊人，用几分之一的资源实现了几倍的效果。

这次切换的契机是 Loki 表现不佳，而它配套的日志收集 Agent Promtail 今年也将被弃用。 我选择了目前最好的方案：VictoriaLogs + Vector，顺便也把 VMetrics + VTrace 带上了。

效果立竿见影：以前拉取一天的日志需要转圈等待，现在 VictoriaLogs 基本秒出。 我们将所有日志收集迁移到 VictoriaLogs，设计了与 Prometheus 一致的标签体系，给各组件补齐了日志监控。 各个组件都添加了 Logs 与 Panels，还新增了 Node Vector、Node Juice、Claude Code 等全新仪表盘。

arch.png

架构上也做了简化：原本需要通过 Nginx 给不同组件挂载不同端点，现在所有组件统一挂载在一个 Nginx Server 上。 你不再需要区分域名和端口，一个域名甚至直接用 IP 就能访问 Grafana、日志系统、监控指标和 Alertmanager。 企业版还提供了自动汉化功能，将每个指标的标题、描述都翻译成中文，并补充了使用和解读说明。

nginx.webp

从整体上来看，当下的 INFRA 模块，就像是一个 Victoria 发行版，Metrics + Logs + Trace + Alert + 统一 UI 入口。 配上开箱即用的 Grafana，就能让你轻松拥有一个企业级的可观测性平台。

容器支持：Docker 党的福音

Docker 容器支持，应该是社区呼声最高的功能 —— 让 Pigsty 本身跑在容器里。 以前虽然能实现，但需要手动修改参数，对基础镜像和 Systemd 配置有技术门槛。 现在，我们直接提供了官方基础镜像，只要你有 Docker，一键就可以拉起！（前提是你的 Docker Hub 已经翻好了）

cd ~/pigsty/docker; make launch	# 一键启动单机容器版 Pigsty
docker-compose.webp

在镜像设计上，我纠结了很久，是交付一个装好了所有东西的镜像，还是一个可以部署的精简镜像。 最后我选择了后者，基于 Debian 13 官方镜像，添加了 systemd、ssh、sudo 以及 pigsty 本体，其他东西都交由 deploy 部署阶段在线完成。 这样基础镜像的大小就只有 200 MB 左右（否则是 3 GB）。

部署完成后，你就可以正常使用了，默认使用本地的 8080 端口提供 web 服务；2222 端口提供 ssh 访问；5432 端口提供数据库访问。 无论是 Windows，MacOS 还是 Linux，都可以轻松拉起，快速尝鲜。

PG 18 就绪：444 个扩展严阵以待

Pigsty v4 的一个核心目标，就是确保 PostgreSQL 18 成为生产可用的默认版本。 在这一轮发布周期中，我们为 TimescaleDB、ParadeDB、Citus、DocumentDB、AGE 这样的主要扩展添加了 PG 18 支持。

为了实现这一点，我们为 14 个 Linux 上的 6 个 PG 大版本编译了约 226+ 扩展包，让可用扩展的总数达到了 444 个，同时还修复了不少 PGDG 中缺失的扩展组合。 还额外包括了 10 个全新的扩展：

扩展 版本 说明
pg_textsearch 0.4.0 使用 BM25 排名的全文搜索
pg_clickhouse 0.1.3 从 PostgreSQL 查询 ClickHouse 数据库
pg_ai_query 0.1.1 AI 驱动的 SQL 查询生成
etcd_fdw 0.0.0 etcd 外部数据包装器
pg_ttl_index 0.1.0 使用 TTL 索引自动过期数据
pljs 1.0.4 PL/JS 可信存储过程语言
pg_retry 1.0.0 支持指数退避的瞬态错误重试
weighted_statistics 1.0.0 稀疏数据的高性能加权统计函数
pg_enigma 0.5.0 加密的 Postgres 数据类型
pglinter 1.0.1 PostgreSQL SQL Linter

与此同时，我们还进一步优化了 PG 的默认参数配置策略。 例如，允许用户配置新增的 io_method 以充分利用异步 IO 能力，并且启用了 file_copy_method = clone，以实现对 “瞬间克隆数据库” 的支持。 PG 17/18 的新增参数和之前的老参数，我们都认真仔细地重新梳理了一遍，并根据更新过的业界最佳实践提供了表现良好的默认值。

同时，提供 Oracle 兼容性的 IvorySQL 内核与 TDE 透明加密的 Percona 内核都提供了 PG 18 的版本支持。 提供 MongoDB 兼容性的 FerretDB 在我切换至微软的 DocumentDB 版本后，也提供了 PG 18 的支持。

总而言之，PG 18 的主要扩展都已经正式就位，参数也已经充分利用并优化完毕，监控指标也完整收集处理。 Pigsty 中的 PG 18 已经可以以全盛状态，进入严苛的生产环境使用！

安全加固：密码，防火墙，SELinux

Pigsty v4 也在安全方面做了大量工作，对照等保，SOC2 等合规标准，基本实现了所有能做的安全合规点。 几个值得一提的改进：

随机默认强密码：经常有用户部署直接用默认密码，这次我们新增了 configure -g 选项，自动把所有默认密码替换成随机强密码。

ETCD 启用 RBAC：以前全局用证书认证，现在每个 PG 集群一个自己的 etcd 用户密码。 管理节点可以管理所有集群，普通数据库节点仅能管理自身所在的集群，避免串台干扰。

SELinux 规则优化：以前默认关闭，现在 EL 系统中基本的安全上下文都已配置妥当，默认为 permissive 模式，可以直接按需 enforce。

防火墙默认支持：现在支持定义公网开放端口，内网网段。 即使云服务器没有提供安全组，你也可以自己用简单的方式将暴露面缩小到最小状态（默认开 ssh 22，http 80，https 443，按需 pgsql 5432）

此外，我们还梳理了所有用户和文件的权限属主模型，把所有数据聚拢在统一目录（/data）下（方便 Docker 挂载）。 根据不同用户组拆分权限，完全遵循最小权限原则。

最后，这些安全策略都是渐进式的：默认配置下只要随机生成了强密码，就已经足够安全了。 而更多高级安全选项，则供企业用户根据自己的实际情况进行利弊权衡与选用。

JUICE 模块：把数据库当文件系统

v4 新增的 JUICE 模块集成了 JuiceFS，可以把对象存储和 PostgreSQL 挂载成本地文件系统。 最厉害的玩法是把数据和元数据都放到同一个 PG 里，实现 文件系统和数据库的一致性 PITR， 详见《PGFS：将数据库作为文件系统》。

这解决了一个实际痛点：一个应用既有文件系统（存放知识库文件），又用了数据库。 回滚时数据库 PITR 容易，文件系统难，两者保持一致更难。 现在你可以把文件全部存到数据库里，实现整个系统的同步时间点回滚。

这种能力对 Agent 特别有用。 你可以在挂载目录上进行 Vibe Coding，所有修改实时存储在数据库中，相比 Git 手动快照的方式，可以瞬间回滚到任意历史时间点。 以前只有高端商用 CDP 设备才有这种能力，现在 Pigsty 免费提供。 在 PIGLET AI 沙箱里面，就默认配置了这个功能。

vibe.webp

VIBE 模块：Claude Code 运行时

VIBE 模块为 Vibe Coding 准备，是完全可选的。 它配置好了 Node.js、Claude Code，还有 VS Code 和 Jupyter，都可以直接从浏览器访问。 此外，还有 uv python 包管理器，npm，golang，hugo 等常用工具。 中国区域的部署，还会自动配置 Python/Node 的镜像源，安装速度快，不需要翻墙。

最妙的是，我们还准备好了完整的 Claude Code 环境，可以一键帮你下载并配置好最新版本。 只需一行配置就能使用 CC + 国产 GLM 4.7 等，提供了各种便利的快捷方式，可以让 Claude Code 以 Sandbox 模式 YOLO 运行。 还提供了一个监控 Claude Code 的 Grafana Dashboard，能让你实时了解你的 Agent 正在干什么、想什么。 甚至还带了个 happy + tmux，让你能很方便的用手机语音指挥 CC 干活。

claude-monitor.webp

VIBE 模块还可以和 Juice 模块配合使用，例如在 PIGLET.RUN 沙箱环境中就是这样做的： 把你的代码目录整个通过 JuiceFS 模块挂载到数据库里，就能利用数据库的时间点恢复能力，一键将文件系统和数据库同时回滚到任意时间点。

这个模块是给 PIGLET.RUN 准备的，也是老冯自己在云端写代码开发时使用的环境。 装好之后，你等于有了一个完整的云上开发环境，足够安全，而且工具齐备。

DBA Agent：Skills 与命令行

VIBE 这个模块，并非只是拿来搞开发用的。 它的真正用途是为老冯在做的 DBA Agent 打基础 —— 其实你现在用这个模块装好 Claude Code 之后，它已经能够在 Pigsty 环境里面做一些很有价值的事情了。 帮你巡检数据库，出个报告，优化查询之类的问题，都不在话下。

我之前写过一篇 PostgreSQL 快速上手教程：安装 Pigsty，运行 Open Code 调用 GLM-4 模型，让它扮演老师指导学习。 用户反馈效果惊人，一些 DBA 试用后说"这玩意儿怪吓人的"——给它丢个巡检任务，没做额外配置就能干得相当出色。

当然，让 Agent 在生产环境放手大干还是过于激进，所以硬性规则还是需要仔细配置的：哪些操作绝对不能做，哪些必须人工确认，权限如何划分。 我们在 pigsty 家目录里面已经有了一个基础的 CLAUDE.md 告诉 CC 什么能做，什么不能做，你在这个目录里面启动，就可以启用它。

Pigsty 做 DBA Agent 有一个得天独厚的优势，就是它的上下文与环境是高度确定，而且是用代码清晰描述管理的。 Pigsty 从第一天就坚持 IaC（基础设施即代码） + CLI（命令行工具） 的理念，只将图形界面用于监控系统，而非管控。

因为我们相信程序化，智能化管理的终局就是 IAC + CLI。 因此 CC 只需简单读取 pigsty.yml 配置文件，就能知道你的环境中有什么模块组件，如何访问与使用。

而一个简单易用的 AgentNative CLI，更是会让 DBA 和 DBA Agent 如虎添翼。 这次跟着 Pigsty v4 一起发布的 pig v1.0，就提供了许多这样的能力封装，将原本复杂的命令与操作序列，组织为傻瓜 / Agent 都会用的命令，后面将专门写文章介绍。

高可用优化：RTO/RPO 拆解与权衡

除了 AI4PG 和 PG4AI，Pigsty v4 也在数据库服务的核心基本功上做了很多优化。 之前也在 《PostgreSQL 高可用到底怎么做？》这篇文章中详细介绍过。

Pigsty 用户的场景很广泛：同机柜部署、跨机房容灾、跨大洲架构（延迟 200ms+、高丢包）。 这些场景对高可用参数的要求完全不同。

以前我们只是共用一套调整了的 Patroni 参数集，而这次我们针对几种不同的情况，提供了四种预制的参数模板。

rto-mode.webp

同理，我们也照着 Oracle 的数据保护模式，提出了三种典型的 RPO 模板，供用户在数据一致性与性能/可用性之间进行利弊权衡。

protect-mode.webp

有意思的是，当我们深入研究这个主题的时候，我们发现市面上绝大多数基于 Patroni 的高可用方案使用的都是默认参数，也没有人详细分析过 RTO 的组成。 所以这里我定量分析了几种故障路径下 RTO 的详细组成，并确保这几组参数的最劣情况 RTO 不超过指定上界。 用理论分析，确保用户在用 Patroni 高可用的时候，做到心里有数、安心放心。

rto-chart.webp

用理论拆解的方式，将四组参数的 RTO 上限控制在 30/45/90/150s 内

瞬间克隆：瞬间复刻数据库与实例

不仅仅是高可用有改进，在 PITR 上也有了显著的优化 《Git for Data: 瞬间克隆PG数据库》。 PostgreSQL 18 带来了瞬间克隆能力，这是 AI 应用特别需要的：快速、低成本地 Clone 一个副本。

生产库可能几百 GB 甚至几个 TB，不可能直接在上面做测试。 Fork 采用 COW（写时拷贝）技术，即使超大型数据库也能在 200 毫秒左右完成克隆。 最酷的是克隆后存储空间不变：两个 100GB 的数据库，总占用依然是 100GB。

pg-meta:
  hosts:
    10.10.10.10: { pg_seq: 1, pg_role: primary }
  vars:
    pg_cluster: pg-meta
    pg_version: 18
    pg_databases:
      - { name: meta }  # <----- 待克隆的数据库
      - { name: meta_dev ,template: meta , strategy: FILE_COPY}  # bin/pgsql-db meta_dev

如果使用 XFS 文件系统（Linux 主流默认），还能获得实例级别的瞬间克隆能力：瞬间克隆出一个大实例，不占用额外存储，不影响线上业务。 再加上经典的集群 PITR 能力，总结起来，你可以在 实例、数据库、集群 三个层面快速克隆 PostgreSQL，并回滚到保留期内的任意时间点。

为了进一步降低 PITR 的门槛，我们还把 PITR 能力做到了 pig 命令行工具里：运行 pig pitr，它自动帮你傻瓜式地处理一切。 将数据库集群以原地/增量/快速高效的方式，恢复到你指定的目标点。 这样，无论是新手还是 AI Agent 都能轻松利用起来，门槛就得做到这种程度才够劲。

IaC 增强：更多精细的定制旋钮

以前 Pigsty 不提供删除用户和删除数据库的能力，因为删除操作很危险，涉及清理依赖对象和权限的复杂 SOP。 但用户确实有这个需求：配置复杂资源搞糊了，想删掉重来。 这次我们实现了删库和删用户功能。 不要小看删除用户这样的功能 —— 看似简单，实际上要做好非常难：几乎所有的云数据库服务，都只支持很简单的删除 “裸用户”，一旦用户身上挂着依赖，系统直接报错。

v4 也调整了 IAC API 设计，新增并对齐了直到 PG 18 的新增可用参数。 例如，在用户层对角色继承的三个选项 ADMIN, INHERIT, SET 提供了定制支持。 你也可以为数据库指定额外的 Locale 参数，并指定 state 用于删除或者重建数据库与用户，以及数据库内的 Schema 和 Extension。

现在 HBA 规则定义支持了额外的 order 字段，这意味着你可以明确指定每条规则的优先级顺序。 同时内网网段的定义，也可以进行定制与修改了，并与默认防火墙策略保持一致。 PG 有了自己专门的 Crontab 列表，与系统的全局定时任务区别开来。

此外，我们还改善了许多细节，对几乎所有的参数位点都做了防注入处理，并单独处理了一些 PG 特殊的列表参数，细节就不过多展开了。 最终的效果是，你可以用 IaC 的方式定制 PostgreSQL 集群里面的各种细节。 从数据库，用户，继承关系，权限，HBA，服务，到扩展，模式，一步到位，拉起可以直接供业务生产就绪的数据库集群。 而且这种 IaC 配置文件定义的方式，对于 DBA 与 DBA Agent 来说，都非常自然友好。

Vibe 实战：品味与验收是护城河

最后来聊一下 Pigsty v4 的工程实践吧，Pigsty v4.0 中 九成以上的代码都是 Claude Code 编写的。 我只负责三件事：提出思路，设计 API，验收结果。方法论分四个阶段：

设计：扮演产品经理，与 AI 探讨生成设计文档。API 设计的品位 CC 还不够好，这部分必须亲自操刀。

实现：新 Session 让 AI 实现代码，完成后让它进行 10 轮自我反思与修正，每轮给出评审意见直至满意。

Review：开启另一个 Session，让 AI 在虚拟机沙箱中进行自动化测试。

验收：最后手工测试验证。

Claude Code 像一个聪明但略缺领域经验的天才实习生。 只要你的直觉正确、方向对了，它就能把细节做得很到位。 这种老带新结对编码效率很高，我通常并行推进三个 User Story —— CC 写代码极快，瓶颈卡在我身上。

通常确定设计方案之后，CC 的一次出活率能到 90%+，剩下 10% 就要多次迭代优化拉扯了。 特别是对于 RDS 这种几乎没有公开资料的领域，需要各种人工指导才能达到最终的满意效果。

Claude Code 有两件事情做得还不太理想： 一是 API 设计，这个还是需要品位来把关，CC 只能提供一些思路与建议； 二是验证效率，目前瓶颈在于人工验证的速度（卡在我身上），因为执行冒烟测试 SOP 太慢。

这给我一个启示：在 Agent 编码时代，设计的品味与验证的能力才是真正的护城河。 硬核项目即便开源了代码，绝大多数人既没有二次开发能力，更缺乏 QA 能力——这才是壁垒所在。 代码会越来越 “便宜”，但 “把正确的东西做对” 依然昂贵。

这让我想到 SQLite 的模式：源代码公开在 public domain，但核心测试套件 TH3 是专有的。 在 AI 助手加持下，一个超级个体就能顶一个满编团队，引入外部贡献反而会拖慢节奏。 所以，Pigsty 也将采用类似路线：Open Source, but not Open Collaboration —— 只接受 Issue、特性请求与反馈，不再接受 PR。

完工软件：质量达到满意状态

正如《从AGPL到Apache：Pigsty 协议变更的思考》里说过的，我能给 v4.0 这个版本打一个 90 分的水准。 SOTA AI 给出的结论也基本差不多：在 PostgreSQL 服务质量上，免费的 Pigsty 已经优于头部云 RDS ，在开源方案中也达到了顶尖水准。

所以老冯觉得也差不多了，在文章开头说，Pigsty v4.0 可以称之为 “Finished Software”。

但 “完成” 不是 “归档”。软件的生命周期里，Finished 意味着它已经足够好、足够稳定、足够让人放心地用于生产。 就像一把好刀，开刃完成了，接下来是长期的使用、保养、传承。Pigsty 我会持续维护——Bug 修复、版本跟进、扩展打包，有 AI 帮助这些工作不费多少时间，每年跟进一个 PG 大版本就好。 剩下的 10 分，留给生态、产品、商业服务去生长。

而我的精力，终于可以腾出手来，正式转向那个三年前就埋下的伏笔。

进入 AI 时代：为 Agent 而生

三年前，老冯写下 《数据库需求金字塔》 ，就已经将 智能自治数据库 列为终极目标。 彼时这只是愿景，而今天，它真正成为可能。

Pigsty 从第一天起就坚持 IaC + CLI，把 GUI 只用于观测而非管控。很多人不理解：为什么不做个漂亮的控制台？

现在答案清晰了——因为我们在等 Agent。

Agent 不需要点按钮，它需要读配置、调 API、执行命令。Pigsty 的架构天然为程序化管理而生。 当别人还在琢磨如何让 AI 操作图形界面时，Pigsty 用户已经可以让 Claude Code 直接读取 pigsty.yml，理解整个基础设施，然后动手干活了。

这就是"进入 AI 时代"的真正含义：不是给软件加个 AI 功能，而是让软件本身成为 AI 的原生栖息地。

为此，我准备了两翼：

PIG —— 原本只是个包管理器，在 v1.0 中重新定位为 PostgreSQL 生态的 Agent Native CLI， 完整接管数据库、连接池、高可用、备份、接入的全生命周期。它是 Agent 操作 PostgreSQL 的双手。

PIGLET.RUN —— 一个以 PostgreSQL 为中心的 Agent 运行时。 轻量化的 Pigsty 子发行版，用户动动嘴，就能生成完整的、带有数据库的复杂应用。它是 Agent 栖息的土壤。

而 Pigsty 本身，要成为那个让你在 AI 时代依然保持确定性的基础设施底座 —— 敢让 Agent 放手干活，也敢在它干错的时候一键回到昨天。

用 IaC 描述它，用观测理解它，用权限约束它，用 PITR 纠正它。 这不是 “又一个 PostgreSQL 装机脚本”，而是一整套把复杂系统关进笼子里的工程方法。

数据是系统的命脉，数据库是守护命脉的心脏。

Agent 正在成为新的生命形式。它们会思考、会行动、会犯错、会学习。

而每一个生命，都需要一颗可靠的心脏。

Pigsty v4.0，为这个时代而生。

欢迎入局。

v4.0.0 发行注记

快速上手 

curl https://pigsty.cc/get | bash -s v4.0.0

320 个提交，604 文件变更，+118,655 / -327,552 行

发布日期: 2026-01-28 | GitHub | 英文文档 | 中文文档

亮点特性

  • 可观测性革命: Prometheus → VictoriaMetrics（10x 性能提升），Loki + Promtail → VictoriaLogs + Vector
  • 安全加固: 自动生成强密码、etcd RBAC、防火墙/SELinux 模式、权限收紧、Nginx Basic Auth
  • Docker 支持：支持在 Docker 容器中运行 Pigsty
  • 新增模块：Juice，提供将 PG 挂载为文件系统并进行 PITR 的能力
  • 新增模块：VIBE，提供 Claude Code、Jupyter、VS Code Server、Node.js 的配置与可观测性
  • 数据库管理: pg_databases state（create/absent/recreate）、strategy 瞬间克隆数据库
  • PITR 与分叉: /pg/bin/pg-fork CoW 瞬间克隆、pg-pitr 增强支持 PITR 前备份
  • 高可用增强: pg_rto 提供四档 RTO 预置参数（fast/norm/safe/wide），pg_crontab 定时任务
  • 多云 Terraform: AWS、Azure、GCP、Hetzner、DigitalOcean、Linode、Vultr、腾讯云模板
  • 许可证变更: AGPL-3.0 → Apache-2.0

基础设施软件包更新

MinIO 开始使用 pgsty/minio fork RPM/DEB.

软件包 版本 软件包 版本
victoria-metrics 1.134.0 victoria-logs 1.43.1
vector 0.52.0 grafana 12.3.1
alertmanager 0.30.1 etcd 3.6.7
duckdb 1.4.4 pg_exporter 1.1.2
pgbackrest_exporter 0.22.0 blackbox_exporter 0.28.0
node_exporter 1.10.2 minio 20251203
pig 1.0.0 claude 2.1.19
opencode 1.1.34 uv 0.9.26
asciinema 3.1.0 prometheus 3.9.1
pushgateway 1.11.2 juicefs 1.4.0
code-server 4.100.2 caddy 2.10.2
hugo 0.154.5 cloudflared 2026.1.1
headscale 0.27.1

Docker 支持

Pigsty 现在支持在 Docker 容器 中运行，完整支持 systemd，兼容 macOS (Docker Desktop) 与 Linux。

快速开始：

cd ~/pigsty/docker; make launch    # = make up config deploy

新增模块

v4.0.0 新增两个 可选模块，不影响 Pigsty 核心功能，按需安装即可：

JUICE 模块：JuiceFS 分布式文件系统

  • 使用 PostgreSQL 作为元数据引擎，支持利用 PITR 恢复文件系统
  • 支持多种存储后端：PostgreSQL 大对象、MinIO、S3
  • 支持多实例部署，每个实例暴露 Prometheus 指标端口
  • 新增 node-juice 仪表盘监控 JuiceFS 状态
  • 新增剧本 juice.yml 用于部署和管理 JuiceFS 实例
  • 参数：juice_cache、juice_instances

VIBE 模块：AI 辅助编程沙箱环境（整合了 Code-Server、JupyterLab、Node.js 与 Claude Code）

  • Code-Server：浏览器中的 VS Code

    • 在节点上部署 Code-Server，通过 Nginx 反向代理提供 HTTPS 访问
    • 支持 Open VSX 和 Microsoft 两种扩展市场
    • 设置 code_enabled: false 可禁用
    • 参数：code_enabled、code_port、code_data、code_password、code_gallery

  • JupyterLab：交互式计算环境

    • 在节点上部署 JupyterLab，通过 Nginx 反向代理提供 HTTPS 访问
    • 支持 Python 虚拟环境配置，便于安装数据科学库
    • 设置 jupyter_enabled: false 可禁用
    • 参数：jupyter_enabled、jupyter_port、jupyter_data、jupyter_password、jupyter_venv

  • Node.js：JavaScript 运行时环境

    • 安装 Node.js 和 npm 包管理器
    • 当 region=china 时自动配置中国 npm 镜像
    • 设置 nodejs_enabled: false 可禁用
    • 参数：nodejs_enabled、nodejs_registry

  • Claude Code：AI 编程助手 CLI 配置

    • 配置 Claude Code CLI，跳过 onboarding 流程
    • 内置 OpenTelemetry 可观测性配置，将指标和日志发送到 VictoriaMetrics/VictoriaLogs
    • 新增 claude-code 仪表盘监控 Claude Code 的使用情况
    • 设置 claude_enabled: false 可禁用
    • 参数：claude_enabled、claude_env

  • 新增剧本 vibe.yml 用于部署完整的 VIBE 模块

  • 配合 conf/vibe.yml 配置模板，可快速搭建完整的 AI 辅助编程沙箱环境

  • 公共参数：vibe_data（默认 /fs）指定 VIBE 工作空间目录

PG 扩展更新

主要扩展添加 PG 18 支持：age, citus, documentdb, pg_search, timescaledb, pg_bulkload, rum 等

新增扩展：

重要更新：

扩展 旧版本 新版本 备注
timescaledb 2.23.x 2.24.0 +PG18
pg_search 0.19.x 0.21.4 ParadeDB, +PG18
citus 13.2.0 14.0.0 分布式 PG, +PG18 预发布
documentdb 0.106 0.109 MongoDB 兼容, +PG18
age 1.5.0 1.7.0 图数据库, +PG18
pg_duckdb 1.1.0 1.1.1 DuckDB 集成
vchord 0.5.3 1.0.0 VectorChord
vchord_bm25 0.2.2 0.3.0 BM25 全文搜索
pg_biscuit 1.0 2.2.2 Biscuit 认证
pg_anon 2.4.1 2.5.1 数据脱敏
wrappers 0.5.6 0.5.7 Supabase FDW
pg_vectorize 0.25.0 0.26.0 向量化
pg_session_jwt 0.3.3 0.4.0 JWT 会话
pg_partman 5.3.x 5.4.0 分区管理, PGDG
pgmq 1.8.0 1.9.0 消息队列
pg_bulkload 3.1.22 3.1.23 批量加载, +PG18
pg_timeseries 0.1.7 0.2.0 时序扩展
pg_convert 0.0.4 0.1.0 类型转换
pg_clickhouse 0.1.2 0.1.3 ClickHouse FDW

pgBackRest 更新至 2.58，支持 HTTP。

可观测性

  • 使用全新的 VictoriaMetrics 替代 Prometheus，用几分之一的资源实现数倍的性能
  • 使用全新的日志收集方案：VictoriaLogs + Vector，取代 Promtail + Loki
  • 统一调整了所有组件的日志格式，PG 日志使用 UTC 时间戳（log_timezone）
  • 调整了 PostgreSQL 日志的轮换方式，使用按周循环截断日志轮转模式
  • 在 PG 日志中记录超过 1MB 的临时文件分配，在特定模版中启用 PG 17/18 日志新参数
  • 新增了 Nginx / Syslog / PG CSV / Pgbackrest / Grafana / Redis / etcd / MinIO 等日志的 Vector 解析配置
  • 注册数据源现在会在所有 Infra 节点上进行，Victoria 数据源将自动注册入 Grafana
  • 新增 grafana_pgurl 参数，允许指定 Grafana 使用 PG 作为后端存储元数据库
  • 新增 grafana_view_password 参数，指定 Grafana Meta 数据源使用的密码
  • pgbackrest_exporter 的默认选项现在设置 120 秒的内部缓存间隔（原本为 600s）
  • grafana_clean 参数的默认值现在由 true 改为 false，即默认不清除
  • 新增指标收集器 pg_timeline，收集更实时的时间线指标 pg_timeline_id
  • 新增 pg:ixact_ratio 指标，监控空闲事务占比
  • pg_exporter 更新至 1.1.2，新增 pg_timeline 采集器，修复大量历史遗留问题
  • 修复 pg_recv 指标采集器的 slot name coalesce 问题
  • 启用 Blackbox ping 监控支持
  • 新增 node-vector 仪表盘，监控 Vector 日志收集器状态
  • 新增 node-juice 仪表盘，监控 JuiceFS 分布式文件系统状态
  • 新增 claude-code 仪表盘，监控 Claude Code AI 编程助手使用情况
  • PGSQL Cluster/Instance 仪表盘新增版本横幅显示
  • 所有仪表盘使用 compact JSON 格式，大幅减少文件体积

接口改进

剧本重命名

  • install.yml 剧本现在重命名为 deploy.yml 以更符合语义
  • 新增 vibe.yml 剧本，用于部署 VIBE AI 编程沙箱环境

pg_databases 数据库制备功能改进

  • 添加删库能力：可以使用 state 字段指定 create, absent, recreate 三种状态
  • 添加克隆能力：数据库定义中使用 strategy 参数指定克隆方法
  • 支持较新版本引入的 locale 配置参数：locale_provider，icu_locale，icu_rules，builtin_locale
  • 支持 is_template 参数，将数据库标记为模板数据库
  • 添加了更多类型检查，避免了字符类参数的注入
  • 允许在 extension 中指定 state: absent 以删除扩展

pg_users 用户制备功能改进

  • 新增参数 admin，类似 roles，但是带有 ADMIN OPTION 权限可以转授
  • 新增 set 和 inherit 选项定制用户角色属性

pg_hba 访问控制改进

  • 支持 order 字段，允许指定 HBA 规则的排序优先级
  • 支持 IPv6 的 localhost 访问
  • 允许通过 node_firewall_intranet 指定 HBA 信任的 “内网网段”

其他改进

  • 新增 Supabase 角色的默认权限配置
  • node_crontab 在 node-rm 时会自动恢复原始 crontab
  • 新增 infra_extra_services 参数用于首页额外服务入口导航

参数优化

I/O 参数

  • pg_io_method 参数：auto, sync, worker, io_uring 四种方式可选，默认 worker
  • maintenance_io_concurrency 设置为 100（如果使用 SSD）
  • effective_io_concurrency 从 1000 减小为 200
  • file_copy_method 参数为 PG18 默认设置为 clone，提供瞬间克隆数据库的能力

复制槽与日志参数

  • idle_replication_slot_timeout 默认 7d，crit 模板 3d
  • log_lock_failures：oltp, crit 模版开启
  • track_cost_delay_timing：olap, crit 模版开启
  • log_connections：oltp/olap 开启认证日志，crit 开启全部日志

高可用参数

  • 新增 pg_rto_plan 参数，整合 Patroni 与 HAProxy 的 RTO 相关配置
    • fast: 最快故障转移（~15s），适合对可用性要求极高的场景
    • norm: 标准模式（~30s），平衡可用性与稳定性（默认）
    • safe: 安全模式（~60s），减少误判概率
    • wide: 宽松模式（~120s），适合跨地域部署
  • pg_crontab 参数：为 postgres dbsu 配置定时任务
  • 对于 PG17+，如果 pg_checksums 开关关闭，在 Patroni 初始化集群时显式禁用校验和
  • Crit 模板启用 Patroni 严格同步模式

备份恢复参数

  • PITR 默认 archive_mode 改为 preserve，确保恢复后保留归档能力
  • pg-pitr 支持恢复前自动备份数据

其他改进

  • 修复了 duckdb.allow_community_extensions 总是生效的问题
  • 现在 pg_hba 与 pgbouncer_hba 支持 IPv6 的 localhost 访问

架构改进

目录与门户

  • 在 Infra 节点上，设置固定的 /infra 软连接指向 Infra 数据目录 /data/infra
  • 现在 Infra 的数据默认放置于 /data/infra 目录下，这使得在容器中使用更为便利
  • 本地软件仓库现在放置于 /data/nginx/pigsty，/www 现在作为软链接指向 /data/nginx 确保兼容
  • DNS 解析记录现在放置于 /infra/hosts 目录下，解决了 Ansible SELinux 竞态问题
  • 默认首页域名从 h.pigsty 更名为 i.pigsty，新增中文首页支持

运维脚本

  • 新增了 /pg/bin/pg-fork 脚本，用于快速创建 CoW 副本数据库实例
  • 调整 /pg/bin/pg-pitr 脚本，现在可以用于实例级别的 PITR 恢复，支持恢复前自动备份
  • 新增 /pg/bin/pg-drop-role 脚本，用于安全删除用户角色
  • 新增 bin/pgsql-ext 脚本，用于安装 PostgreSQL 扩展
  • 恢复 pg-vacuum 和 pg-repack 脚本

新增剧本

  • juice.yml：部署 JuiceFS 分布式文件系统实例
  • vibe.yml：部署 VIBE AI 编程沙箱环境（含 Code-Server、JupyterLab、Node.js、Claude Code）

模块改进

  • 显式安装 cron/cronie 包，确保定时任务功能在最小化安装的系统上可用
  • UV Python 包管理器从 infra 模块迁移至 node 模块，新增 node_uv_env 参数指定虚拟环境路径
  • pg_remove/pg_pitr 移除 etcd 元数据的任务，现在不再依赖 admin_ip 管理节点，而在 etcd 集群上执行
  • 36 节点仿真模板 simu 简化为 20 节点的版本
  • 适配上游变化，移除 PGDG sysupdate 仓库，移除 EL 系统上所有 llvmjit 的相关包
  • 为 EPEL 10 / PGDG 9/10 仓库使用操作系统完整版本号（major.minor）
  • 允许在仓库定义中指定 meta 参数，覆盖 yum 仓库的定义元数据
  • 确保 Vagrant libvirt 模板默认带有 128GB 磁盘，以 xfs 挂载于 /data
  • 确保 pgbouncer 不再将 0.0.0.0 监听地址修改为 *
  • 新增 10 节点、Citus 等 Vagrant 配置模板
  • 恢复 EL7 系统兼容性支持

系统调优

  • 基于实际工作负载调整 systemd 服务的 NOFILE 限制
  • 修复 tuned profile 激活问题（通过重启 tuned 服务）
  • 添加 PostgreSQL systemd 服务运行时目录
  • 修复 ip_local_port_range 起止值奇偶对齐问题

多云支持

  • 多云 Terraform 模板：AWS、Azure、GCP、Hetzner、DigitalOcean、Linode、Vultr、腾讯云

安全改进

密码管理

  • configure 现在支持 -g 参数自动生成随机强密码，避免使用默认密码带来的安全隐患
  • 更改了 MinIO 模块的默认密码，避免与众所周知的默认密码冲突

防火墙与 SELinux

  • 移除 node_disable_firewall，新增 node_firewall_mode，支持 off, none, zone 三种模式
  • 移除 node_disable_selinux，新增 node_selinux_mode，支持 disabled, permissive, enforcing 三种模式
  • 为 HAProxy、Nginx、DNSMasq、Redis 等组件配置了正确的 SELinux 上下文

访问控制

  • 启用了针对 etcd 的 RBAC，每个集群现在只能管理自己的 PostgreSQL 数据库集群
  • etcd root 密码现在放置于 /etc/etcd/etcd.pass 文件中，仅对管理员可读
  • 将 admin_ip 添加到 Patroni API 允许访问的 IP 列表白名单中
  • 总是创建 admin 系统用户组，patronictl 配置收紧为仅限 admin 组用户访问
  • 新增 node_admin_sudo 参数，允许指定/调整数据库管理员的 sudo 权限模式（all/nopass）
  • 收回了所有非 root 用户对可执行脚本的拥有权限

证书与认证

  • 新增 Nginx Basic Auth 支持，可以为 Nginx Server 设置可选的 HTTP Basic Auth
  • 修复 ownca 证书有效期问题，确保了 Chrome 可以识别自签名证书
  • 新增 vip_auth_pass 参数用于 VRRP 认证

其他

  • 修复了若干 ansible copy content 字段为空时报错的问题
  • 修复了 pg_pitr 中遗留的一些问题，确保 Patroni 集群恢复时没有竞态条件
  • 使用 mode 0700 保护 files/pki/ca 目录

问题修复

问题 说明
ownca 证书有效期 Chrome 兼容性问题 正确设置 ownca_not_after 参数
Vector 0.52 syslog_raw 解析问题 适配新版本 Vector 的解析格式变化
pg_pitr 多副本 clonefrom 时序问题 修复 Patroni 集群恢复的竞态条件
Ansible SELinux dnsmasq 竞态条件 将 DNS 记录移至 /infra/hosts 目录
EL9 aarch64 patroni & llvmjit 问题 热修复 ARM64 架构兼容性问题
Debian groupadd 路径问题 修复 Debian 系统用户组添加路径
空 sudoers 文件生成问题 防止生成空的 sudoers 配置文件
pgbouncer pid 路径 使用 /run/postgresql 替代旧路径
duckdb.allow_community_extensions 始终生效 修复 DuckDB 扩展配置问题
pg_partman EL8 上游问题 因上游问题隐藏 EL8 上的 pg_partman 扩展
HAProxy 服务模板变量路径 修复变量引用路径错误
Redis remove 任务变量名 修复 redis_seq 到 redis_node 变量名
MinIO reload handler 无效 移除无效的 reload 处理器
vmetrics_port 默认值 修正为正确的 8428 端口
pg-failover-callback 脚本 处理所有 Patroni 回调事件
pg-vacuum 事务块问题 修复事务块处理逻辑
pg_sub_16 并行逻辑复制 worker 添加 PG16+ 并行逻辑复制支持
FerretDB 证书 SAN 和重启策略 修复证书配置和服务重启策略
Polar Exporter 指标类型 修正监控指标类型定义
proxy_env 包安装缺失 修复代理环境变量未传递问题
patroni_method=remove 服务问题 修复移除模式下 postgres 服务配置
Docker 默认数据目录 更新为正确的默认数据目录路径
EL10 缓存兼容性 修复 EL10 系统上的缓存问题
etcd/MinIO 移除时清理不完整 修复 systemd 服务和 DNS 条目清理
IvorySql 18 file_copy_method 修复 IvorySql 18 不支持 clone 方法问题
tuned profile 激活 通过重启 tuned 服务修复激活问题

参数变化

新增参数

参数 类型 默认值 说明
node_firewall_mode enum none 防火墙模式：off/none/zone
node_selinux_mode enum permissive SELinux 模式
node_firewall_intranet string - HBA 信任的内网网段
node_admin_sudo enum nopass 管理员 sudo 权限级别
pg_io_method enum worker I/O 方法：auto/sync/worker/io_uring
pg_rto_plan dict - RTO 预设：fast/norm/safe/wide
pg_crontab list [] postgres dbsu 定时任务
vip_auth_pass string - VRRP 认证密码
grafana_pgurl string - Grafana PG 后端连接字符串
grafana_view_password string DBUser.Viewer Grafana Meta 数据源密码
infra_extra_services list [] 首页额外服务入口
juice_cache path /data/juice JuiceFS 共享缓存目录
juice_instances dict {} JuiceFS 实例定义
vibe_data path /fs VIBE 工作空间目录
code_enabled bool true 是否启用 Code-Server
code_port port 8443 Code-Server 监听端口
code_data path /data/code Code-Server 数据目录
code_password string Vibe.Coding Code-Server 登录密码
code_gallery enum openvsx 扩展市场：openvsx/microsoft
jupyter_enabled bool true 是否启用 JupyterLab
jupyter_port port 8888 JupyterLab 监听端口
jupyter_data path /data/jupyter JupyterLab 数据目录
jupyter_password string Vibe.Coding JupyterLab 登录 Token
jupyter_venv path /data/venv Python 虚拟环境路径
claude_enabled bool true 是否启用 Claude Code 配置
claude_env dict {} Claude Code 额外环境变量
nodejs_enabled bool true 是否启用 Node.js 安装
nodejs_registry string '' npm registry，自动配置中国镜像
node_uv_env path /data/venv 节点 UV 虚拟环境路径，空则跳过
node_pip_packages string '' UV 虚拟环境中安装的 pip 包

移除参数

参数 说明
node_disable_firewall 由 node_firewall_mode 替代
node_disable_selinux 由 node_selinux_mode 替代
infra_pip_packages 由 node_pip_packages 替代
pgbackrest_clean 未使用参数，已移除
pg_pwd_enc 已移除，统一使用 scram-sha-256
code_home 由 vibe_data 替代
jupyter_home 由 vibe_data 替代

默认值变更

参数 变化 说明
grafana_clean true → false 默认不清除
effective_io_concurrency 1000 → 200 更合理的默认值
node_firewall_mode zone → none 默认不启用防火墙规则
install.yml 重命名为 deploy.yml 更符合语义

兼容性

操作系统 x86_64 aarch64
EL 8/9/10 ✅ ✅
Debian 11/12/13 ✅ ✅
Ubuntu 22.04/24.04 ✅ ✅

PostgreSQL: 13, 14, 15, 16, 17, 18

校验和 

9f42b8c64180491b59bd03016c26e8ca  pigsty-v4.0.0.tgz
db9797c3c8ae21320b76a442c1135c7b  pigsty-pkg-v4.0.0.d12.aarch64.tgz
1eed26eee42066ca71b9aecbf2ca1237  pigsty-pkg-v4.0.0.d12.x86_64.tgz
03540e41f575d6c3a7c63d1d30276d49  pigsty-pkg-v4.0.0.d13.aarch64.tgz
36a6ee284c0dd6d9f7d823c44280b88f  pigsty-pkg-v4.0.0.d13.x86_64.tgz
f2b6ec49d02916944b74014505d05258  pigsty-pkg-v4.0.0.el10.aarch64.tgz
73f64c349366fe23c022f81fe305d6da  pigsty-pkg-v4.0.0.el10.x86_64.tgz
287f767fbb66a9aaca9f0f22e4f20491  pigsty-pkg-v4.0.0.el8.aarch64.tgz
c0886aab454bd86245f3869ef2ab4451  pigsty-pkg-v4.0.0.el8.x86_64.tgz
094ab31bcf4a3cedbd8091bc0f3ba44c  pigsty-pkg-v4.0.0.el9.aarch64.tgz
235ccba44891b6474a76a81750712544  pigsty-pkg-v4.0.0.el9.x86_64.tgz
f2791c96db4cc17a8a4008fc8d9ad310  pigsty-pkg-v4.0.0.u22.aarch64.tgz
3099c4453eef03b766d68e04b8d5e483  pigsty-pkg-v4.0.0.u22.x86_64.tgz
49a93c2158434f1adf0d9f5bcbbb1ca5  pigsty-pkg-v4.0.0.u24.aarch64.tgz
4acaa5aeb39c6e4e23d781d37318d49b  pigsty-pkg-v4.0.0.u24.x86_64.tgz

17 - 从AGPL到Apache：Pigsty 协议变更的思考

原文发布于 VONNG。

Pigsty 是一个开箱即用、开源且本地优先的 PostgreSQL 数据库发行版，最近发布的 v4.0 是一个史诗级的大版本，整体有了一个整体的质变与飞跃。

也正好借这个发布窗口，我把一件惦记很久的事落地了：把 Pigsty 的许可证从 AGPLv3 改回 Apache 2.0。

德哥还专门写了篇文章聊这事儿（我看完确实笑出了声）。你可以先读他的版本，再来看我这个作者的第一人称心路历程： 为什么改、改了意味着什么，以及我对开源、生态、服务与商业化的整体判断。

digoal.webp

前生今世

Pigsty 刚诞生的时候，用的就是 Apache 2.0。

动机很朴素：我做个自己用得爽的作品，顺手开源出来让大家也能用上，顺便把业界使用 PostgreSQL 的姿势整体往前推一点。既然是这种心态，选 Apache 很自然：开放、宽松、少纠结。

后来到 2.0 版本，我把许可证改成了 AGPLv3。表面理由是：当时一些知名项目从 Apache 转向了 AGPLv3，Pigsty 也跟着受了传染。 但老实说，这只是“好解释”的版本。后来我认真研究过：它们的 AGPL 并不会“传染”到 Pigsty —— 我既没有把它们当库去链接，也没有去修改它们的代码。

更真实的原因其实是：那时我开始拿投资创业，要认真对商业结果负责，自然会考虑商业利益保护，于是选择了开源谱系里约束最强的许可证之一：AGPLv3。 同时我们也在许可与声明中明确表达过：对普通用户不追索、执行效果等同 Apache-2.0；AGPLv3 更像是“为同行/云厂商的极端白嫖场景保留一个选项”。

但实践证明：这个选项既没带来我想要的保护，反而带来了新的采用阻力。

后来公司清算了，我又回到了单人开发者的状态。说来也有意思：反而是现在有了稳定的咨询收入，我才能重新把 Pigsty 当成一开始那样 —— 送给世界的礼物。

AGPLv3 的糟糕实践

AGPL 的第一类问题很直观：它会在商业公司内部直接触发“法务红灯”。不少公司对 AGPL 的默认策略就是：先别碰——成本高、风险不清、审批慢。 你解释“我不追普通用户”“我实际不传染”，很多时候也没用。规则是规则，流程是流程。

我就遇到过很典型的对话：某云上数据库团队的人跟我聊方案，我提议他们在云服务器上直接用 Pigsty 自建，结果对方的反馈很干脆：

去年 PG 大会的时候，我就跟 OAI 的朋友聊过这个问题。我提议说：“你们在 Azure 上搞这个 PG，不如直接用他们的服务器上用 Pigsty 自建啊。” 他跟我说：“开源的可以考虑一下，但你这个用 AGPLv3 就不行啊”。

这类对话聊多了，你就会意识到：AGPLv3 是在给自己制造采用门槛 —— 不是技术门槛，是流程门槛，而流程门槛通常更难打穿。

第二类问题是：AGPL 也未必真能阻止你想象中的“白嫖”。 我举个真实出现的交付模式：某云厂商巨头的 SA 在云上替客户在云资源上部署 Pigsty，遇到问题再来找我做付费支持。对方确实借 Pigsty 完成了交付。 但在法律层面，AGPL 对这种“顾问 / 交付 / 私有部署”的模式杀伤力很有限：代码没以 SaaS 方式对外提供，不等于就触发你脑补的“云白嫖反制”。

featured.webp

AGPL 在很多场景里更像是：把想认真用你软件的人劝退了，却未必能起到你想象中的效果。 这个变化更是体现在数据层面上：从切到 AGPL 开始，Pigsty 的开源采用增速明显放缓 —— 以前像指数曲线那样飞，现在更像线性爬坡。这种“别扭”的状态本身就说明了问题。

几年前《DDIA》的作者 Martin Kleppmann 也提过类似观点：GPL/AGPL 并不能很好解决云时代的价值分配问题。 如果你真想限制云厂商，你需要的往往不是开源许可证，而是“源码可用”体系（ELv2、SSPL、BSL 之类）， 甚至需要的是产品路线本身（比如本地优先、可分发、生态绑定），而不是寄希望于 GPL 家族在云上替你伸张正义。

所以我后来越想越确定：AGPL 既不够开源友好，也不够反云有效。两头都不讨好。

那为什么不用 ELv2 / SSPL / BSL？

既然 AGPL 不好使，那一个很自然的追问就是：你不是一直喊“下云”吗？那你直接上 ELv2（Elastic License v2）这种 “对普通用户几乎等同 Apache、但明确限制云厂商”的许可证，不就完事了吗？

说实话，我认真考虑过。尤其是现在这个时间点：Pigsty 趋近“完成软件”。我并不缺 PR，也不靠开源协作才能推进功能。 今天的现实是：你给我一个 idea，我用 Claude 之类的工具，能非常快地把它做出来。对我来说，社区最重要的价值不是代码贡献，而是：

  • 真实场景的反馈与问题暴露
  • 可复用的模板与最佳实践
  • 案例、口碑、传播与生态连接

在这种前提下，“我到底需不需要一个严格意义上的 OSI 开源许可证”，这个问题就变得很尖锐。 但我最后还是没走 ELv2。原因只有一个核心：那不是我想做的事。

我真正想做的，是把 Pigsty 做成“数据库世界的 Debian”。 Debian 不是靠“限制谁不能用”成为 Debian 的。它靠的是：开放、包容、可复用、可分发， 最后长成了一个生态位 —— 主流发行版、上游、标准、基础设施。

做数据库世界的 Debian

我在公开演讲《立足中国，面向全球的 PostgreSQL 发行版》里说过： Pigsty 的目标是成为 PostgreSQL 世界里的 Debian —— 一个面向全球、真正好用、可分发、可复用的主流发行版。

我判断：最近这两年将是数据库世界与软件形态剧烈变化的窗口期。 AI、Agent、基础设施范式迁移，会把 “谁是默认选项” 这件事重新洗牌。

PostgreSQL 已经成为数据库世界的 Linux 内核，而发行版之争才刚刚拉开序幕。 这种历史窗口并不常见。Pigsty 已经拿到了一张参赛门票，我不打算错过这场大戏。

而要在这个窗口期里抓住机会，成为一个主流数据库发行版，靠的不是 “许可证当武器”，而是：

  • 让用户用得爽、用得稳
  • 让厂商能集成、能二次分发
  • 让 ISV 有钱赚、有路走
  • 让开发者/运维/DBA 都能有收益

这套激励结构要成立，宽松许可证几乎是必选项。 它代表姿态，也代表诚意：欢迎使用、欢迎集成、欢迎分发、欢迎做你自己的版本。

说得更直白一点：欢迎来“白嫖”。

当然边界要讲清楚：拿去卖无所谓，千万别瞎吹什么 100% 自研国产数据库。

开源何须惧白嫖？

很多人问我：在大家都从开源转 “源码可用”、许可证越来越收紧的大背景下，你为什么反而逆势回到 Apache？你不怕被白嫖吗？你还怎么赚钱？

我的想法很简单：如果你害怕被白嫖、又指望靠许可证直接变现，那干脆别开源，卖商业软件就好了；如果你选择了真开源，就要接受它的基本现实：它会被使用、会被集成、会被二次分发。 应该把这个东西当成一个送给世界的礼物。把开源当成一种娱乐与公益来做 —— 更符合它本来的样子。就像 Linus 祖师爷自传说的 —— Just for Fun。

当然，道德层面，我也看不上某些云厂商今天搞个 “ClxxdBot”，明天嫖个 “SxxxBase”， 拿开源项目套壳引流，卖自家服务器和服务，看起来很“聪明”，其实很掉价的行为。 但这一招对 Pigsty 没用，它不是云厂商的菜，它就是云数据库饭碗本身。

头部云厂商本身都有自己的 RDS/PG 服务，深度绑定自家云底座。他们真要把 Pigsty 拿去做成 RDS，反而很别扭 —— 这等于用别人的旗子砸自己的招牌。

老冯虽然倡导 “下云”，但主要针对的是云数据库这样的 PaaS。你能下到 IDC 自建当然好，但是用云上的服务器自建也不错； 云 IaaS 除了云盘实在太拉垮，其他东西并没有什么大问题 —— 也有那种 NVMe 实例存储的机器，合适就用没毛病。

所以对于那些没有成熟托管 PG 服务、但想把“自建 PG 交付”做成能力的厂商与集成方，我的态度很明确：欢迎。把朋友搞得多多的，比“拿许可证当棍子”更重要。

新定位：从“发行版”进化成“元发行版”

使用宽松的许可证，还有一个考虑是 —— Pigsty 的定位已经从 “一个 PG 发行版”，逐渐变成了一个元发行版（Meta Distribution）。

Pigsty 在设计之初的理念就是 —— 一切皆可定制。你可以根据自己的需求，通过简单的配置，轻松实现各种定制化场景。 Pigsty 可以提供完整的工具箱与基础设施，以及 PG 生态最大，最全面的二进制扩展分发目录与仓库。 你可以基于 Pigsty 定制出满足自己需求的子发行版，就像 Linux 世界从 Debian/Red Hat 这类主干发行版，长出无数定制分支一样。

我最近做的新项目： PIGLET.RUN（小猪快跑/PIGSTY 轻量 AI 沙箱运行时）就是一个例子， 在 Pigsty 单机模板的基础上添加了 Vibe Coding 工具箱，让你在云端一键拉起 Claude Code，VS Code 等全家桶服务。这就是一个 PIGSTY 的第一方子发行版。

你可以把内核换掉，把这个 PG 内核换成你自己的；或者你自己做了一些扩展、开发了一些软件，把它们打进去，做成你自己的 PG 发行版。 老冯觉得对于 PG内核厂商 来说这是个大好事 —— 本来一个光板无毛的 RPM 内核包，现在变成了“高可用、备份恢复、监控、IaC、离线交付”全套齐活，交付给客户价值直接上一个量级。

meta-distro.webp

其实之前在 v3 的时候，我们就提供了使用定制 PG 内核的能力。你可以使用好几种不同风味的 PostgreSQL 内核一键拉起。 其实严格来说，这每一个内核的支持都可以作为一个新的子发行版。Percona TDE，Supabase，OrioleDB，PolarDB，IvorySQL，AlloyDB 等等。 你可以把他们做成 PolarStyle，IvoryStyle，HaloStyle 这样的发行版。你甚至可以用 Claude Code 在里面写个 MySQL 的 Ansible 模块剧本，做一个 MysqlStyle 的发行版。

要让“元发行版”这件事成立，许可证必须足够宽松。否则你一边喊“欢迎分发”，一边写“分发会触发义务”，生态是长不起来的。 我理想中的终局是：Pigsty 未来形成某种治理结构，甚至像 Debian 那样出现委员会与共建机制。目标很大，但大才有趣。

关键契机：完成的软件

为什么选在 v4.0 这个时间点切回 Apache？因为 v4.0 这个版本，是一个里程碑式的版本，达到了一个 “完成软件”（Finished Software） 的状态。

如果我以自己能达到的巅峰水准为 100 分基准，那么 Pigsty 本体已经达到了 90 分的水平，作为参照的话，我给 AWS RDS 大概能打个 80 分。

当然这事老冯自己没法说，容易王婆卖瓜。所以我还特意后来我也特意找了 SOTA AI 三件套（GPT、Claude、Gemini）， 要求他们客观公正地进行分析给我一个评估对比，结果基本也是这样的：

comment.jpg

RDS PG 的粗略评估： Claude & ChatGPT

这个评价代表在主流 AI 的认知中，Pigsty 的水平表现，那么问题就来了？ 如果你把一个免费的产品，做到了 90 分的水平，那收费的 80 分服务咋办。 所以差不多了，再做下去，别说把云数据库和同行都卷死了，自己说不定也卷没了 —— 毕竟老冯卖的就是把 90 分自助免费服务提升到 100 分的专家咨询服务呀。

当然，老冯是非常欢迎 ISV 与 DBA 专家个体基于 Pigsty 打造自己的商业服务的。 这个市场大的很，俺怎么吃的完？你服务你的客户，我可以提供上游支持 —— 你要能搞定就自己搞，搞不定就找我兜底，这不就是一个健康的生态分工嘛

商业模式：站着挣钱

很多人也好奇：既然开源了，你靠什么挣钱？ 我特别欣赏的一种模式，是 VictoriaMetrics 创始人走的那条路。

这位大神程序员单枪匹马写出了 VictoriaMetrics，性能质量横扫了可观测性世界。 随后他搞了一家公司，主要提供企业技术支持，并将几个专业模块放在企业版里面。 不融资，没有压力，过的美滋滋。基本上 Pigsty 也是走的这种路子。

Pigsty 也有一个商业版，和开源版是同一套代码库，不过可以支持更多操作系统和更老的 PG 大版本。 里面有一个强力的命令行，DBA Agent，SKills 与 SOP，以及不开源的测试套件，里面有各种故障场景用例 —— 有点像 SQLite 的方式。

当然商业版不是重点，企业不会为你已经开源的部分付费，而只会为你提供的实际价值付费 —— 你能帮他把服务质量从 90 分做到 100 分，客户就很乐意为此付费。 这包括质保，答疑，疑难杂症兜底，以及把 PostgreSQL 干到超过 OpenAI 量级的实战经验，不会出现在 AI 语料中的 Know-How 知识与验证能力。

说到底，老冯卖的不是产品，产品都开源当礼物送给大家了，还卖什么。卖的还是老冯自己的经验与时间 —— 你可以白用 Pigsty，但总不能白嫖老冯吧？ —— 好在有了 AI 的帮助，大部分时候我只要负责问出正确的问题，并判断结果的正确性就行了，相当于加了几十倍时间杠杆，日常还是比较轻松的。

如果您在使用 Pigsty，觉得我做的事情对您有帮助，也欢迎用订阅支持一下。一来有商业承诺与契约，二来这也是对软件自由与开源生态的一种支持。

结语：Apache-2 不是妥协，是路线选择

所以概括起来，从 AGPLv3 回到 Apache 2.0，不是老冯变软了，也不是我天真了。

这是一个路线选择：Pigsty 要做数据库世界的 Debian —— 要做到这件事，开放与包容不是口号，是工程上的必需条件 —— 降低摩擦、扩大分发、建立生态。

Pigsty v4.0 已经正式发布可用，它我希望它能让更多人更轻松地享受 PostgreSQL 的乐趣：用好、管好、省钱、省心。

18 - 震惊！它改成阿帕奇开源协议了，不怕被云厂商“白嫖”吗？

原文发布于 VONNG。

原作者：digoal

此时此刻，Pigsty 就是真雷锋

早上看到一则大新闻，有感而发。

Pigsty 4.0 – The 'batteries-included' Postgres distribution hardens security, adds Docker support, and switches from AGPL-3.0 to Apache-2.0.

在云厂商与开源软件因为“分赃不均”而闹得不可开交的今天，数据库圈正上演着一出魔幻大戏。

当 Redis 抛弃 BSD，MongoDB 坚守 SSPL，就连曾经的浓眉大眼的 Elasticsearch 都把协议改得让开发者头秃时，一款国产 PostgreSQL 管控平台 Pigsty（目前发布了 4.0 版本）竟然反向操作：从相对严格的 AGPL-3.0 转向了近乎“大放水”的 Apache-2.0。

这是不怕被云厂商“白嫖”，还是另有玄机？

一、为什么大家都在“收紧”，它却在“开源”？

我们要先看清当前的数据库战场。Redis、Mongo、HashiCorp 转向商业化限制协议（如 BUSL 或 SSPL），核心痛点是：云厂商利用其强大的分发能力，直接托管开源内核获利，却不回馈社区。

但 Pigsty 4.0 敢于在这个节骨眼切换到 Apache-2.0，背后的逻辑非常硬核：

1. 差异化竞争：云厂商嫖内核，不嫖“管家”

云厂商（AWS 等）最核心的资产是 RDS 内核的魔改能力。对于管控逻辑，云厂商有自己的研发体系（如 AWS 的云管平台）。

  • 事实支撑： 云厂商需要的是多租户、自研存储底座的深度集成。Pigsty 是一套基于 Ansible 和离线部署的极致自动化管控，其设计理念是**“去中心化”** 和**“让用户在本地跑出云端体验”**。
  • 结论： 云厂商看不上这套“管家”代码，因为这跟他们的自研运维系统不兼容。

2. “农村包围城市”的开发者策略

Pigsty 修改协议，本质上是在降低企业法务的准入门槛。

  • AGPL-3.0 有一个“传染性”担忧：一旦修改代码并提供网络服务，就必须开源。这让很多大企业的内服架构师望而却步。
  • Apache-2.0 则是商业友好的“免死金牌”。Pigsty 4.0 通过这一举动，迅速吸纳那些被云厂商高昂续费割肉、想要回迁线下（Cloud Repatriation）的企业客户。

二、逆潮流而行的“理”与“据”

为什么说它是“真雷锋”？我们可以对比一下这组数据：

特性 传统云数据库 (RDS) 某些“伪开源”管控 Pigsty 4.0
开源协议 闭源/私有 SSPL / BSL (受限) Apache-2.0 (完全自由)
部署环境 仅限特定云 绑定特定系统 裸机、虚拟机、Docker (新增强化)
监控指标 基础指标 (约 50 个) 进阶指标 3000+ 指标 (行业天花板)

案例支撑：

某国内头部量化私募机构，在从云端 RDS 迁回自建机房时，面临最大的问题不是 PG 内核不会装，而是高可用自动化和监控报警没人写。如果用闭源管控，相当于从一个坑跳到另一个坑。Pigsty 4.0 切换协议后，该机构可以放心进行二次开发，集成到自有的风控系统中，而无需担心法务风险。

三、结论成立的前提与潜在风险

Pigsty 的“雷锋行为”并非盲目慷慨，其逻辑成立有赖于以下前提：

  1. 前提一：内核生态足够强大。 Pigsty 玩的是 PostgreSQL 的生态位。PG 本身是宽松的 BSD 类协议，如果 PG 倒了，管控软件就是空中楼阁。
  2. 前提二：服务变现能力。 放弃协议保护意味着放弃了“卖授权”的门票，转而考验其专家服务（订阅制）和商业版插件的盈利能力。

如果条件发生变化，结论会如何逆转？

  • 如果云厂商改变策略： 假设云厂商发现自研运维平台成本过高，转而直接封装 Pigsty 4.0 卖服务。由于 Apache-2.0 不强制回馈代码，Pigsty 可能会面临“被吸干”且无法获得反馈的窘境（类似当年的 Redis）。
  • 如果 PG 官方出了竞品： 如果 PostgreSQL 官方在未来版本中内置了同等强度的管控逻辑，Pigsty 的独特性将消失，协议再宽松也难以维持社区热度。

总结：这是最高级的商业防守

Pigsty 修改协议看似“自废武功”，实则是以退为进。在数据库厂商纷纷缩减自由度的 2026 年，它利用 Apache-2.0 建立了一个巨大的信任池，把“好用、免费、合规”这三张牌打成了一个王炸。它不是不怕被白嫖，而是它深知：在开源的世界里，不被白嫖意味着你还没做到行业标配。

你怎么看？欢迎留言讨论

发布版本：微信公众号转载页

19 - Pigsty v3.7：PG万磁王，PG18深度支持

原文发布于 VONNG。

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

Pigsty v3.7.0 正式发布，带来完整的 PostgreSQL 18 生产级支持，以及四个新操作系统的支持：Debian 13 与 EL 10 在 x86_64/ARM64 架构上的全部组合。扩展插件数量从 423 个增至 437 个，大量扩展同步更新至最新版本。

此外，Supabase、IvorySQL、PolarDB、Percona TDE 等内核均升级至最新版本，Prometheus、Grafana、DuckDB、Etcd 等基础组件也完成了一轮集中更新。

凭借在 PostgreSQL 扩展生态的突出贡献，Pigsty 在第八届 PostgreSQL 数据库生态大会上荣获 “PostgreSQL 万磁王” 奖。

PostgreSQL 18 成为默认版本

随着 PostgreSQL 18.1 的发布，PG 18 已具备生产就绪状态。Pigsty v3.7 正式将其设为默认版本。

PG 18 引入了多项重要特性：时态主键（Temporal Primary Key）、内置 UUIDv7、索引跳跃扫描（Index Skip Scan）、异步 I/O（AIO）、虚拟生成列、EXPLAIN 增强、OAuth 2.0 支持等。如果这些特性符合你的业务需求，现在是升级的好时机。

与此同时，11 月发布的 PG 13.23 将是 PG 13 的最后一个版本，该大版本正式进入 EOL 状态。Pigsty v3.7 是最后一个包含 PG 13 完整扩展支持的版本 —— 所有扩展均已重新编译，但后续将不再更新。

史诗级扩展更新

支持 PG 18 远不止内核部署那么简单。从 beta 阶段开始，Pigsty 就提供了 PG 18 的部署能力，但要将其作为生产默认版本，扩展生态的跟进至关重要。目前除 Citus 外，主流扩展均已支持 PG 18。为此，我们修复了数十个扩展的兼容性问题，并统一了 40 余个 Rust 扩展的 pgrx 版本。

这是一次史诗级的更新。PG 18 上的可用扩展数量达到 390-405 个（因发行版略有差异）。完整的扩展可用性信息可在 PGEXT.CLOUD 查阅。近三个月的扩展更新情况如下：

多个扩展迎来里程碑式更新：

  • pg_duckdb 1.1：代码质量显著改善，EL8 兼容性问题已修复
  • pg_mooncake 0.2：使用 Rust 重写，现为 pg_duckdb 的子扩展，两者可并存
  • VectorChord 1.0：正式发布稳定版
  • pg_search 0.20：ParadeDB 全文检索扩展重大更新

支持 PG 18、Debian 13、EL 10 意味着编译测试矩阵从 50 个（5 PG × 10 OS）扩展到 84 个（6 PG × 14 OS），增幅达 68%。仓库中的 RPM/DEB 包数量从四万余个增至六万余个。

为提升效率，我们将整个扩展构建流程完全自动化。现在只需启动容器，执行 pig build pkg <ext> 即可完成构建。这套扩展仓库与构建基础设施完全独立可用 —— 即使不使用 Pigsty，也可通过 YUM/APT 直接安装扩展，所有代码采用 Apache-2.0 许可证开源。

凭借这一贡献，Pigsty 在第八届 PostgreSQL 数据库生态大会上荣获"PostgreSQL 万磁王"奖。

新增操作系统支持：EL 10 与 Debian 13

本版本新增四个操作系统支持，主线支持总数达到 14 个。

适配过程中的主要挑战：

  • EL 10 Ansible 缺失：官方仓库缺少 ansible-collection-community-crypto，我们将 EL9 版本移植并打包
  • Ansible 2.19 破坏性变更：大量语法不兼容，进行了全面适配确保新老版本均可正常工作
  • LLVM 版本升级：EL9/EL10 上 PGDG 仓库从 LLVM 19 升级至 LLVM 20，引入兼容性问题
  • ARM64 仓库调整：el10.aarch64 的 PGDG 仓库经历多轮调整
  • 依赖变动频繁：上游包依赖关系持续变化

这也是我们不建议用户自行折腾 PostgreSQL 部署的原因之一：很多时候问题并非操作失误，而是上游变更导致的依赖断裂。使用 Pigsty 离线安装包可以锁定特定时刻的完整依赖，确保部署的稳定性。

维护策略调整：Pigsty 将仅维护各系列最近两个大版本。随着 EL 10 与 Debian 13 的加入，EL 8、Debian 11、Ubuntu 20.04 将不再主动更新（支持不移除），新扩展包与测试流程不再覆盖这些老系统。

多内核同步更新

除原生 PostgreSQL 内核外，本版本同步更新了多个衍生内核：

内核 更新内容
Supabase 全部 Docker 镜像更新至最新，底层升级至 PG 18
IvorySQL 从 4.5 升级至 5.0，兼容 PG 18.0
Percona TDE 透明加密内核从 PG 17.5 兼容升级至 PG 18.1 兼容
PolarDB 发布 15.15.5.0，新增 Debian 13/EL 10 的 RPM/DEB 包
FerretDB 更新至 2.7，底层 DocumentDB 升级至 0.107
OpenHalo / OrioleDB 新增 Debian 13 与 EL 10 支持

这些内核均可在新操作系统上平滑使用（Babelfish 除外），进一步巩固了 Pigsty 作为"元发行版"（Meta-Distribution）的定位 —— 一个可以开箱即用体验各种 PostgreSQL 风味的统一平台。

参数模板优化

针对 PG 18 与新场景优化了默认参数模板：

  • 优化 CPU、进程、线程与并行查询相关参数配置
  • 确保各类扩展拥有充足的 background worker 资源
  • 放宽 OLTP 模板对并行查询的限制
  • 新增维护保养、故障排查、误删恢复等 SOP 文档

愿景：PostgreSQL 生态的 Ubuntu

Pigsty 已成为 PostgreSQL 生态中国开源项目中 Star 数最高的项目，在国际上也建立了一定的知名度与影响力。

我们的愿景是：将 Pigsty 打造为 PostgreSQL 世界的主流发行版，在数据库领域占据类似 Debian、Ubuntu、RHEL 在操作系统领域的生态位。

实现路径：

  • 聚焦核心场景：原生 Linux 上的大规模生产级 PostgreSQL 管理
  • 构建差异化优势：业界领先的监控系统与最完整的扩展生态
  • 整合生态资源：融合 Supabase、Percona 等发行版的核心能力
  • 优化开发者体验：在保证专业性的同时兼顾易用性

v3.7.0

Pigsty v3.7.0 版本发布，PostgreSQL 18 深度支持！

curl https://repo.pigsty.cc/get | bash -s v3.7.0

亮点特性

  • PostgreSQL 18 深度支持，成为默认 PG 大版本，扩展已就位！
  • 新增 EL10 / Debian 13 操作系统支持，总数达 14 个！
  • 新增 PostgresQL 扩展数量，总数达到 437 个！
  • 支持了 Ansible 2.19 破坏性重构以后的版本！
  • Supabase，PolarDB, IvorySQL, Percona 内核更新至最新版本！
  • 优化了 PG 默认参数的设置逻辑，更充分利用资源。

版本更新

  • PostgreSQL 18.1, 17.7, 16.11, 15.15, 14.20, 13.23
  • Patroni 4.1.0
  • Pgbouncer 1.25.0
  • pg_exporter 1.0.3
  • pgbackrest 2.57.0
  • Supabase 2025-11
  • PolarDB 15.15.5.0
  • FerretDB 2.7.0
  • DuckDB 1.4.2
  • Etcd 3.6.6
  • pig 0.7.4

更多软件版本更新信息，请参考：

API 变化

  • 为并行执行的相关参数设置了更合理的优化策略
  • 在 rich 与 full 模板中，不再默认安装 citus 扩展，因为 citus 尚未支持 PG 18
  • PG 参数模板中，新增 duckdb 系列扩展存根
  • 为 min_wal_size, max_wal_size, max_slot_wal_keep_size 设置 200，2000，3000 GB 的封顶上限值
  • 为 temp_file_limit 设置 200 GB 的封顶上限，OLAP 设置为 2 TB
  • 适当增大连接池默认链接数量
  • 新增 prometheus_port 参数，且默认值为 9058，避开与 EL10 RHEL Web Console 端口的冲突
  • 修改 alertmanager_port 参数的默认值为 9059，避开与 Kafka SSL 端口的潜在冲突
  • 新增 pg_pkg 的 pg_pre 子任务，在安装 PG 包前移除 el9+ 上导致 LLVM 冲突的 bpftool, python3-perf
  • 在 Debian / Ubuntu 的默认仓库定义中新增 llvm 仓库模块
  • 修复了 infra-rm.yml 移除软件包的逻辑

兼容性修复

  • 修复了 Ubuntu/Debian 信任 CA 时 Warning 返回码错误的问题
  • 修复了 Ansible 2.19 引入的大量兼容性问题，确保在新老版本上正常运行
  • 为 seq 类变量添加了 int 类型转换，确保兼容
  • 将大量 with_items 修改为 loop 语法，确保兼容
  • 为密钥交换变量添加一层列表嵌套，避免在新版本下针对字符串进行字符迭代
  • 将 range 用例显式转换为 list 后使用
  • 修改了 name，port 等标记保留的变量命名
  • 将 play_hosts 修改为 ansible_play_hosts
  • 为部分字符串类型添加了 string 强制类型转换，避免运行时错误

EL10 逻辑适配

  • 修复了 EL10 缺少 ansible-collection-community-crypto 无法生成密钥的问题
  • 修复了 EL10 缺少 ansible 逻辑包的问题
  • 移除 modulemd_tools flamegraph timescaledb-tool
  • 使用 java-21-openjdk 替代 java-17-openjdk
  • aarch64 YUM 仓库名称问题

Debian 13 逻辑适配

  • 使用 bind9-dnsutils 替代 dnsutils

Ubuntu 24 修复

  • 临时移除了上游依赖崩溃的 tcpdump 包

校验和 

e00d0c2ac45e9eff1cc77927f9cd09df  pigsty-v3.7.0.tgz
987529769d85a3a01776caefefa93ecb  pigsty-pkg-v3.7.0.d12.aarch64.tgz
2d8272493784ae35abeac84568950623  pigsty-pkg-v3.7.0.d12.x86_64.tgz
090cc2531dcc25db3302f35cb3076dfa  pigsty-pkg-v3.7.0.d13.x86_64.tgz
ddc54a9c4a585da323c60736b8560f55  pigsty-pkg-v3.7.0.el10.aarch64.tgz
d376e75c490e8f326ea0f0fbb4a8fd9b  pigsty-pkg-v3.7.0.el10.x86_64.tgz
8c2deeba1e1d09ef3d46d77a99494e71  pigsty-pkg-v3.7.0.el8.aarch64.tgz
9795e059bd884b9d1b2208011abe43cd  pigsty-pkg-v3.7.0.el8.x86_64.tgz
08b860155d6764ae817ed25f2fcf9e5b  pigsty-pkg-v3.7.0.el9.aarch64.tgz
1ac430768e488a449d350ce245975baa  pigsty-pkg-v3.7.0.el9.x86_64.tgz
e033aaf23690755848db255904ab3bcd  pigsty-pkg-v3.7.0.u22.aarch64.tgz
cc022ea89181d89d271a9aaabca04165  pigsty-pkg-v3.7.0.u22.x86_64.tgz
0e978598796db3ce96caebd76c76e960  pigsty-pkg-v3.7.0.u24.aarch64.tgz
48223898ace8812cc4ea79cf3178476a  pigsty-pkg-v3.7.0.u24.x86_64.tgz

更多版本信息请参考 GitHub 发布页面。

20 - 立足中国，面向全球的 PostgreSQL 发行版

原文发布于 VONNG。

大家好，我是冯若航，Pigsty 的作者，独立开源贡献者。 今天我想和大家聊一个话题：如何打造一个立足中国，面向全球的 PostgreSQL 数据库发行版。

这个标题听着有点大，但我想说的很简单：PostgreSQL 已经赢了，问题是 —— 我们中国开发者在这场胜利中扮演什么角色？ 是旁观者，还是参与者？是跟随者，还是引领者？

数据库内核之争已经尘埃落定，真正的竞争将会发生在数据库发行版上。 而在这个关键的机会窗口里，我们应该凝聚生态合力，打造一个全世界开发者都愿意使用的基础设施，数据库世界中的 Ubuntu / Deepseek。

WHY — 为什么

PostgreSQL 已经成为数据库领域主宰者

PostgreSQL 已经赢了 —— 这个观点有着非常扎实的数据支撑。

Stack Overflow 开发者调查 显示，专业开发者中 PostgreSQL 的使用率达到 58.2%，甩开第二名 MySQL 18.6 个百分点，而且这个比例还在加速增长。 从新开源项目，AI SaaS 到 OpenAI 这样的独角兽，PG 已经成为新项目的标配 “默认” 数据库。

pg-used-data.webp

无论 DB-Engines 的数据库热度指数，还是 JetBrains 的开发者调查 都得出了相似的结论。 如果这些社区调查还不够，我们再看看资本市场的动向。

2025 年，PostgreSQL 生态发生了两起标志性收购案： Databricks 斥资约 10 亿美元收购了 PostgreSQL 初创公司 Neon，而 Snowflake 则以 2.5 亿美元收购了 Crunchy Data。 两大数据平台巨头通过收购杀入 PostgreSQL 的 OLTP 市场——他们选的不是 MySQL，也不是自研新库，而是直接押注 PostgreSQL。

industry.webp

各大云厂商同样在 All in PostgreSQL：AWS 的新品 Aurora DSQL，Azure 的新品 HorizonDB，GCP 的 AlloyDB，这些云上创新产品都是 PostgreSQL 独占。 PG 的胜利不仅仅是技术上的胜利，更是商业上的胜利。全球最聪明的钱，都在往 PostgreSQL 生态里涌。选择 PostgreSQL 就是选择了未来！

中国在PG开源生态中并没有多少参与感

遗憾的是，在 PostgreSQL 全球狂飙突进的过程中，中国开源的存在感却非常弱。 在这幅波澜壮阔的版图上，很难找到几样醒目的 “Made in China”。我们在见证 PG 巨大胜利的同时，却几乎缺席了这场盛宴。

此前的 PostgreSQL 社区内核 Committer 列表里，没有一位中国人。 而在开源项目方面，老冯搜集了由中国公司或者中国开发者主导的 PG 开源项目，结果发现 Star 数最多， 影响力最大的竟然是老冯这个数据库个人开发者的 Pigsty 。我一方面感觉很自豪，另一方面也感觉很荒诞。

china-pg-oss.webp
项目 Star 简介
pigsty 4.3K 开箱即用的PG发行版
PolarDB PG 3.1K 阿里云 PolarDB 开源内核
pgvector.rs 2.1K Rust 编写的PG向量扩展
VectorChord 1.4K 下一代 Rust PG 向量扩展
TBase 1.4K 腾讯云 PG 内核
Cloudberry 1.1K Hashdata 的开源 Greenplum 2.0
IvorySQL 960 瀚高主导的 Oracle 兼容内核
openGauss 751 华为主导的早期 PG 分叉
openHalo 626 易景开源的 MySQL 兼容 PG 内核
zhparser 798 使用 scws 的PG中文分词扩展
duckdb_fdw 393 李红艳开源的 DuckDB 包装器
pg_jieba 392 使用结巴分词的 PG 中文分词扩展
VectorChord-bm25 314 PG 原生的 BM25 排序索引算法
pg_roaringbitmap 263 PG 中的 RoaringBitmap 位图

我这两年参加了几场 国际 PostgreSQL 会议，感受很复杂。 去年 PG 开发者大会里，我碰上了瀚高北美的 Grant Zhou 和 Carry Huang，富士通的 Zhijie Hou，再加上我，就没有别的中国开发者影子了。 今年 还碰上了 TensorChord 的朋友。放在几百人的大会里面，依然是不成比例的极少数。

中国有两三百个数据库产品，很多都是 PG 衍生。但在全球 PostgreSQL 生态里，几乎没有存在感。 我们的人才、我们的资金、我们的精力，都花在了重复造轮子上。当全球同行们正在奋勇创新，在资本市场嘎嘎乱杀的时候。 中国的数据库同行们却在泥潭中挣扎 —— 几百家国产数据库公司，只有四家在盈利，整个行业正在高速缩水凋亡。 这说明什么？说明我们在错误的方向上投入了太多资源，市场正在用脚投票。

我们需要思考如何破局：如何在 PostgreSQL 生态中找到一个切入点，做出像 Deepseek 这样有世界级影响力的东西

有这样的东西吗？有的，朋友们，有的。

数据库发行版大战拉开序幕

数据库内核之争已经尘埃落定，真正的战斗将会发生在数据库发行版上。 —— 这个判断来自对 Linux 发展历程的观察。

1991 年，Linus Torvalds 发布了 Linux 内核。但 Linux 内核本身是不能直接用的， 你需要有人把内核、工具链、软件包、配置脚本打包在一起，形成一个可以安装、可以使用的操作系统。这就是 发行版。

1993 Debian 年诞生，94 年 RedHat 诞生。之后服务端操作系统内核很快就收敛到了 Linux 上， 大家都用同一个内核，OS 世界的竞争很快就从内核层面转移到了发行版。

今天的 PostgreSQL，正处于当年 Linux 的位置上。

distro.webp

做过系统管理的朋友都清楚，真正的生产环境中几乎没有有人会从源码编译整个 Linux 内核和软件栈，而是直接选择一个发行版。 因为后者已经帮我们选好了内核版本、驱动与库，准备好了软件仓库和包管理器，带有文档手册与最佳实践，可以 开箱即用。

PostgreSQL 内核如今已经足够成熟强大了，如何把内核 + 扩展 + 高可用 + 监控 + 备份 + 安全等要素整合起来，形成一个开箱即用的完整解决方案，这件事成为了关键。 PostgreSQL 内核称王，发行版诸侯争霸。谁会成为数据库世界的 Debian / Ubuntu / RedHat，群雄逐鹿，犹未可知。

pg-distro.webp

事实上，目前在全球范围内，围绕 PostgreSQL 已经出现了一些“准发行版”的雏形。最有名的就是 Supabase。 它把 PostgreSQL 内核与几个扩展和开源生态组件打包起来，加上UI封装成一个后端即服务 (BaaS) 平台。 从本质上看，这就是一个 PostgreSQL 发行版！钉死了 PG 中的 Android 生态位.

一家成立不到五年的 PG 发行版创业公司，估值高达 50 亿美元； 而 PostgreSQL 内核贡献的老大哥 EDB，成立近20年估值才 10～20 亿美元，这足够证明很多事情了。

这对于我们而言既是挑战，更是机会。在这个时间窗口里， 我们完全有机会打造一个由中国团队主导的 PostgreSQL 开源发行版，服务全球用户，抢占新的制高点。 如果我们再错过这一次的机会窗口，我们可能又要在下一个时代继续扮演追随者的角色。

HOW：我是怎么做的？

但在讲故事之前，我先亮个底牌 —— 我不是来画饼的，我已经做出来了。

Pigsty，一个 PostgreSQL 发行版。从下载量和网站 UV 看，用户大概小十万，中国一半，海外一半。GitHub Star 在中国 PG 生态项目里排第一。

users.webp

要是拿来和 Supabase 这种50亿美金的巨无霸比呢，差距确实很大，Supabase 的 Star 数量和用户量都是 Pigsty 的 20 倍。

Supabase 其实属于 2C 的 “Android”，而且也被老冯偷了家，目前 Pigsty 是极个别可以直接 自建生产级 Supabase 的开源方案。

但这个生态允许错位竞争，可以同时出现多个赢家， 如果看 Linux 原生 PG RDS 发行版 这个细分赛道，Pigsty 拿第一当仁不让。 就算拉上 EDB、Crunchy 这些大厂搞的十几个 K8S 云原生 Operator 一起比，也算是打得有来有回。

star-history.webp

至少我证明了：一个中国开发者，用正确的方法，也可以在 PG 全球生态里占有一席之地，拿到了一张决赛圈的门票。

claude.webp

Claude Opus 4.5: PG 生态发行版格局分析

gemini.png

Gemini 3 Pro: PG 生态发行版格局分析

老冯 2022 年开始全职创业做这个，差不多三年半了。技术储备从 2018 年就开始。 作为开源项目，有一些外部贡献者，但 99% 以上的代码和工作量，是我一个人完成的。 那么问题来了：一个人，怎么做到这些的？其实就是两句话，立足中国，面向世界。

立足中国：规模是最好的试炼场

什么是“立足中国”？ 它不是一句口号，而是我们手中最有价值的资源 —— 规模与场景。

Pigsty 并不是在车库里凭空想出来的，它是在 探探 —— 中国第二大陌生人社交平台上孵化出来的。（PS. 这是个瑞典的创始团队） 在那几年里，我们要面对的是什么？是 250 万全局 QPS 的恐怖流量，是所有核心业务逻辑全跑在数据库存储过程里的极限架构，以及上百套大型物理机集群的高效监控管理。

就连现在独角兽之王 OpenAI 对于 PostgreSQL 的使用规模与深度，也没有达到当初我们所面临的挑战。 当时市面上的监控、高可用方案，在这种规模的冲击下，要么不够看，要么不好用。 没办法，逼着我们自己试，自己造，自己整合。 我们是在几百万 QPS 的高压锅里，在一个又一个故障和报警的锤炼下，把 Pigsty 打磨出来的。

这就是“立足中国”的真正含义： 中国拥有全球罕见的互联网规模和复杂场景。这里的海量用户高并发挑战，就是最好的炼丹炉。 如果一个方案能扛住探探这种级别的压力与复杂度，并解决好这些问题，那它放在全世界的其他场景下基本都是降维打击。

—— 立足中国，就是要用中国互联网场景独有的规模场景，打磨出世界先进的生产级方案。

intro.webp

面向全球：成为供应链的上游

那什么叫“面向全球”？ 把文档翻译成英文，去海外发帖推广，那算不了什么。 真正的面向全球，是 让你自己成为全球软件供应链不可或缺的一环。而想要走向全球，你需要关注的是开发者的体验与需求。

developers.webp

差不多做到 2023 年，Pigsty 运维层面已经很完善了。 高可用，备份恢复，监控系统，离线部署，IaC 大规模管理全部整合到了一起，可以无需容器在主流 Linux 上一键交付。 但我隐隐觉得哪里不对，老冯一直站在 DBA 的视角，做了很多可靠性、可观测性，质量与易用性上的工作 —— 但我忽视了开发者的核心需求 —— 功能特性。

ecosystem.webp

我意识到：扩展才是 PostgreSQL 最大的价值所在。MySQL 想加向量搜索，折腾很久效果还不好。 PG 呢？一个社区开发者写了 pgvector，几个扩展一起赛马，直接把这个赛道卷没了，这就是可扩展架构的威力。

去年我写了一篇文章《PostgreSQL 正在吞噬数据库世界》，发到 Hacker News 火了，传遍整个 PG 社区。 核心观点就是：PG 能拳打 Oracle、脚踢 MySQL，靠的是极致的可扩展性和繁荣的扩展生态。

于是我开始做扩展仓库。一开始想借力，等生态里其他项目做完再集成。 等了几个月发现等不来，就自己干了。先编译十几个，然后几十个，然后一百多个。 做着做着发现：PG 生态里能打的扩展就几百个，官方仓库提供一百出头， 而我凭一己之力把这个数字推到了 437 个。

437-ext.webp

这个仓库覆盖 14 个 Linux 发行版、x86 和 ARM 两种架构、6 个 PostgreSQL 大版本。 仓库里有六七万个 RPM 和 DEB 包。很多扩展得改代码才能编译通过，我前后修了几十个。 想借力借不到只能自己干，反而干出了壁垒。最费工夫的苦活，成了最坚固的护城河。 但老冯也不会藏着掖着，敝帚自珍，而是将这个扩展仓库对公众与同行免费开放。

pgext-cloud.webp

让我没有想到的是， 现在不仅仅是 PG 终端用户在用 Pigsty。 国外的数据库发行版项目，甚至是一些商业数据库公司，开始直接使用 Pigsty 的扩展仓库作为他们的上游源。

以前，我们是下载别人的代码，用别人的源。 现在，是一个中国开发者维护的仓库，成为了国际数据库同行的上游基础设施。 我们不再只是旁观者或者消费者，我们成了供应商，我们嵌入到了全球 PG 的供应链里。

upstream-repo.webp

这是真正的出海：不是去别人的地盘抢饭吃，而是让别人做饭的时候，用你的大米。 用这种方式，老冯的发行版开始成为了 PostgreSQL 生态的一块基础设施，成为全球软件供应链的一个节点。

有了从零到一的突破之后，中国的 PG 生态开源软件也能够更容易的走向国际。 在老冯的 Pigsty 仓库中，目前还分发三款来自中国的 PostgreSQL Kernel 分支 —— IvorySQL，PolarDB，OpenHalo，以及一些中国开发者的扩展与工具。

kernel-deliver.webp

邀请

一个人做到现在这个程度，真的很不容易。但如果想要更进一步，打造出一个像 Ubuntu 这样的，全球主流的 PostgreSQL 发行版。 那就绝非一人能成了，需要众人拾柴火焰高。所以今天，我想借这个机会，向在座的各位发出邀请。共同参与到这样的事业中来。

面向用户的邀请

对于用户来说，你可以通过使用 Pigsty 免费获得企业级质量的本地 RDS 服务，免去手搓HA，编译安装配置等诸多烦恼，一步到位完成生产数据库自建，开箱即用。

我们邀请您在新项目中尝试 Pigsty —— 反正一行命令就能部署，不满意可以随时换掉。如果愿意向朋友推荐，写下使用心得，投稿博客或者视频，那对于项目来说也是巨大的贡献。

面向数据库厂商的邀请

对于数据库厂商来说，我想说的是，如果你们交付给客户的还是一个裸的 RPM / DEB 包，现在你可以选择用 Pigsty 交付一套完整的生产级基础设施。 Pigsty 可以成为你们的交付载体。你们专注做内核、做特色功能，Pigsty 帮你们解决周边生态的问题。这是双赢的合作。已经有好几款PG内核分支 通过 Pigsty获得了完整的 RDS 能力。

vendor-invite.webp

作为诚意，原本 AGPLv3 许可证的 Pigsty 本体也将在下个大版本中使用更宽松的开源许可。而像 PG 扩展仓库，PIG 包管理器的的全部代码与基础设施都以 Apache 2.0 许可证开源。

面向开发者的邀请

对于扩展作者来说，PGEXT.CLOUD 是一个让你的作品触达全球用户的渠道。

你写了一个 PostgreSQL 扩展，怎么让用户用上？自己编译打包适配十几个不同的 Linux 发行版？ 自己去触达全世界的 PG 用户？如果你有这样的烦恼，也许老冯可以帮到你。

结语

最后，我想用一句话来总结今天的演讲：

与其在两百多个国产数据库里内卷，不如一起打造一个全世界都想用的 PostgreSQL 发行版。

PostgreSQL 已经赢了。现在的问题是，我们中国人要不要参与这场胜利，以及以什么姿态参与。我选择的姿态是：拥抱 PostgreSQL，做一个发行版，立足中国，面向全球。

这条路我已经走了 7 年，即使是一个人，我会继续走下去。但我希望不是一个人走，而是有更多的人一起前行。

谢谢大家。

featured.jpg

21 - Pigsty v3.6：全能PG发行版的关键一步

原文发布于 VONNG。

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

Pigsty v3.6 正式发布。历经两个月的精心打磨，这将是 v4.0 之前的最后一个主要版本，进行了大量重构与改进，为打造终极全能 PostgreSQL 发行版奠定了坚实基础。

本版本对 PostgreSQL、MinIO、Etcd 的部署任务进行了深度优化与重构，新增了 Percona PG TDE 内核支持，提供开箱即用的透明加密功能。此外，Supabase 自建体验得到全面优化，彻底移除了幂等剧本中的"删库"功能，并新增全自动 pgsql-pitr 剧本用于一键时间点恢复。

安装流程也进一步简化：从四步走变为三步走（下载、配置、安装），且默认采用在线安装模式，可跳过本地软件仓库的构建过程。

全新内核支持：Percona PG TDE

Percona 的 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 透明加密内核外，OrioleDB 也发布了 1.5 beta12 版本，Supabase CEO 透露其即将正式 GA。Pigsty 已第一时间编译了 OrioleDB 补丁版本的 PG 及其扩展。

另一个值得关注的扩展是 pgactive —— 由 AWS 开发并开源的 PG 多活扩展，声称解决了亚秒级高可用切换问题。该扩展依赖缺失的 pgfeutils，编译有一定门槛，Pigsty 已提供开箱即用的二进制包。

可用扩展数量达到 423 个。PG18 beta2、OrioleDB、TimescaleDB、Citus、FerretDB & DocumentDB、DuckDB、Etcd 等均完成例行版本更新。

扩展目录站点也已全面翻新，采用 Next.js 重构，观感大幅提升，新地址：https://pgext.cloud

Supabase 自建体验优化

Pigsty v3.6 提供了更流畅的 Supabase 自建体验，并修复了 Supabase 官方模板中的若干问题：

  • logflare 复制槽不推进
  • 大量打印错误日志
  • Studio 无法查看两项 Analytics 日志

生产级 Supabase 自建只需几行命令即可完成：

此外，Pigsty 现默认使用由 1Panel 提供的 Docker 镜像站点，国内下载速度显著提升。

目前 Pigsty 和 StackGres 是仅有的两个自建 Supabase 方案的开源供应商：Pigsty 基于裸 Linux 系统交付，StackGres 基于 Kubernetes 交付。

PITR 恢复增强

此前版本中，Pigsty 提供 pg-pitr 脚本用于"半自动"辅助 PITR 恢复。本版本新增了全自动的 pgsql-pitr 剧本，实现一键时间点恢复。

该剧本会自动执行以下操作：

  • 暂停高可用切换
  • 关闭 PostgreSQL
  • 生成并执行 pgbackrest PITR 恢复命令至指定目标位点
  • 校验后重新拉起 PostgreSQL
  • 重新启用高可用切换

支持快速重试（原地增量），便于精确定位恢复位点。同时新增了一种新用例：在新启动的实例（或摘下的从库）上执行 PITR 恢复，避免影响现有业务，然后从新实例抽取数据手工导入。

ETCD 管理简化

本版本对 Etcd 模块进行了重构，新增独立的 etcd-rm.yml 剧本与扩缩容 SOP 脚本。

此前扩缩容 etcd 涉及一系列复杂的命令操作，现在只需简单几条命令：

bin/etcd-add              # 创建 etcd 集群，或刷新现有集群状态
bin/etcd-add 10.10.10.11  # 扩容 etcd 集群，新增一个成员
bin/etcd-rm               # 移除整个 etcd 集群
bin/etcd-rm 10.10.10.11   # 将指定成员从集群中移除

etcd.yml 剧本现 不再清理现有 ETCD 集群，清理工作由专门的 roles 与剧本实现，维护变得更加简单明了。

MinIO 模块改进

MinIO 模块进行了重构，新增 Plain HTTP 模式，并调整了默认桶与用户配置。

此前版本默认为 MinIO 启用 HTTPS（通过本地 CA 签发自签名证书），可避免内网流量窃听，但也带来一些烦恼：Pigsty 管理节点之外的客户端（如容器）需要信任该 CA 才能访问 MinIO。

本版本新增开关，允许 MinIO 运行在纯 HTTP 模式下。需注意：pgbackrest 不接受 HTTP 模式的 MinIO，若使用本地 MinIO 存储 PG 备份仍需 HTTPS 模式。HTTP 模式仅适用于纯粹给外部服务使用的场景。

默认桶配置也进行了调整：

原配置 新配置
pgsql, infra, redis pgsql, meta, data

同时为 meta 和 data 桶创建了专用用户 s3user_meta 与 s3user_data，并为每个桶创建同名策略。如此设计下，Supabase、Dify 等应用可直接使用这两个桶，无需手动创建。

安装流程简化

安装步骤从四步简化为三步：

原流程 新流程
下载 → 引导 → 配置 → 安装 下载 → 配置 → 安装

“引导"步骤（解压离线软件包或配置上游软件仓库以安装 Ansible）已合并到下载脚本中，执行安装脚本时会自动执行 ./bootstrap。

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

默认在线安装

默认安装策略发生变化：不再先下载到本地再安装，而是直接从互联网上游安装。

这一改变带来显著好处：

  • 减少出错点：许多用户反馈的安装报错都发生在本地 Repo 下载和 Nginx 服务拉起阶段（如 el9.aarch64 上 PGDG 配置错误导致的 patroni-etcd 安装失败）
  • 提升速度：只下载真正需要安装的包，而非一次性下载所有包
  • 简化配置：无需处理 Nginx 的安全策略和防火墙配置问题

大比例用户在单节点 Linux 上安装 Pigsty，“不需要"本地软件仓库提供的多节点一致性。需要本地仓库的用户可通过简单配置（repo_enabled、node_repo_modules）重新启用，或直接使用默认启用本地仓库的 rich / full 模板。

全新文档站

全新文档站点已上线：https://pigsty.cc/docs/

该站点采用 Next.js 与 Fumadocs 现代前端技术栈打造，感谢兰天游与 Claude Code 的强力助攻。英文版已基本完工，中文版正在翻译建设中。欢迎通过 GitHub PR 或 Issue 参与贡献。

其他改进

  • tuned 模块优化：针对现代硬件与 NVMe 磁盘进行优化，移除过时配置参数，新增 NVMe / 虚拟化 SSD 的调度/预读参数优化
  • MCP Toolbox 集成：集成了 Google 新发布的 MCP Toolbox（数据库 MCP 工具箱），预置模板 SQL 解决部分数据库安全性问题
  • 配置模板调整：所有配置模板调整为 单节点 模式，便于快速上手

下一步：v4.0 与 DBA Agent

PostgreSQL 18 将于今年 9 月发布，Pigsty 计划在 PG 18 发布后正式发布 v4.0 版本，主要改进方向：

领域 计划
CLI 工具 pig 完整封装 Ansible 剧本功能，接口初步定型
监控系统 VictoriaMetrics / VictoriaLogs 替代 Prometheus / Loki
日志收集 vector 替代过时的 promtail
门户组件 考虑使用 Caddy 替代 Nginx（待定）

v4.x 的主旋律将是 DBA Agent。Pigsty 已具备 DBA Agent 所需的完整上下文，核心正是这套 PG 最强监控系统。待文档中沉淀的领域知识足够丰富，为 Pig 命令行工具套上 MCP，一个能打的全自动驾驶数据库 DBA Agent 便将诞生。

v3.6.0

Pigsty v3.6.0 版本发布，全新文档站与 PITR 增强！

curl https://repo.pigsty.cc/get | bash -s v3.6.0

亮点特性

  • 全新文档站：https://pigsty.cc/docs/
  • 新增 pgsql-pitr 剧本与备份/恢复教程，改善 PITR 体验
  • 新增内核支持：Percona PG TDE (PG17)
  • 优化 Supabase 自建体验，更新至最新版本，并解决了一系列官方模板的问题
  • 简化安装步骤，默认使用在线安装，更加高效简单，bootstrap 过程（安装ansible）嵌入安装脚本中

设计改进

  • 改善了 Etcd 模块的实现，新增独立的 etcd-rm.yml 剧本与扩缩容 SOP 脚本
  • 改善了 MinIO 模块的实现，支持 HTTP 模式，创建不同属性的三个桶供开箱即用
  • 重新调整梳理了所有配置模板，使用更为便利
  • 针对中国大陆使用速度更快的 Docker Registry 镜像站
  • 优化了 tuned 操作系统参数模板，针对现代硬件与 NVMe 磁盘优化
  • 新增扩展 pgactive 用于多主复制与亚秒级故障切换
  • 调整 pg_fs_main / pg_fs_backup 默认值，简化文件目录结构设计

问题修复

  • 修复了 pgbouncer 配置文件的错误 by @housei-zzy
  • 修复了 OrioleDB 在 Debian 平台上的问题
  • 修复了 tuned shm 配置参数的问题
  • 离线软件包直接使用 PGDG 源，避免使用断开同步的镜像站点
  • 修复了 IvorySQL libxcrypt 依赖的问题
  • 替换了破损与缓慢的 EPEL 软件仓库站点
  • 修复了 haproxy_enabled 标记位的功能

基础设施软件包更新

新增 Victoria Metrics / Victoria Logs 相关包：

  • genai-toolbox 0.9.0 (new)
  • victoriametrics 1.120.0 -> 1.121.0 (重构)
  • vmutils 1.121.0 (重命名 victoria-metrics-utils)
  • grafana-victoriametrics-ds 0.15.1 -> 0.17.0
  • victorialogs 1.24.0 -> 1.25.1 (重构)
  • vslogcli 1.24.0 -> 1.25.1
  • vlagent 1.25.1 (新增)
  • grafana-victorialogs-ds 0.16.3 -> 0.18.1
  • prometheus 3.4.1 -> 3.5.0
  • grafana 12.0.0 -> 12.0.2
  • vector 0.47.0 -> 0.48.0
  • grafana-infinity-ds 3.2.1 -> 3.3.0
  • keepalived_exporter 1.7.0
  • blackbox_exporter 0.26.0 -> 0.27.0
  • redis_exporter 1.72.1 -> 1.77.0
  • rclone 1.69.3 -> 1.70.3

数据库软件包更新

  • PostgreSQL 18 Beta2 更新
  • pg_exporter 1.0.1，更新至最新依赖并提供 Docker 镜像
  • pig 0.6.0，更新了最新扩展与仓库列表，带有 pig install 子命令
  • vip-manager 3.0.0 -> 4.0.0
  • ferretdb 2.2.0 -> 2.3.1
  • dblab 0.32.0 -> 0.33.0
  • duckdb 1.3.1 -> 1.3.2
  • etcd 3.6.1 -> 3.6.3
  • ferretdb 2.2.0 -> 2.4.0
  • juicefs 1.2.3 -> 1.3.0
  • tigerbeetle 0.16.41 -> 0.16.50
  • pev2 1.15.0 -> 1.16.0

PG 扩展包更新

  • OrioleDB 1.5 beta12
  • OriolePG 17.11
  • plv8 3.2.3 -> 3.2.4
  • postgresql_anonymizer 2.1.1 -> 2.3.0
  • pgvectorscale 0.7.1 -> 0.8.0
  • wrappers 0.5.0 -> 0.5.3
  • supautils 2.9.1 -> 2.10.0
  • citus 13.0.3 -> 13.1.0
  • timescaledb 2.20.0 -> 2.21.1
  • vchord 0.3.0 -> 0.4.3
  • pgactive 2.1.5 (new)
  • documentdb 0.103.0 -> 0.105.0
  • pg_search 0.17.0

API 变更

  • pg_fs_backup：重命名为 pg_fs_backup，默认值为 /data/backups。
  • pg_rm_bkup：重命名为 pg_rm_backup，默认值为 true。
  • pg_fs_main：现在默认值调整为 /data/postgres。
  • nginx_cert_validity：新增参数，用于控制 Nginx 自签名证书的有效期，默认为 397d。
  • minio_buckets：默认值调整为创建名为 pgsql、meta、data 的三个桶。
  • minio_users：移除 dba 用户，新增 s3user_meta 和 s3user_data 用户，分别对应 meta 和 data 桶。
  • minio_https：新增参数，允许配置 MinIO 使用 HTTP 模式。
  • minio_provision：新增参数，允许跳过 MinIO 置备阶段（跳过桶和用户的创建）。
  • minio_safeguard：新增参数，启用后会在执行 minio-rm.yml 时中止操作。
  • minio_rm_data：新增参数，控制在执行 minio-rm.yml 时是否删除 minio 数据目录。
  • minio_rm_pkg：新增参数，控制在执行 minio-rm.yml 时是否卸载 minio 软件包。
  • etcd_learner：新增参数，允许 etcd 以学习者身份初始化。
  • etcd_rm_data：新增参数，控制在执行 etcd-rm.yml 时是否删除 etcd 数据目录。
  • etcd_rm_pkg：新增参数，控制在执行 etcd-rm.yml 时是否卸载 etcd 软件包。

校验和 

df64ac0c2b5aab39dd29698a640daf2e  pigsty-v3.6.0.tgz
cea861e2b4ec7ff5318e1b3c30b470cb  pigsty-pkg-v3.6.0.d12.aarch64.tgz
2f253af87e19550057c0e7fca876d37c  pigsty-pkg-v3.6.0.d12.x86_64.tgz
0158145b9bbf0e4a120b8bfa8b44f857  pigsty-pkg-v3.6.0.el8.aarch64.tgz
07330d687d04d26e7d569c8755426c5a  pigsty-pkg-v3.6.0.el8.x86_64.tgz
311df5a342b39e3288ebb8d14d81e0d1  pigsty-pkg-v3.6.0.el9.aarch64.tgz
92aad54cc1822b06d3e04a870ae14e29  pigsty-pkg-v3.6.0.el9.x86_64.tgz
c4fadf1645c8bbe3e83d5a01497fa9ca  pigsty-pkg-v3.6.0.u22.aarch64.tgz
5477ed6be96f156a43acd740df8a9b9b  pigsty-pkg-v3.6.0.u22.x86_64.tgz
196169afc1be02f93fcc599d42d005ca  pigsty-pkg-v3.6.0.u24.aarch64.tgz
dbe5c1e8a242a62fe6f6e1f6e6b6c281  pigsty-pkg-v3.6.0.u24.x86_64.tgz

更多版本信息请参考 GitHub 发布页面。

v3.6.1

Pigsty v3.6.1 版本发布，PostgreSQL 小版本更新！

curl https://repo.pigsty.cc/get | bash -s v3.6.1

亮点特性

  • PostgreSQL 17.6, 16.10, 15.14, 14.19, 13.22, 以及 18 Beta 3 支持
  • 在中国大陆地区使用 Pigsty 提供的 PGDG APT/YUM 镜像解决更新断供问题
  • 新的网站首页：https://pigsty.cc
  • 增加了 el10, debian 13 的实现存根，以及 el10 的 Terraform 镜像

基础设施软件包更新

  • Grafana 12.1.0
  • pg_exporter 1.0.2
  • pig 0.6.1
  • vector 0.49.0
  • redis_exporter 1.75.0
  • mongo_exporter 0.47.0
  • victoriametrics 1.123.0
  • victorialogs: 1.28.0
  • grafana-victoriametrics-ds 0.18.3
  • grafana-victorialogs-ds 0.19.3
  • grafana-infinity-ds 3.4.1
  • etcd 3.6.4
  • ferretdb 2.5.0
  • tigerbeetle 0.16.54
  • genai-toolbox 0.12.0

数据库软件包更新

  • pg_search 0.17.3

API 变更

  • 从 node_kernel_modules 默认值中移除 br_filter 内核模块。
  • 在添加 PGDG YUM 源时使用操作大版本号，不再使用小版本号。

校验和 

045977aff647acbfa77f0df32d863739  pigsty-pkg-v3.6.1.d12.aarch64.tgz
636b15c2d87830f2353680732e1af9d2  pigsty-pkg-v3.6.1.d12.x86_64.tgz
700a9f6d0db9c686d371bf1c05b54221  pigsty-pkg-v3.6.1.el8.aarch64.tgz
2aff03f911dd7be363ba38a392b71a16  pigsty-pkg-v3.6.1.el8.x86_64.tgz
ce07261b02b02b36a307dab83e460437  pigsty-pkg-v3.6.1.el9.aarch64.tgz
d598d62a47bbba2e811059a53fe3b2b5  pigsty-pkg-v3.6.1.el9.x86_64.tgz
13fd68752e59f5fd2a9217e5bcad0acd  pigsty-pkg-v3.6.1.u22.aarch64.tgz
c25ccfb98840c01eb7a6e18803de55bb  pigsty-pkg-v3.6.1.u22.x86_64.tgz
0d71e58feebe5299df75610607bf448c  pigsty-pkg-v3.6.1.u24.aarch64.tgz
4fbbab1f8465166f494110c5ec448937  pigsty-pkg-v3.6.1.u24.x86_64.tgz
083d8680fa48e9fec3c3fcf481d25d2f  pigsty-v3.6.1.tgz

更多版本信息请参考 GitHub 发布页面。

22 - Pigsty：喜提上海开源创新菁英奖

原文发布于 VONNG。

上海开源信息技术协会最近搞了个优秀开源项目评选，以及优秀开源社区贡献者评选。老冯投了两个，都中了。第一个是 Pigsty，当选了优秀开源项目：

图片

第二个是老冯自己，评了个优秀开源社区贡献者

图片

感谢上海开源信息技术协会，ITPUB，各位专家评委的认可。

这次比较可惜，周六在上海的颁奖活动真好和在济南的 PG 高峰论坛时间冲突了，所以没有参加，不过这俩奖状给寄到家里了。

老冯不喜欢那种费时间拉票的奖项，但这种花点时间填一下就能参与的奖还是很乐意参加的。拿个奖心里也是挺高兴的，哈哈。

另外最近 ITPUB 搞的新媒体评选，老冯的公众号还顺手搂了一个《最佳文章影响奖》https://zt.itpub.net/topic/peanit/

图片

老冯最近的公众号发展的还不错，总关注数量达到了 44355，主要是常读用户比例有 22%，9904，这还真是不少。在这里老冯也要感谢各位读者朋友的关注与支持哈🙏。

图片图片

Pigsty 的发展势头也还行，目前在 GitHub 上的 Star 数量达到了 4K 的里程碑。增长的速度跟一些竞品比还是算快的。

图片图片图片

在 PostgreSQL 生态开源项目排行榜中，Pigsty 也进了前两页，算是一个国际知名的开源项目了。在中国人主导的 PG 生态开源项目里目前是第一名。

Pigsty 文档站的流量也还不错，pigsty.cc 年 UV 差不多大概十万，大概一半来自海外。

图片

Pigsty 国内站点 pigsty.cc 和 Cloudflare 上的海外站点 pigsty.io 都有不少访问。另外最近还新搞了一个 pgsty.com，用 Next 重新糊了一遍。

图片

让我感到欣慰的是，写了这么多博客文章，还是有不少效果的，用 GPT 搜一些 PostgreSQL 相关的东西，Pigsty 的网站和博客经常成为权威参考来源了。

图片

总的来说，这算是做 Pigsty 的第五个年头了，今年的发展总算是走上了正轨。耐心做好有价值的事情，美好的事情自然会发生。

做了这么久的 PostgreSQL 数据库发行版，终于赶上了 AI 时代的数据库二次崛起。拿到了一张 数据库发行版大乱斗决赛的门票。这对一个一人公司来说，还真是挺不容易的。

好在，今年也有好几个用户决定成为我的客户。顺利的话，年底可以招几个实习生扩扩容了。

图片

最后，再次感谢各位读者与用户朋友，你们的关注，鼓励与支持是我前进的不竭动力源泉。

Pigsty 是什么？

Pigsty 是一个开箱即用的 PostgreSQL 数据库发行版，是数据库的自动驾驶软件，可以让你在本地一键用云 RDS 1/10 不到的成本，在没有专业 DBA 的情况下，拉起企业级 PostgreSQL 数据库服务，带有高可用，PITR，监控系统，IaC，以及 421 个 PG 生态的扩展插件，直接运行在 10 个主流 Linux 发行版上而无需容器或 Kubernetes 支持。

图片图片

发布版本：微信公众号

23 - Pigsty v3.5：4K Star，PG18支持，421个扩展

原文发布于 VONNG。

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

Pigsty v3.5 正式发布。项目在 GitHub 上达成 4000+ Star 里程碑，对于一个数据库基础设施项目而言，这是一个难得的成就。

本版本带来全新文档网站、OrioleDB 和 OpenHalo 内核全平台支持、Supabase 自建优化、监控系统与架构优化、PostgreSQL 18 Beta 支持、例行 PG 小版本更新，以及 Apple ARM Vagrant 支持。

Pigsty 是什么？

Pigsty 是一个开箱即用的 PostgreSQL 数据库发行版，可视为数据库的"自动驾驶软件"。它能让用户以云 RDS 十分之一不到的成本，在无需专业 DBA 的情况下，快速拉起企业级 PostgreSQL 数据库服务 —— 具备高可用、PITR、监控系统、IaC 能力，以及 421 个 PG 生态扩展插件，直接运行在 10 个主流 Linux 发行版上，无需容器或 Kubernetes。

PostgreSQL 18 支持

PostgreSQL 18 Beta1 已发布，正式版本将于今年 9 月推出。PG 18 带来了 AIO、OAuth 等诸多强力新特性，现已可在 Pigsty 中尝鲜（但切勿用于生产环境）。同时提供 17.5、16.9、15.13、14.18、13.21 例行小版本更新支持。

Pigsty 提供了全新的 pg18 配置模板，可直接用于拉起基于 PostgreSQL 18 Beta1 内核的高可用 RDS。pg_exporter 也刚发布 1.0 版本，完整收录了 PG 18 的新监控指标。用户还可使用 pig 包管理器一键安装 PG 18 与 PGDG 中的相应扩展。

Supabase 自建优化

Pigsty 提供的"企业级" Supabase 自建能力广受欢迎 —— Supabase 自建教程的页面流量甚至超过了 Landing Page。本版本进一步优化了 Supabase 自建流程。

pgsodium 密钥管理集成：现可指定根密钥或提供密钥获取脚本，供 Supabase 依赖的 pgsodium 扩展使用，提供数据加密能力，并可从根密钥派生出一系列子密钥。

logflare 复制槽问题修复：Supabase Analytics logflare 组件存在一个缺陷 —— 当系统表没有更新写入时，它不会更新 WAL 消费进度，导致复制槽持续保留数据。Pigsty 通过预置的定时任务 supa-kick 每分钟执行"假更新"来触发进度推进，避免磁盘被撑爆。

同时跟进了 Supabase 相关扩展版本与 Docker 镜像版本。

OpenHalo 与 OrioleDB 全平台可用

OpenHalo 内核在 PG 14 基础上提供 MySQL 兼容性，而 OrioleDB 内核则提供云原生的无膨胀版本 PG。在 v3.4 中仅提供了 RPM 包，现已在全部十个受支持的 Linux 系统上完整可用。

OrioleDB 已被 Supabase 收购，近日发布了第 11 个 Beta 版本。虽然尚未成为 Supabase 默认使用的 PG 内核分支，但 Pigsty 已提前做好准备 —— 确保 Supabase 一旦决定从原生 PG 切换到 OrioleDB，可以无缝跟进。

421 个扩展插件

可用扩展数量达到 421 个，并对大量扩展进行了版本更新。值得关注的新扩展：

pgsentinel：可观测性扩展，提供类似 Oracle Active Session History 的功能，可记录每个会话的统计信息及等待事件。详见：https://pigsty.cc/ext/e/pgsentinel/

spat：一个有趣的实验性扩展，在 PG 中提供类似 Redis 的接口，使用共享内存实现类似 Redis 的性能表现。目前处于 Alpha 阶段，切勿用于生产。

全新的扩展百科网站已上线，比原版本更美观、更全面：

全新文档站点

Pigsty 文档站基于 Next.js 进行了重制，从静态页面渲染迈入现代前端时代。新站点地址：https://pigsty.cc

不仅形式上全面翻新，内容上也针对 3.5 版本进行了完整重写与梳理，清理修复了大量过时信息。目前仅提供英文版本，简体中文支持即将推出。

架构优化

Pigsty v3.5 对 PGSQL 实现进行了深度优化：

  • 合并减少任务数量
  • 微调可用任务标签
  • 统一模板文件命名
  • 优化现代 NVMe 环境下的系统与数据库参数默认值
  • 调整 roles 分工

重要变更：彻底移除了 pgsql.yml 剧本的删库功能。从 v3.5 起，删库操作仅能通过 pgsql-rm.yml 专用剧本执行，不再需要各种"安全阀"和"保险栓"。

重构后的 PGSQL 剧本任务：

重构后的 pgsql-rm.yml 剧本任务：

命令行优化

pig 命令行工具新增 do 子命令，可替代原来 pigsty/bin 目录下的包装脚本，以统一、标准化的方式执行各类任务。

目前处于试点阶段，API 尚未最终固定，计划经过一段时间打磨后正式发布文档。

监控优化

Grafana 12.0 发布，带来了不少 Breaking Changes，监控系统也相应进行了改进。

针对来自 Oracle DBA 用户提出的 AWR 需求进行了分析：其中大部分指标 PG 和 Pigsty 已经提供，唯一的例外是 等待事件。

PG 内核本身只提供当前活动的等待状态，但没有历史等待事件记录。这只能通过插件实现 —— pg_wait_sampling 和 pgsentinel 都提供了此功能，监控面板也已支持等待事件分析。

Apple Vagrant 支持

Pigsty 提供 Vagrant / Terraform 沙箱模板，允许用户在本地/云端轻松拉起所需的虚拟机资源。此前 Vagrant / VirtualBox 对 Apple ARM 架构支持存在各种问题，经过重新测试，Vagrant + VirtualBox 组合现已在 Apple Silicon 上丝滑运行。

虽然并非所有 Vagrant Box 都提供了 ARM64 on VirtualBox 支持，但主要的 EL9 和 Ubuntu 24.04 已支持。这意味着用户可以在 Apple MacBook（无论是 Intel 还是 M 系列 ARM 架构）上顺畅拉起虚拟机并运行 Pigsty。

下一步规划

下一个版本可能是 v3.6 或 v4.0。Pigsty v4.0 预计随 PostgreSQL 18 正式版一同发布（9 月）。

计划中的改进：

领域 规划
操作系统 新增 EL 10 支持，编译打包所有扩展
日志收集 promtail 替换为 vector
安装流程 简化为三步走（Install / Configure / Deploy）
许可证 考虑推出 Apache 许可的轻量化版本

v3.5.0

Pigsty v3.5.0 版本发布，支持 PostgreSQL 18 Beta！

curl https://repo.pigsty.cc/get | bash -s v3.5.0

亮点特性

  • 支持 PG 18 (Beta)，扩展更新，总数达到 421 个
  • OrioleDB 与 OpenHalo 内核在全平台上可用
  • 可使用 pig do 子命令代替 bin 脚本
  • Supabase 自建加强，解决若干遗留问题，例如复制延迟与密钥分发
  • 代码重构与架构优化，优化了 Postgres 与 Pgbouncer 默认参数
  • 更新了 Grafana 12, pg_exporter 1.0 与相关插件，翻修面板

PostgreSQL 18 支持

  • 支持 PostgreSQL 18
  • 通过 pg_exporter 1.0.0 支持 PG18 监控指标
  • 通过 pig 0.4.1 支持 PG18 安装 Alias
  • 提供 pg18 配置模板

代码重构

  • PGSQL 重构，将 PG 监控抽离为单独的 pg_monitor 角色，移除 clean 逻辑
  • 去除冗余重复的任务，合并同类项，精简配置。移除 dir/utils 任务块
  • 所有扩展默认安装至 extensions 模式中（与 supabase 安全实践保持一致）
  • 重命名模板文件，移除所有 .j2 后缀
  • 为所有模板中的 monitor 函数添加 SET 命令清空 search_path，遵循 Supabase 安全最佳实践
  • 调整 pgbouncer 默认参数，增大默认链接池大小，设置链接池清理查询
  • 新增参数 pgbouncer_ignore_param，允许配置 pgbouncer 忽略的参数列表
  • 新增任务 pg_key 用于生成 pgsodium 所需的服务端密钥
  • 针对 PG 17 默认启用 sync_replication_slots
  • 重新调整了子任务标签，使其更符合配置小节的拆分逻辑

模块重构

  • 重构 pg_remove 模块
    • 重命名参数：pg_rm_data, pg_rm_bkup, pg_rm_pkg 用于控制删除的内容
    • 重新调整角色代码结构，使用更清楚的标签进行划分
  • 新增 pg_monitor 模块
    • pgbouncer_exporter 现在不再和 pg_exporter 共享配置文件
    • 新增了 TimescaleDB，Citus，pg_wait_event 的监控指标
    • 使用 pg_exporter 1.0.0，更新了 PG16/17/18 相关监控指标
    • 使用更为紧凑，全新设计的指标收集器配置文件

Supabase 加强

感谢来自 @lawso017 的贡献！

  • 将 Supabase 容器镜像与数据库模式更新至最新版本
  • 现在默认支持 pgsodium 服务端密钥加载
  • 通过 supa-kick 定时任务解决 logflare 无法及时更新复制进度的问题
  • 为 monitor 模式中的函数添加 set search_path 子句以遵循安全最佳实践

CLI 与监控更新

  • CLI 新增 pig do 命令，允许通过命令行工具替代 bin/ 中的 Shell 脚本
  • 更新 Grafana 大版本至 12.0.0，更新相关插件/数据源软件包
  • 更新 Postgres 数据源 uid 命名方式（以适应新的 uid 长度限制与字符限制）
  • 新增了 Static Datasource
  • 更新了现有 Dashboard，修复若干遗留问题

基础设施软件包更新

  • pig 0.4.2
  • duckdb 1.3.0
  • etcd 3.6.0
  • vector 0.47.0
  • minio 20250422221226
  • mcli 20250416181326
  • pev 1.5.0
  • rclone 1.69.3
  • mtail 3.0.8 (new)

可观测性软件包更新

  • grafana 12.0.0
  • grafana-victorialogs-ds 0.16.3
  • grafana-victoriametrics-ds 0.15.1
  • grafana-infinity-ds 3.2.1
  • grafana_plugins 12.0.0
  • prometheus 3.4.0
  • pushgateway 1.11.1
  • nginx_exporter 1.4.2
  • pg_exporter 1.0.0
  • pgbackrest_exporter 0.20.0
  • redis_exporter 1.72.1
  • keepalived_exporter 1.6.2
  • victoriametrics 1.117.1
  • victoria_logs 1.22.2

数据库软件包更新

  • PostgreSQL 17.5, 16.9, 15.13, 14.18, 13.21
  • PostgreSQL 18beta1 支持
  • pgbouncer 1.24.1
  • pgbackrest 2.55
  • pgbadger 13.1

PG 扩展包更新

  • spat 0.1.0a4 新扩展
  • pgsentinel 1.1.0 新扩展
  • pgdd 0.6.0 (pgrx 0.14.1) 新扩展
  • convert 0.0.4 (pgrx 0.14.1) 新扩展
  • pg_tokenizer.rs 0.1.0 (pgrx 0.13.1)
  • pg_render 0.1.2 (pgrx 0.12.8)
  • pgx_ulid 0.2.0 (pgrx 0.12.7)
  • pg_idkit 0.3.0 (pgrx 0.14.1)
  • pg_ivm 1.11.0
  • orioledb 1.4.0 beta11 新增 debian/ubuntu 支持
  • openhalo 14.10 新增 debian/ubuntu 支持
  • omnigres 20250507 (在 d12/u22 编译最新版本失败)
  • citus 12.0.3
  • timescaledb 2.20.0 (移除 PG14 支持)
  • supautils 2.9.2
  • pg_envvar 1.0.1
  • pgcollection 1.0.0
  • aggs_for_vecs 1.4.0
  • pg_tracing 0.1.3
  • pgmq 1.5.1
  • tzf-pg 0.2.0 (pgrx 0.14.1)
  • pg_search 0.15.18 (pgrx 0.14.1)
  • anon 2.1.1 (pgrx 0.14.1)
  • pg_parquet 0.4.0 (0.14.1)
  • pg_cardano 1.0.5 (pgrx 0.12) -> 0.14.1
  • pglite_fusion 0.0.5 (pgrx 0.12.8) -> 14.1
  • vchord_bm25 0.2.1 (pgrx 0.13.1)
  • vchord 0.3.0 (pgrx 0.13.1)
  • pg_vectorize 0.22.1 (pgrx 0.13.1)
  • wrappers 0.4.6 (pgrx 0.12.9)
  • timescaledb-toolkit 1.21.0 (pgrx 0.12.9)
  • pgvectorscale 0.7.1 (pgrx 0.12.9)
  • pg_session_jwt 0.3.1 (pgrx 0.12.6) -> 0.12.9
  • pg_timetable 5.13.0
  • ferretdb 2.2.0
  • documentdb 0.103.0 (新增 aarch64 支持)
  • pgml 2.10.0 (pgrx 0.12.9)
  • sqlite_fdw 2.5.0 (fix pg17 deb)
  • tzf 0.2.2 0.14.1 (rename src)
  • pg_vectorize 0.22.2 (pgrx 0.13.1)
  • wrappers 0.5.0 (pgrx 0.12.9)

校验和 

ab91bc05c54b88c455bf66533c1d8d43  pigsty-v3.5.0.tgz
4c9fabc2d1f0ed733145af2b6aff2f48  pigsty-pkg-v3.5.0.d12.x86_64.tgz
796d47de12673b2eb9882e527c3b6ba0  pigsty-pkg-v3.5.0.el8.x86_64.tgz
a53ef2cede1363f11e9faaaa43718fdc  pigsty-pkg-v3.5.0.el9.x86_64.tgz
36da28f97a845fdc0b7bbde2d3812a67  pigsty-pkg-v3.5.0.u22.x86_64.tgz
8551b3e04b38af382163e6857778437d  pigsty-pkg-v3.5.0.u24.x86_64.tgz

更多版本信息请参考 GitHub 发布页面。

24 - 影视飓风达芬奇千万级数据库演化及实践

原文发布于 VONNG。

原作者：龚锐

老冯喜欢摄影，很早就关注了影视飓风。但俺也没有想到有一天还会出现这种交集：开源 PostgreSQL RDS 软件 Pigsty 有一天会被影视飓风用在影视行业里，用于支持达芬奇这种行业软件。

在 影视飓风达芬奇千万级数据库演化及实践 一文中，影视飓风的专家们分享了他们是如何使用 Pigsty 来解决达芬奇的各种问题。比如高可用，高级权限管控，误删回滚，读写分离，以及简化维护。

本文将介绍影视飓风达芬奇项目数据库建设的过程中遇到的问题和解决方案

01

OVERVIEW

达芬奇概述

图片 达芬奇（DaVinci Resolve）是由 Blackmagic Design 开发的一款专业的视频编辑、调色、特效和音频处理软件，被电影、影视、广告等各类视频制作场景下广泛应用。
图片

达芬奇的项目库（Project Libraries）用于协作工作流程中，它允许多个用户在同一个网络中同时访问和操作项目，支持团队的实时协作。这对制作复杂的影视项目时尤为有用，在后期制作中，剪辑、调色、音频等各类工种可以同时处理不同部分的工作。可以通过官方应用得出该功能就是**依赖 PostgreSQL 数据库实现**的。
图片

02

EVOLUTION PATH

数据库演进路径

图片图片

2019 年 - 达芬奇官方应用（DaVinci Resolve Project Server） 

随着业务体量的不断增加，达芬奇官方应用的单体架构渐渐暴露出诸多不足，如容易造成单点故障、无官方实现的自动备份、权限管控难度大、维护不便等问题。

2023 年 4 月 - Docker 容器化

Docker 带来的弊端也立马显现出来，具体可以阅读这篇文章。我们在使用 Docker 方案半年后，迅速评估转舵更换方案，迭代为目前的高可用集群。\

2024 年 1 月 - 高可用集群

经过对比选型后，采用了开源的 [Pigsty](/zh/blog/article/v3.4/) 方案。集群配置为一主两从，当主节点故障时，其中一个从节点将成为主节点，并将故障节点降级隔离。底层虚拟机采用双服务器集群避免硬件或网络造成的中断，当有故障时可在毫秒级内完成自动迁移，用户体感仅为闪断。
图片

高可用集群架构图

图片

集群监控 Dashboard

03

DIFFICULTY

技术难点

图片
对于达芬奇这种“黑盒应用”来说，我们无法改变软件自身逻辑，仅能从数据库方面进行优化。或许达芬奇在设计之初为了避免数据库架构的复杂性和潜在的同步问题，它舍弃了很多高级的数据库功能，比如无法在协作模式使用连接池、不能仅开放只读权限等。这对我们的优化及管理带来了很大挑战。

04

PITR

时间点恢复

图片
针对误操作、误删等场景，目前实现了恢复至过去一周内的任意时间点的能力。剪辑师仅需告知操作时间点，BDA 同学可在几分钟内将数据库滚回至恢复专用数据库中将该项目提取出来。

05

PERMISSION

权限治理

图片
通过 LDAP 组件对接影视飓风 SSO 统一登录平台的账户体系及角色身份，虽然由于软件限制无法做到一键单点登录，但与 SSO 账号密码一致，避免了用户维护多套账号。

除 DBA 账户外，常规角色为最小化权限，仅可连接数据库、新建数据、修改数据、删除数据等必要功能。

用户操作均有安全审计记录，这也是企业安全场景下必不可少的一环，可留存用户对数据库的访问、操作记录，异常操作后可追溯，保护了数据安全。
图片

用户列表 &权限

06

EXPERIENCE

踩坑经验

图片

**现象：在 2024 年 5 月 8 日 11:35 分开始有多位后期同学反馈达芬奇数据库连接中断情况。**定位 &处理：

  • [11:36] 查看节点状态，发现全部离线，LDAP 等相关依赖组件一切正常

  • [11:43]查看日志后发现抛出大量 etcd 容量满及停止服务相关告警

  • [11:46]为了在最短时间内恢复业务使用，我们先尝试使用手动清理碎片的形式释放空间

  • [11:50]重启 etcd 和 HAProxy

  • [11:52]节点上线，业务恢复

由于 etcd 基础服务集群容量配额写满导致集群管控平面失效，但未对数据平面造成影响。

etcd 是一个分布式的、可靠的键-值存储，用于存放系统中最为关键的数据，Pigsty 使用 etcd 作为 Patroni 的 DCS（分布式配置存储）服务，用于存储 PostgreSQL 集群的高可用状态信息。

******根因：**未开启 etcd 自动压实功能，且默认仅为 2GB 容量。

07

LAUNCH

上线收益

图片

  • 数据零丢失

  • 99.99% 服务可用性

  • 通过时间点恢复回滚近十次误操作

- End -

老冯评论

老冯喜欢摄影，很早就关注了影视飓风。但俺也没有想到有一天还会出现这种交集：开源 PostgreSQL RDS 软件 Pigsty 有一天会被影视飓风用在影视行业里，用于支持达芬奇这种行业软件。

在 影视飓风达芬奇千万级数据库演化及实践 一文中，影视飓风的专家们分享了他们是如何使用 Pigsty 来解决达芬奇的各种问题。比如高可用，高级权限管控，误删回滚，读写分离，以及简化维护。

达芬奇官方单体应用内置了一个 PostgreSQL 数据库，用于本地存储项目和数据库信息。这个数据库通常是在单机模式下运行，并且是自动配置好的，不需要用户手动设置或配置。但如果要团队协作，那么还是要专门拉起一个共享的 PostgreSQL 数据库实例来使用。

当我看到影视行业的专家们竟然还会专门开一门课来介绍 “达芬奇的 PostgreSQL 权威配置指南” 时，我确实是吃了一惊：https://medium.com/@sethgoldin/the-definitive-guide-to-postgresql-for-davinci-resolve-c3fcb36a1561。

图片

但这确实是一个需要自建本地 RDS 的有趣场景。因为用一个远程的云厂商 PG RDS，响应时间对影视编辑团队协同的场景来说实在是太高了，而 Pigsty 这样的本地 PG RDS 自建方案可以恰到好处的解决这些问题 —— 即使没有专业 DBA，也可以自建高水准的本地 PG 数据库服务，从搞了近十次 PITR 误删回滚恢复来看，他们玩的还是很溜的。

正如微软 CEO 纳德拉所说，你喜欢的软件应用在本质上都是数据库套壳 （SaaS 已死？AI 时代，软件从数据库开始）。对于达芬奇这种“黑盒应用”来说，用户确实没有办法改变软件本身的逻辑。但可以通过使用更好的 PostgreSQL RDS，来为现有软件添加这些强大的能力 —— 更好的业务连续性与数据持久性，回滚到过去一周任意时间点的魔法，以及精细化的权限管理。

发布版本：微信公众号转载页

25 - Pigsty v3.4：备份恢复增强，本地化排序，自动证书

原文发布于 VONNG。

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

经过一个月的密集开发，Pigsty v3.4 正式发布。本版本进行了显著的架构优化，解决了用户和客户高度关注的几个核心问题：

  • 将一套集群的物理备份 PITR 恢复到另一套集群
  • pgBackRest 备份组件的监控指标与面板
  • 自建应用时自动申请 HTTPS 证书
  • 本地化排序规则与字符集的最佳实践
  • Oracle 兼容的 IvorySQL 现已全平台可用
  • 图数据库扩展 Apache AGE 现已全平台可用

此外，基于 Cursor Vibe Coding 打造了全新的价值主张/特性介绍页面：https://pigsty.cc/about/values/

自动申请证书

不少用户因自建 Dify、Odoo、Supabase 而使用 Pigsty。用户反馈证书申请步骤有些繁琐，需要手动调用 certbot，希望将其自动化。

本版本对 Nginx 配置进行了增强：当用户在某个 Nginx Server 上定义 certbot 字段时，可使用 make cert 命令一键完成证书申请与应用，无需其他配置与命令。

Dify、Odoo、Supabase 等应用自建模板均已采用此功能。安装完成后，make cert 即可自动更新或新申请所需证书。若配置 certbot_sign = true，则在安装过程中自动申请证书。

v3.4 中 Nginx 的可配置项更加丰富：可使用 config 向 nginx 注入配置，使用 enforce 强制重定向 HTTPS。自建网站在绝大多数场景下可做到完全不碰传统 Nginx 配置文件。

本地化排序最佳实践

许多程序员对 Locale/Collation 规则不太了解，但这确实是一个相当重要的配置。使用不当的 Collation 不仅可能带来数倍性能损失，还可能导致数据不一致甚至数据丢失 —— 索引与排序规则紧密相关，Collation 绝非无关紧要的配置。

推荐阅读：

最佳实践：始终使用 C 或 C.UTF-8 作为 Locale 排序规则。

  • C：兼容性最好，所有系统都支持，但缺少 Unicode 字符集知识，除 ASCII 外的字符大小写功能失灵
  • C.UTF-8：在 C 基础上实现 Unicode 语义，更符合用户直觉，但并非所有系统默认支持
  • PostgreSQL 17 新特性：内置对这两种 Collation 的支持，不再依赖操作系统的 libc

Pigsty v3.4 反映了这种最佳实践：

  • 所有 Locale 相关参数默认值统一使用 C（主要是 pg_lc_ctypes 从 en_US.UTF-8 变为 C），确保在任何系统上都能运行
  • 自动配置时，若检测到 PG >= 17 或系统明确支持 C.utf8，将 Locale 配置为 C.UTF-8 以获得更好的 Unicode 语义

除非数据库密集工作在特定语言排序场景，否则此默认值即为最佳实践。可使用 PostgreSQL COLLATION 语法在查询/索引/列上指定其他排序规则，PG + ICU 共支持 841 种排序规则。

时间点恢复增强

时间点恢复是关系型数据库的核心功能。此前 Pigsty 通过 pg-pitr 辅助用户执行半自动 PITR。v3.4 对 PITR 支持进行了显著改进，现可方便地从集中式备份仓库中选择任意备份进行恢复。

在 PG 集群上定义 pg_pitr 参数时，Pigsty 会自动生成 /pg/bin/pg-restore 命令及 /pg/conf/pitr.conf 配置文件。

执行 pg-restore 命令时，Pigsty 会自动暂停 Patroni 集群、关闭 PG、开始原地增量 PITR、恢复到指定位点后拉起 PG。重要改进：使用集中式备份仓库时，可用其他集群的备份覆盖当前集群。

备份监控方面，v3.4 引入了 pgbackrest_exporter 用于收集备份监控指标，PGSQL PITR 监控面板也会显示当前备份状态。此前用户只能通过 PGCAT Instance 查询当前状态，而无历史记录，本次改进对分析备份状态大有帮助。

扩展插件更新

经过持续一年的扩展生态扩张，Pigsty 已收录 PG 生态中几乎所有主流扩展，数量达到 405 个。扩展突飞猛进的阶段已基本结束，近期版本将重心放回架构与基础设施，扩展以巩固为主。

v3.4 新增扩展 pgspider_ext，利用各种 FDW 实现多数据源查询。同时有 28 个扩展更新至最新版本，并修复了若干扩展的版本与 Bug。

Apache AGE 图数据库扩展：该项目的开发者似乎被裁员，基本进入无维护状态。作为发行版，Pigsty 尽力为其提供支持 —— 根据 Debian 上的 Patch 重新编译了 AGE 1.5.0 的 PG 13-17 扩展，补上了缺少 EL RPM 的遗憾。

多内核支持更新

Pigsty v3.4 更新了 PolarDB、IvorySQL、Babelfish 最新版本支持。

继 PolarDB 之后，IvorySQL 成为第二个在 Pigsty 支持的十大 Linux 发行版上全平台可用的 PostgreSQL 内核。除扩展插件外，IvorySQL 4.4 的体验基本与 PostgreSQL 17.4 一致。

使用 IvorySQL（Oracle 兼容模式）只需修改四个参数：

pg_mode: ivory                                                 # 使用 IvorySQL 兼容模式
pg_packages: [ ivorysql, pgsql-common ]                        # 安装 IvorySQL 软件包
pg_libs: 'liboracle_parser, pg_stat_statements, auto_explain'  # 加载 Oracle 兼容扩展
repo_extra_packages: [ ivorysql ]                              # 下载 IvorySQL 软件包

同时更新了 Supabase 模板至最新版本，将 Citus 更新至 13.0.2。下一步将关注专注 OLTP 性能的 OrioleDB 以及提供 MySQL 协议兼容性的 OpenHalo 内核。

基础设施强化

v3.4 更新了许多 Infra 软件包版本，新增组件：

组件 说明
JuiceFS 将 S3/MinIO 挂载为本地文件系统
Restic 类似 pgBackRest 但用于文件备份
TimescaleDB EventStreamer 抽取 TimescaleDB 超表数据变更流

这些组件现已默认下载，可直接安装使用。

另一变化：以下软件包新增到默认下载列表：

docker-ce docker-compose-plugin ferretdb2 duckdb restic juicefs vray grafana-infinity-ds

Docker 使用量确实很大，主要用于运行 pgAdmin 等软件，因此将其纳入默认下载。

v3.5 特性展望

v3.5 计划功能：

领域 规划
CLI pig 命令行完整封装 Pigsty Playbook
配置 Vibe Config Wizard 配置向导与 MCP Server
Docker Debian 12 x86/ARM Pigsty Docker 镜像
内核 OrioleDB 与 OpenHalo 支持

v3.4.0

Pigsty v3.4.0 版本发布，MySQL 兼容性与全面增强！

curl https://repo.pigsty.cc/get | bash -s v3.4.0

新功能

  • 增加了新的 pgBackRest 备份监控指标和仪表板
  • 增强了 Nginx 服务器配置选项，支持自动 Certbot 签发
  • 现在优先使用 PostgreSQL 内置的 C/C.UTF-8 区域设置
  • IvorySQL 4.4 现在在所有平台上完全支持（RPM/DEB 在 x86/ARM 上）
  • 增加了新的软件包：Juicefs、Restic、TimescaleDB EventStreamer
  • Apache AGE 图数据库扩展现在在 EL 上完全支持 PostgreSQL 13–17
  • 改进了 app.yml playbook：无需额外配置即可启动标准 Docker 应用
  • 升级 Supabase、Dify 和 Odoo 应用模板到最新版本
  • 增加 electric 应用模板，本地优先的 PostgreSQL 同步引擎

基础设施包

  • +restic 0.17.3
  • +juicefs 1.2.3
  • +timescaledb-event-streamer 0.12.0
  • Prometheus 3.2.1
  • AlertManager 0.28.1
  • blackbox_exporter 0.26.0
  • node_exporter 1.9.0
  • mysqld_exporter 0.17.2
  • kafka_exporter 1.9.0
  • redis_exporter 1.69.0
  • pgbackrest_exporter 0.19.0-2
  • DuckDB 1.2.1
  • etcd 3.5.20
  • FerretDB 2.0.0
  • tigerbeetle 0.16.31
  • vector 0.45.0
  • VictoriaMetrics 1.113.0
  • VictoriaLogs 1.17.0
  • rclone 1.69.1
  • pev2 1.14.0
  • grafana-victorialogs-ds 0.16.0
  • grafana-victoriametrics-ds 0.14.0
  • grafana-infinity-ds 3.0.0

PostgreSQL 相关

  • Patroni 4.0.5
  • PolarDB 15.12.3.0-e1e6d85b
  • IvorySQL 4.4
  • pgbackrest 2.54.2
  • pev2 1.14
  • WiltonDB 13.17

PostgreSQL 扩展

  • pgspider_ext 1.3.0（新扩展）
  • apache age 13–17 el rpm (1.5.0)
  • timescaledb 2.18.2 → 2.19.0
  • citus 13.0.1 → 13.0.2
  • documentdb 1.101-0 → 1.102-0
  • pg_analytics 0.3.4 → 0.3.7
  • pg_search 0.15.2 → 0.15.8
  • pg_ivm 1.9 → 1.10
  • emaj 4.4.0 → 4.6.0
  • pgsql_tweaks 0.10.0 → 0.11.0
  • pgvectorscale 0.4.0 → 0.6.0 (pgrx 0.12.5)
  • pg_session_jwt 0.1.2 → 0.2.0 (pgrx 0.12.6)
  • wrappers 0.4.4 → 0.4.5 (pgrx 0.12.9)
  • pg_parquet 0.2.0 → 0.3.1 (pgrx 0.13.1)
  • vchord 0.2.1 → 0.2.2 (pgrx 0.13.1)
  • pg_tle 1.2.0 → 1.5.0
  • supautils 2.5.0 → 2.6.0
  • sslutils 1.3 → 1.4
  • pg_profile 4.7 → 4.8
  • pg_snakeoil 1.3 → 1.4
  • pg_jsonschema 0.3.2 → 0.3.3
  • pg_incremental 1.1.1 → 1.2.0
  • pg_stat_monitor 2.1.0 → 2.1.1

接口变更

  • 增加了新的 Docker 参数：docker_data 和 docker_storage_driver（#521 由 @waitingsong 提供）
  • 增加了新的基础设施参数：alertmanager_port，让您指定 AlertManager 端口
  • 增加了新的基础设施参数：certbot_sign，在 nginx 初始化期间申请证书？（默认为 false）
  • 增加了新的基础设施参数：certbot_email，指定通过 Certbot 请求证书时使用的邮箱
  • 增加了新的基础设施参数：certbot_options，指定 Certbot 的额外参数
  • 更新 IvorySQL，从 IvorySQL 4.4 开始将其默认二进制文件放在 /usr/ivory-4 下
  • 将 pg_lc_ctype 和其他区域相关参数的默认值从 en_US.UTF-8 更改为 C
  • 对于 PostgreSQL 17，如果使用 UTF8 编码与 C 或 C.UTF-8 区域，PostgreSQL 的内置本地化规则现在优先
  • configure 自动检测 PG 版本和环境是否都支持 C.utf8，并相应调整区域相关选项
  • 将默认 IvorySQL 二进制路径设置为 /usr/ivory-4
  • 更新 pg_packages 的默认值为 pgsql-main patroni pgbouncer pgbackrest pg_exporter pgbadger vip-manager
  • 更新 repo_packages 的默认值为 [node-bootstrap, infra-package, infra-addons, node-package1, node-package2, pgsql-utility, extra-modules]
  • 从 /etc/profile.d/node.sh 中删除 LANG 和 LC_ALL 环境变量设置
  • 现在使用 bento/rockylinux-8 和 bento/rockylinux-9 作为 EL 的 Vagrant box 镜像
  • 增加了新别名 extra_modules，包含额外的可选模块
  • 更新 PostgreSQL 别名：postgresql、pgsql-main、pgsql-core、pgsql-full
  • GitLab 仓库现在包含在可用模块中
  • Docker 模块已合并到基础设施模块中
  • node.yml playbook 现在包含 node_pip 任务，在每个节点上配置 pip 镜像
  • pgsql.yml playbook 现在包含 pgbackrest_exporter 任务，用于收集备份指标
  • Makefile 现在允许使用 META/PKG 环境变量
  • 增加 /pg/spool 目录作为 pgBackRest 的临时存储
  • 默认禁用 pgBackRest 的 link-all 选项
  • 默认为 MinIO 仓库启用块级增量备份

错误修复

  • 修复 pg-backup 中的退出状态码（#532 由 @waitingsong 提供）
  • 在 pg-tune-hugepage 中，限制 PostgreSQL 仅使用大页面（#527 由 @waitingsong 提供）
  • 修复 pg-role 任务中的逻辑错误
  • 纠正大页面配置参数的类型转换
  • 修复 slim 模板中 node_repo_modules 的默认值问题

校验和 

768bea3bfc5d492f4c033cb019a81d3a  pigsty-v3.4.0.tgz
7c3d47ef488a9c7961ca6579dc9543d6  pigsty-pkg-v3.4.0.d12.aarch64.tgz
b5d76aefb1e1caa7890b3a37f6a14ea5  pigsty-pkg-v3.4.0.d12.x86_64.tgz
42dacf2f544ca9a02148aeea91f3153a  pigsty-pkg-v3.4.0.el8.aarch64.tgz
d0a694f6cd6a7f2111b0971a60c49ad0  pigsty-pkg-v3.4.0.el8.x86_64.tgz
7caa82254c1b0750e89f78a54bf065f8  pigsty-pkg-v3.4.0.el9.aarch64.tgz
8f817e5fad708b20ee217eb2e12b99cb  pigsty-pkg-v3.4.0.el9.x86_64.tgz
8b2fcaa6ef6fd8d2726f6eafbb488aaf  pigsty-pkg-v3.4.0.u22.aarch64.tgz
83291db7871557566ab6524beb792636  pigsty-pkg-v3.4.0.u22.x86_64.tgz
c927238f0343cde82a4a9ab230ecd2ac  pigsty-pkg-v3.4.0.u24.aarch64.tgz
14cbcb90693ed5de8116648a1f2c3e34  pigsty-pkg-v3.4.0.u24.x86_64.tgz

更多版本信息请参考 GitHub 发布页面。

v3.4.1

Pigsty v3.4.1 版本发布，新增 openHalo 与 OrioleDB 内核支持！

curl https://repo.pigsty.cc/get | bash -s v3.4.1

亮点特性

  • 在 EL 系统上增加了对 MySQL 协议兼容 PostgreSQL 内核的支持：openHalo
  • 在 EL 系统上增加了对 OLTP 增强 PostgreSQL 内核的支持：orioledb
  • 优化了 pgAdmin 9.2 应用模板，具有自动服务器列表更新和 pgpass 密码填充功能
  • 将 PG 默认最大连接数增加到 250、500、1000
  • 从 EL8 中删除了有依赖错误的 mysql_fdw 扩展

基础设施更新

  • pig 0.3.4
  • etcd 3.5.21
  • restic 0.18.0
  • ferretdb 2.1.0
  • tigerbeetle 0.16.34
  • pg_exporter 0.8.1
  • node_exporter 1.9.1
  • grafana 11.6.0
  • zfs_exporter 3.8.1
  • mongodb_exporter 0.44.0
  • victoriametrics 1.114.0
  • minio 20250403145628
  • mcli 20250403170756

扩展更新

  • 将 pg_search 升级到 0.15.13
  • 将 citus 升级到 13.0.3
  • 将 timescaledb 升级到 2.19.1
  • 将 pgcollection RPM 升级到 1.0.0
  • 将 pg_vectorize RPM 升级到 0.22.1
  • 将 pglite_fusion RPM 升级到 0.0.4
  • 将 aggs_for_vecs RPM 升级到 1.4.0
  • 将 pg_tracing RPM 升级到 0.1.3
  • 将 pgmq RPM 升级到 1.5.1

校验和 

471c82e5f050510bd3cc04d61f098560  pigsty-v3.4.1.tgz
4ce17cc1b549cf8bd22686646b1c33d2  pigsty-pkg-v3.4.1.d12.aarch64.tgz
c80391c6f93c9f4cad8079698e910972  pigsty-pkg-v3.4.1.d12.x86_64.tgz
811bf89d1087512a4f8801242ca8bed5  pigsty-pkg-v3.4.1.el9.x86_64.tgz
9fe2e6482b14a3e60863eeae64a78945  pigsty-pkg-v3.4.1.u22.x86_64.tgz

更多版本信息请参考 GitHub 发布页面。

26 - Pigsty v3.3：扩展突破400，丝滑建站，应用模板

原文发布于 VONNG。

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

经过两个月的精心打磨，Pigsty v3.3 正式发布。作为开源的"开箱即用" PostgreSQL 发行版，Pigsty 旨在凝聚 PG 生态的合力，为本地自建提供与云上 RDS 媲美的免运维便捷体验。

本版本聚焦三个关键领域：扩展插件、建站体验 和 应用模板，大幅增强了开发、运维、部署等多方面的能力。

可用扩展突破 400+

PostgreSQL 以其丰富的扩展机制著称，孕育了庞大的数据库生态。Pigsty 将 PostgreSQL 的插件扩展能力发挥到极致。

一年前《PostgreSQL正在吞噬数据库世界》一文发布时，Pigsty 可用扩展约 150 个，主要来自 PG 自带（70）和 PGDG 官方仓库。

如今 Pigsty v3.3 将可用扩展数量推至 404 个！用户几乎可以即插即用任何想要的 PostgreSQL 插件，更重要的是能像搭积木一样组合这些扩展。

值得关注的新扩展：

扩展 说明
PGDocumentDB 微软开源，赋予 PostgreSQL 文档数据库能力
PGCollection AWS 出品，高性能内存优化集合数据类型
pg_tracing DataDog 开源，分布式调用链追踪
pg_curl 支持数十种网络协议发起请求
pgpdf 直接读取存储 PDF，SQL 全文检索 PDF 内容
Omni 系列 Omnigres 开发的 30+ 扩展，用于 PG 中进行 Web 应用开发

Pigsty 与 Omnigres 达成深度合作伙伴关系：Pigsty 整合分发 Omnigres 扩展，Omnigres 作为下游将 Pigsty 扩展仓库中的扩展交付给其用户，实现互惠共赢。

FerretDB 2.0：PostgreSQL 变身 MongoDB

与 FerretDB 团队合作，交付基于 PostgreSQL 的 MongoDB 方案。FerretDB 2.0 使用微软开源的 DocumentDB 作为后端实现，提供更好的性能与更完善的功能。

可将 PG 变为核心功能完备的 MongoDB 5.0，使用 MongoDB 客户端与线缆协议访问 PostgreSQL 中的数据。

DuckDB 缝合大赛持续进行

Pigsty v3.3 第一时间跟进了 pg_duckdb 0.3.1、pg_mooncake 0.1.2、pg_analytics 0.5.4 最新版本，从不同维度为 PostgreSQL 添加比肩 ClickHouse 的分析能力。

在 ClickHouse 自家榜单 ClickBench 上，PG 扩展 mooncake 已成功挤进 Top 10 T1 梯队。在激烈的竞争角逐下，PostgreSQL 生态很快会出现比肩向量数据库生态中 pgvector 的 OLAP 玩家。

pig 与扩展仓库

如此多扩展插件的安装管理成为难题，Pigsty 的解决方案是 pig 命令行工具与扩展仓库。一行命令即可在 PostgreSQL 上拥有 400 个扩展合体的超能力 —— 即使不用 Pigsty 也没问题。

虽然独一无二的扩展库可作为 Pigsty 的核心竞争优势，但更希望为 PostgreSQL 生态做出更多贡献。因此 pig 包管理器与 PostgreSQL 扩展仓库基于 Apache 2.0 宽松协议开源，对公众与同行开放。

已有多家 PostgreSQL 厂商基于 Pigsty 扩展仓库安装扩展，成为 Pigsty 的下游。这是一种扎实参与全球软件供应链的方式。

建站体验：Nginx IaC 与免费 HTTPS 证书

Pigsty 不仅是 PostgreSQL 发行版，还是完整的监控基础设施、Etcd、MinIO、Redis、Docker 部署管理方案，甚至可作为 Web 建站工具。

Pigsty 提供全功能的 Nginx 配置方案和证书申请 SOP，其网站和软件仓库就是使用 Pigsty 本身搭建的。

只需在配置文件中定义 Nginx Server，Pigsty 即可自动创建所需配置并申请 HTTPS 证书。

Pigsty v3.2 已将 certbot 整合并默认安装，可一行命令完成 HTTPS 证书申请与续签。可用 Nginx 代理各种服务，使用不同域名区分，统一收口到 80/443 端口对外服务 —— 只需打开入站 80/443 TCP 端口即可。

应用模板：Docker 软件一键交付

许多软件都会用到 PostgreSQL，此前 Pigsty 提供 Docker Compose 模板，但用户仍需手动拷贝目录、修改 .env 配置、手工拉起。

Pigsty v3.3 提供全新剧本 app.yml，将基于 PostgreSQL 的 Docker 软件交付压缩为临门一脚的一行命令。

Odoo ERP 系统：

Dify AI 工作流编排：

Supabase 自建：

从裸机到完整的生产应用服务，只需几条命令、几分钟等待。

pig 命令行能力增强

pig v0.3 新增 pig build 子命令，允许快速搭建 PG 扩展构建环境。

curl https://repo.pigsty.cc/pig | bash # 安装 pig
pig build repo        # 添加上游仓库
pig build tool        # 安装构建工具
pig build rust        # 配置 rust/pgrx 工具链（可选）
pig build spec        # 下载构建规范
pig build get citus   # 下载某个扩展源码包
pig build ext citus   # 构建某个扩展

Pigsty 维护的 200+ 扩展均通过此方式构建。即使操作系统不在 Pigsty 支持的十大发行版中，也可轻松 DIY 扩展 RPM/DEB 包。

全新网站设计

从 v3.3 开始，Pigsty 国际站 (pigsty.io) 与中文站 (pigsty.cc) 正式分离，使用独立域名、文档、Demo、仓库。

基于 Next.js 模板打造全新首页。借助 GPT o1-pro 和 Cursor 的帮助，快速完成现代 Landing Page 开发。

在托管方式上尝试了多种方案：Vercel、Cloudflare Pages、阿里云、腾讯云 EdgeOne 等。最终结论：海外全放 Cloudflare，国内用云服务器。

建站流程已高度自动化，十分钟内可在任意区域拉起 Pigsty 文档+仓库基础设施站点。

PG 扩展目录已整合到文档站 pigsty.cc/ext 中，并提供中文版本。小工具可自动扫描 Pigsty 与 PGDG 仓库扩展包版本并生成数据库记录、信息页，用户可直接从网页浏览并下载扩展 RPM/DEB 包。

多内核支持更新

v3.3 跟进了 IvorySQL 4.2（PG 17 兼容版本），解决了 pgbackrest 备份无法用于 IvorySQL 的问题。IvorySQL 运行体验现与标准 PG 内核一致。

同时推动 PolarDB 团队提供了 Debian 及 ARM64 平台的 DEB 包。PolarDB 现可在 Pigsty 支持的 10 大操作系统发行版上丝滑运行。

使用 PolarDB 内核的场景：若有"国产化"要求，PolarDB 是最简单直接、物美价廉的方案，Pigsty 能将 PolarDB 内核 RPM/DEB 封装成强大的 RDS 服务。

v3.3.0

Pigsty v3.3.0 版本发布，可用扩展总数增加到 404 个！

curl https://repo.pigsty.cc/get | bash -s v3.3.0

亮点特性

  • 可用扩展总数增加到 404 个！
  • PostgreSQL 二月小版本更新：17.4、16.8、15.12、14.17、13.20
  • 新功能：app.yml 脚本，用于自动安装 Odoo、Supabase、Dify 等应用。
  • 新功能：在 infra_portal 中进一步自定义 Nginx 配置。
  • 新功能：增加 Certbot 支持，快速申请免费 HTTPS 证书。
  • 新功能：pg_default_extensions 现在支持纯文本扩展列表。
  • 新功能：默认仓库现在包含 mongo、redis、groonga、haproxy 等。
  • 新参数：node_aliases，为节点添加命令别名。
  • 修复：解决 Bootstrap 脚本中的默认 EPEL 仓库地址问题。
  • 改进：为 Debian Security 仓库添加阿里云镜像。
  • 改进：IvorySQL 内核的 pgBackRest 备份支持。
  • 改进：PolarDB 的 ARM64 和 Debian/Ubuntu 支持。

工具改进

  • pg_exporter 0.8.0 现在支持 pgbouncer 1.24 中的新指标。
  • 新功能：git、docker、systemctl 等常用命令的自动补全 #506 #507 由 @waitingsong 提供。
  • 改进：优化 pgbouncer 配置模板中的 ignore_startup_parameters #488 由 @waitingsong 提供。

网站与文档

  • 新主页设计：Pigsty 的网站现在拥有全新的外观。
  • 扩展目录：RPM/DEB 二进制包的详细信息和下载链接。
  • 扩展构建：pig CLI 现在自动设置 PostgreSQL 扩展构建环境。

更多版本信息请参考 GitHub 发布页面。

27 - Pigsty@2024：今年没啥财运，但事儿整的还不赖

原文发布于 VONNG。

去年有大师给我算了一卦曰：明年你没财运，后年的财运一般，然后连着十年就起飞了。起飞不起飞我不知道，反正今年确实算的很准 —— 确实没啥财运。好在 —— 今年的事儿整的还不赖，哈哈。

图片

开源

GitHub 是全球一亿开发者的精神家园，全球最大的♂同性交友网站。与去年相比，今年我在 GitHub 上挣到了大概 3700 颗 Star，在全球 Star Ranking 上的排名从 483 提升 26 名至 457 位。

图片

同时，在劳模活跃榜上，今年我以 2868 个提交成为中国地区活跃度第 16 的用户，以及 3058 个 Contribution 成为国区榜 20 的用户。年底还拿了个 “开源中国 2024 年度突出贡献专家”荣誉称号。

图片

当然，这些贡献基本都围绕着 PostgreSQL 生态。主要是关于我的开箱即用的 PostgreSQL 数据库发行版 —— Pigsty 展开的。

项目

在 2024 年，Pigsty 发布了 9 个版本，特别是 v3 的发布，基本标志着这个项目已经进入了非常成熟稳定的阶段。

图片

这一年里，Pigsty 明确了自己的定位，要站在数据库（PostgreSQL 吞噬数据库世界）与云计算（下云）与两个核心趋势的交汇点上。抢占本地优先开源 RDS PG 标准（非 K8S）的生态位。

图片

Pigsty 提出了六条核心价值主张，其中首当其冲的就是 可扩展的 PostgreSQL。在年初我发表的 《PostgreSQL 正在吞噬数据库世界》一文中，我提出了扩展插件是 PG 成功的秘诀，得到了全球社区的广泛认可。而知行合一的表现就是，既然我认为扩展至关重要，是发行版的核心价值主张。那就应该去解决这个问题。

在这一点上，我还是可以比较骄傲的说，我对 PG 扩展生态做了相当显著的贡献。在过去一年里，我在编译打包维护了 PG 生态中 150 个扩展插件，超过了官方仓库维护的 100 个。并且修复了无数扩展问题，让 PG 生态开箱即用的扩展总数达到了惊人的 340 个，目前在整个 PG 生态中，没有能望其项背的竞争对手。

图片

目前来看，我觉得 PG 生态很有可能在 OLAP 大数据/实时数仓领域再次出现一个类似 PGVECTOR 向量插件这样的爆款。但不同于上次 PGVECTOR 冒头时我只能求助 PGDG Devrim 放入 PG 仓库，现在的 Pigsty 已经成了这些扩展插件分发的一个重要渠道了。

目前我已经说动了两家友商 AutoBase 和 Omnigres 使用 Pigsty 的扩展仓库作为上游，目前还在游说其他几家，总的来说我觉得问题不大，只要保持目前的态势，不难打造出一个 PG 扩展分发事实标准来。

除了扩展，Pigsty 还在另一个方向上，Pigsty 开始围绕 PostgreSQL 摊大饼，那就是 Fork 内核。Pigsty 目前支持了 Oracle 兼容的 IvorySQL，SQL Server 兼容的 WiltonDB，国产数据库 PolarDB （PG / Oracle），以及开源 Firebase，出海创业当红炸子鸡 Supabase。

马上 Neon 和 OrioleDB 也要加入进来 —— Pigsty 能为这些 PG 分支/衍生内核提供完善的高可用，备份，连接池，扩展插件。将简单的 RPM 改造成一个开箱即用的云数据库服务。这意味着只要你是 PostgreSQL 生态的内核公司（没有瞎魔改），那么你就能从 Pigsty 的工作中享受到免费红利。从而打造一个互惠共赢的生态。

指标与数据

从运营指标上看，Pigsty 从年初的 2200 Star 到年底的 3645，虽然比不了去年的 3 倍增长，但也有可观的 50% 增长，收获了 1400 多 Star。

图片

当然 Star 是一方面，主要是在全球 PostgreSQL 生态也开始有了知名度，目前在 OSS Rank 上 PG 生态开源项目排行榜中从去年的第 37 位提升到了 23 位，挤进第一页指日可待。

图片

从 Google Analytics 上来看，今年 Pigsty 网站的总访问用户达到 10 万+ （pigsty.cc 加 pigsty.io ），相比去年的 5 万 UV 翻倍。

图片

这个尖刺来自《PostgreSQL 正在吞噬数据库世界》，英文版引爆了 PG 社区，带来了大量的流量。\

而且来自海外的关注度与流量出现显著增长，去年海外用户占比大约占 20%，而今年则几乎翻倍来到了 40%

图片

商业化

今年下半年，我开始进行了一些商业化方向的尝试。老实说，这不是我喜欢干的事情。我喜欢搞纯粹的研发，产品设计，写文章营销也还行，但销售真是要了血命。所以，我的商业化策略很简单：

—— 没有销售。

在网站上放个页面，你要想买直接找我来买就好了。

图片

虽然没有销售，也没有吆喝，但就这样还是卖出了几单，基本上也就挣了个工资钱。但是知足常乐，反正我干的是自己喜欢的事，挣了钱的目标不就是为了干自己喜欢干的事么？

当然比起客户，用户侧的发展就要繁荣多了。这一年里，有许多新增的用户案例，比较知名的有 B 站，影视飓风，还有一些奇绩校友企业，一些科研院所军工部队单位都有用例，制造业，化工，新能源，各行各业基本都覆盖到了，毕竟数据库这东西太基础太万能，哪里都能用得上。特别是最近两年对 向量 pgvector 的需求激增，这带动了 PG 和 Pigsty 的显著增长。

总的来说，适当的商业化确实能解决一些现金流上的问题，有了现金流也就不用在乎融不融资了，可以开心长久地干自己喜欢的事情。\

自媒体副业

今年，自媒体算是一个副业。写公众号纯粹是为了传达自己的理念，另外就是 —— 这个时代吧，任何公司组织，都必须想办法搞流量 —— 要么去买，要么自己上，那我就只能自己上了。

关注用户数量从年初的一万八正好翻倍来到了三万六。两个专栏《数据库老司机》 和 《云计算泥石流》都有了一些口碑，在数据库领域的关注量大概是做到 Top1 了。

图片

今年虽然有很多软文生意找上门，但我还是保持住了节操 —— 我可以骄傲的宣称本号不接软文，所以我写文章的时候可以肆无忌惮地输出自己的观点，完全不顾及数据库厂商/社区和云厂商的脸面，哈哈，嘴炮很过瘾，没少得罪人，但也有了许多老铁读者与铁杆支持者。

图片

总的来说，搞的还不错，海外平台上 Medium 有了几百个订阅，X 上关注破了一万一，接近千万展现，佛系运营，也算还行吧。

图片

总结

总的来说，2024 年，全职创业的第三年。一人公司，没啥功耗，时间自由，可以做自己喜欢的事情（这里要再次感谢媳妇的大力支持），基本上是一个比较满意的状态。明年，大师说我也没啥财运，宜广结善缘，则后年腾飞矣。俺希望大师没有骗我，总之，努力干吧。

发布版本：微信公众号

28 - Pigsty v3.2：命令行工具pig，完备ARM支持，Supabase & Grafana 加强

原文发布于 VONNG。

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

Pigsty 迎来了 2024 年的最后一次发布 v3.2。本次发布带来了命令行工具 pig，以及完善的 ARM 扩展支持，两者合体，为用户带来 10 大主流 Linux 系统上丝滑的 PostgreSQL 交付能力。

本次发布例行修复了一系列问题，同时跟进了 Supabase 发布周的密集变化，并为 Grafana 扩展插件与数据源提供了 RPM/DEB 包。

Pig 命令行工具

Pigsty v3.2 默认提供命令行工具 pig，可以用来进一步简化 Pigsty 的安装部署配置过程。但 pig 并非仅仅是 Pigsty 的命令行工具，它还是一个可以独立使用的全功能 PostgreSQL 包管理器。

在安装 PostgreSQL 扩展插件时，面对各种发行版、各种芯片架构，总是困难重重：大把时间耗费在过时的 README、晦涩的配置脚本和随机的 GitHub 分支中翻找；又或者受困于国内网络环境，仓库缺失、镜像被墙，下载速度堪忧。

pig 正式登场，为打包解决所有难题。这是一个全新的、基于 Go 的包管理器，能够统一处理 PostgreSQL 及其不断扩展的扩展库，而无需陷入调试泥潭。

Pig 本身是用 Go 编写的轻量级二进制，无依赖、易安装：只需一行命令即可完成安装。它尊重操作系统的包管理传统，不重新发明轮子，基于 yum/dnf/apt 实现包管理。

Pig 专注于跨发行版的和谐 —— 无论是在 Debian、Ubuntu 还是 Red Hat 衍生版上，都可以获得单一、流畅的安装和更新 PostgreSQL 及任何扩展的方法，无需从源代码编译或处理半成品仓库。

如果说 PostgreSQL 的未来是无法阻挡的可扩展性，Pig 就是帮助解锁这种能力的工具。毕竟，没有人会抱怨 PostgreSQL 实例拥有太多扩展 —— 不用的时候没有任何影响，需要时就在手边，随取随用。

ARM 扩展仓库

Pig 的幕后支撑是一个充满稀缺扩展与新发布扩展的补充扩展仓库，因此总可以轻松获取优质扩展 —— 经过测试、精心策划并准备就绪。

在最近一个月内，Pigsty 已经为 ARM64 系统架构完成了完整的支持。对五大主流 Linux 发行版（EL8、EL9、Debian12、Ubuntu 22/24）提供了 完整 的 ARM 支持。所谓完整，是指在 AMD64 上使用的配置文件可以一模一样用在 ARM64 架构的系统上。当然存在零星例外：极个别扩展目前缺少 ARM 支持，将在后续逐一解决。

Pigsty Extension Repo 集合了 340+ 精选 PostgreSQL 扩展，编译成方便使用的 .rpm 和 .deb 包，支持多版本、多架构：

扩展类别 支持情况
TimescaleDB 时序套件 完整支持
Supabase 相关扩展 全套到位
DuckDB 分析扩展 已就绪
社区新扩展 持续收录

Pigsty 搭建了一个跨发行版的流水线，将社区自研的新扩展、历久弥新的老模块，以及官方 PGDG 包整合在一起，让它们能在 Debian、Ubuntu、Red Hat 系列等各大系统上一键无缝安装。

关键设计原则：不造轮子，而是直接基于每个发行版原生的包管理器（YUM、APT、DNF 等），保持与官方 PGDG 仓库的版本对齐。

从底层看，这个仓库是更大范围的 Pigsty PostgreSQL 发行版一部分，但也可以在自己的环境中独立使用，无需全部接纳 Pigsty。所有内容都是免费、开源的，整合起来非常轻松。已有多家 PostgreSQL 厂商将其作为额外的上游用于安装扩展。

针对 ARM64 平台的完整支持为更多芯片架构支持提供了信心。例如 IBM LinuxOne Cloud 提供的开源项目 s390x 大型机支持，Pigsty 也在评估这一方向的可能性。

Supabase 例行跟进

Pigsty 之前推出的 Supabase 自建教程 能让用户在一台机器上迅速拉起自建的 Supabase 服务。对于密集使用 Supabase 的创业群体引起了一定反响，因此持续在 Supabase 的最新版本上做跟进。

Supabase 在 2024 年的最后一个月里发布了一系列重要更新，Pigsty v3.2 也跟进了这些变化，为用户提供最新的 Supabase 版本。

Supabase 最近的一个重要动作是收购 OrioleDB —— 一个专注于提升 PostgreSQL OLTP 性能的内核分支。目前这项功能在 Supabase 中被标记为 Beta，作为用户的可选项存在。Pigsty 正在准备 OrioleDB 的 RPM/DEB 包，确保即使以后 Supabase 使用它作为主干，Pigsty 也能提供支持。

凭借这个契机，Pigsty 也准备进一步将扩展能力普及到更多的 PostgreSQL 分支上：

内核 兼容性
IvorySQL 3/4 Oracle 兼容
WiltonDB SQL Server 兼容
PolarDB PG 阿里云开源
OrioleDB OLTP 优化

Grafana 的可扩展性

Grafana 是非常流行的开源监控和可视化工具，拥有许多扩展插件：各类数据可视化面板与数据源。但这些扩展插件的安装和管理一直是个问题 —— Grafana 自己的 CLI 工具确实可以用于安装插件，不过国内用户必须科学上网才能使用，带来了很大的不便。

在 v3.2 中，常用的 Grafana 扩展面板与数据源插件都制作成了 RPM/DEB 包，方便开箱即用：

架构无关扩展 (grafana-plugins)：

类别 插件
面板 volkovlabs-echarts, image, form, table, variable
面板 knightss27-weathermap, marcusolsson-dynamictext
面板 marcusolsson-treemap, calendar, hourly-heatmap
数据源 marcusolsson-static, json, volkovlabs-rss, grapi

架构相关扩展：

此外，针对那些架构相关（包含 x86、ARM 二进制）的数据源扩展制作了独立的 RPM/DEB 包。例如 Grafana 新推出的 Infinity 数据源插件：可以使用任意 REST/GraphQL API，使用 CSV/TSV/XML/HTML 作为数据源，这极大扩展了 Grafana 的数据接入能力。

与此同时，还针对 VictoriaMetrics 和 VictoriaLogs 的 Grafana 数据源插件制作了 RPM/DEB 包，方便用户在 Grafana 中使用这两个开源的时序数据库和日志数据库。

下一步的发展规划

目前 Pigsty 本身已经达到了相当成熟的状态。接下来一段时间的工作重心，将放在 pig 这个工具以及扩展仓库的维护上。

当前是一个难得的机会窗口：用户与开发者开始意识到 PostgreSQL 扩展的重要性，但 PostgreSQL 生态还没有扩展分发的事实标准。Pigsty 致力于让 pig 成为一个有影响力的 PostgreSQL 扩展插件分发标准。

当然，Pigsty 本身一直也缺少一个足够好用的 CLI 工具，接下来将把散落在各个 Ansible 剧本中的功能整合到 pig 中，让用户可以更方便地管理 Pigsty 与 PostgreSQL。

v3.2.0 发行注记

亮点特性

  • Pigsty 命令行工具：pig 0.2.0，可用于管理扩展插件。
  • 提供五大发行版上 340 个扩展 的 ARM64 扩展支持
  • Supabase 发布周最新版本更新，全发行版均可自建。
  • Grafana 更新至 11.4 ，新增 infinity 数据源。

软件包变化

  • 新增扩展

  • 更新扩展

    • pgvectorscale 0.4.0 -> 0.5.1
    • pg_parquet 0.1.0 -> 0.1.1
    • pg_polyline 0.0.1
    • pg_cardano 1.0.2 -> 1.0.3
    • pg_vectorize 0.20.0
    • pg_duckdb 0.1.0 -> 0.2.0
    • pg_search 0.13.0 -> 0.13.1
    • aggs_for_vecs 1.3.1 -> 1.3.2
    • pgoutput 被标记为新的 PostgreSQL Contrib 扩展

  • 基础设施

    • 新增 promscale 0.17.0
    • 新增 grafana-plugins 11.4
    • 新增 grafana-infinity-plugins
    • 新增 grafana-victoriametrics-ds
    • 新增 grafana-victorialogs-ds
    • vip-manager 2.8.0 -> 3.0.0
    • vector 0.42.0 -> 0.43.0
    • grafana 11.3 -> 11.4
    • prometheus 3.0.0 -> 3.0.1 (软件包名从 prometheus2 变更为 prometheus)
    • nginx_exporter 1.3.0 -> 1.4.0
    • mongodb_exporter 0.41.2 -> 0.43.0
    • VictoriaMetrics 1.106.1 -> 1.107.0
    • VictoriaLogs 1.0.0 -> 1.3.2
    • pg_timetable 5.9.0 -> 5.10.0
    • tigerbeetle 0.16.13 -> 0.16.17
    • pg_export 0.7.0 -> 0.7.1

  • 缺陷修复

    • el8.aarch64 添加 python3-cdiff 修复 patroni 依赖错漏问题
    • el9.aarch64 添加 timescaledb-tools ，修复官方仓库缺失问题
    • el9.aarch64 添加 pg_filedump ，修复官方仓库缺失问题

  • 移除扩展

    • pg_mooncake 因为与 pg_duckdb 冲突而被移除。
    • pg_top 因为出现太多版本出现缺失，因质量问题而淘汰。
    • hunspell_pt_pt 因为与 PG 官方字典文件冲突而被淘汰。
    • pg_timeit 因为无法在 AARCH64 架构上使用而被淘汰。
    • pgdd 因为缺乏维护，PG 17 与 pgrx 版本老旧而被标记为弃用。
    • old_snapshot 与 adminpack 被标记为 PG 17 不可用。
    • pgml 被设置为默认不下载不安装。

API变化

  • repo_url_packages 参数现在默认值为空数组，因为所有软件包现在都通过操作系统包管理器进行安装。
  • grafana_plugin_cache 参数弃用，现在 Grafana 插件通过操作系统包管理器进行安装
  • grafana_plugin_list 参数弃用，现在 Grafana 插件通过操作系统包管理器进行安装
  • 原名为 prod 的 36 节点仿真模板现在重命名为 simu。
  • 原本在 node_id/vars 针对每个发行版代码生成的配置，现在同样针对 aarch64 生成。
  • infra_packages 中默认添加命令行管理工具 pig
  • configure 命令同样会修改自动生成配置文件中 pgsql-xxx 别名的版本号。
  • adminpack 在 PG 17 中被移除，因此从 Pigsty 默认扩展中被移除。

问题修复

  • 修复了 pgbouncer 仪表盘选择器问题 #474
  • pg-pitr 新增 --arg value 参数解析支持 by @waitingsong
  • 修复 Redis 日志信息 typo by @waitingsong

软件包校验和 

8fdc6a60820909b0a2464b0e2b90a3a6  pigsty-v3.2.0.tgz
d2b85676235c9b9f2f8a0ad96c5b15fd  pigsty-pkg-v3.2.0.el9.aarch64.tgz
649f79e1d94ec1845931c73f663ae545  pigsty-pkg-v3.2.0.el9.x86_64.tgz
c42da231067f25104b71a065b4a50e68  pigsty-pkg-v3.2.0.d12.aarch64.tgz
ebb818f98f058f932b57d093d310f5c2  pigsty-pkg-v3.2.0.d12.x86_64.tgz
24c0be1d8436f3c64627c12f82665a17  pigsty-pkg-v3.2.0.u22.aarch64.tgz
0b9be0e137661e440cd4f171226d321d  pigsty-pkg-v3.2.0.u22.x86_64.tgz

29 - Pigsty v3.1：Supabase一键自建，PG17上位，ARM与Ubuntu24支持，MinIO改进

原文发布于 VONNG。

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

随着前天 PostgreSQL 17.2 的发布，Pigsty 也立即跟进了 v3.1 版本。 在这个版本中，PostgreSQL 17 被提升成为默认使用的大版本，近 340 个 PG 扩展插件开箱即用。

此外，Pigsty 3.1 还提供了一键 自建 Supabase 的能力，改进了 MinIO 对象存储的使用最佳实践。 与此同时，Pigsty还提供了ARM64 架构的初步支持，并且支持了新发布的 Ubuntu 24.04 大操作系统发行版大版本。 最后，这个版本提供了一系列开箱即用的场景化模板，统一了不同操作系统发行版使用配置文件，极大简化了配置管理工作。

自建Supabase

Supabase 是一个开源的 Firebase 替代，对 PostgreSQL 进行了封装，并提供了认证，开箱即用的 API，边缘函数，实时订阅，对象存储，向量嵌入能力。 Supabase 的口号是：“花个周末写写，随便扩容至百万”。在试用之后，我觉得此言不虚。 这是一个低代码的一站式后端平台，能让你几乎告别大部分后端开发的工作，只需要懂数据库设计与前端即可快速出活了！

supa-price.png

小微规模（4c8g）内的 Supabase 云服务极有性价比，堪称赛博菩萨。那 Supabase 云服务这么香，为什么要自建呢？有几个原因：

最直观的原因是是《云计算泥石流》中说过的：云数据库服务只要稍微上一点儿规模，成本就很容易爆炸。而且考虑到当下本地 NVMe 盘的无敌性价比，自建的成本与性能优势是显而易见的。

另一个重要的原因是 Supabase 云服务的功能受限 —— 与RDS逻辑相同，很多强力扩展出于多租户的安全问题考虑是不太可能在云端提供的 —— supabase 云服务中有64个可用扩展，但使用 Pigsty 自建 supabase 时，你可以拥有全部 340 个。 此外，Supabase 官方使用 PostgreSQL 15 作为底层数据库，而在 Pigsty 中，你可以使用 PG 14 - 17 的任意版本，运行在 EL / Debian / Ubuntu 主流 Linux 操作系统裸机 上而无需虚拟化支持，充分地利用现代硬件的性能与成本优势。

我发现身边很多创业出海公司都在使用 Supabase，而其中一些的规模确实已经达到了需要自建的状态，而且有人愿意付费咨询来做这件事了。 所以 Pigsty 早在去年9月发布的 v2.4 就支持自建 Supabase （所需的 PostgreSQL）了。但那毕竟还涉及到一些手工操作，比如配置 PG 集群，拉起 Docker。 而在这个版本中，我们将体验优化到了这种状态 —— 一台新装操作系统的裸机，执行以下几条命令之后，一套新鲜的 Supabase 就出炉了！

supabase-selfhosting.png

这两天我会准备一些关于 自建 Supabase 最佳实践 的教程，敬请期待。

PostgreSQL 17

在《PG12过保，PG17上位》中，我们已经详细介绍了 PostgreSQL 17 的新特性与改进。

其中最令人欣慰的莫过于白给的性能优化了：PostgreSQL 17 据说在写入性能上有了显著提升。我找了一台物理机测试了一下，确实不错。 相比与三年前针对 PostgreSQL 14 的测试结果《PostgreSQL到底有多强》，写入确实有不小的提升。

例如，以前 PG 14 在标准配置下，PG 的 WAL 写入吞吐量在 110 MB/s 附近，这是软件的瓶颈，不是硬件的。 而在 PG 17 下，这个数字能达到 180 MB/s。当然，把安全开关都关掉后性能还能翻几番，但体面评测就不玩那些作弊手段了

perf.png

Pigsty 3.1 + PostgreSQL 17 的性能回归测试，详细的性能评测报告将会在最近几天发出，敬请期待。

340个扩展插件

Pigsty 3.1 版本的另一个亮点特性是，这个版本中提供了 340 个 PostgreSQL 扩展插件。 这是一个非常恐怖的数字了，而且这是在我进行审慎精选踢出十几个“扩展”后的结果，不然按照本期规划应该能到 360 个了。

为了实现这一目标，我建设了一个 YUM / APT 仓库，针对 EL 8/9, Ubuntu 22.04/24.04, Debian 12 这几个主流操作系统发行版， 以及 PG 12 - 17 这六个大版本提供开箱即用的扩展 RPM/DEB 包。目前提供 x86_64 的包，ARM64 和其他架构还在路上，目前仅对专业用户按需提供。 当然除了仓库之外，更重要的是我还维护了一个 扩展目录，详细记录了每个扩展的元数据， OS/DB 版本可用性，以及一些使用说明，方便用户找到自己需要的扩展。

ext-repo.png

Pigsty 的扩展仓库基于原生的操作系统包管理器，公开共享，你不一定非要使用 Pigsty 才能按照这些扩展。 你完全可以在现有系统，Dockerfile中添加此仓库并通过 yum/apt install 的方式安装这些扩展。 目前我很欣慰的是有一个比较流行的开源集群部署项目 postgresql-cluster 已经默认用起了这个仓库，作为安装流程的一部分，向用户提供并分发扩展插件。

postgresql-cluster.png

当然，更多细节，在《PostgreSQL神功大成，最全扩展仓库》中对此已经有过介绍。 目前使用 Rust + pgrx 开发扩展的新项目不少，Pigsty 收录了 23 个 Rust 扩展。 如果你有好的扩展推荐，欢迎告诉我，我会考察测试后，尽快将其加入到仓库中。 如果你是 PostgreSQL 扩展作者，我们也欢迎将你的扩展提交到 Pigsty 仓库中，我们可以帮助您打包分发，解决最后一公里的交付问题。

Ubuntu 24.04 支持

Ubuntu 24.04 noble 已经发布半年了，已经开始有一些用户在生产环境中真实使用它了。 因此，Pigsty v3.1 版本也提供了对 Ubuntu 24.04 的正式支持。

尽管如此，作为一个比较新的系统，Ubuntu 24.04 相比 22.04 还有一些缺陷，例如 citus 和 topn 扩展在整个系统上是缺位的，而 timescaledb_toolkit 目前还没有提供 u24 x86_64 的支持。 但总体来说，除了这些个例外，绝大部分扩展都已经支持 Ubuntu 24.04 了。因此将其纳入 Pigsty 的主要支持范围是没有问题的。

相应地，我们将 Ubuntu 20.04 focal 从 Pigsty 主力支持的操作系统中逐出，虽然 Ubuntu 20.04 在明年五月份才正式 EOL。 但是因为它的一些软件缺漏与依赖版本问题比较严重（PostGIS），我非常乐意能将其提早淘汰，踢出开源版本的支持范畴。 当然，理论上您还是可以继续在 Ubuntu 20.04 上安装并使用，而且在我们的订阅服务中也继续提供对 Ubuntu 20.04 的支持。

因此，目前 Pigsty 支持的主流操作系统发行版为：EL 8/9, Ubuntu 22.04 / Ubuntu 24.04, 以及 Debian 12 这五个。 我们会针对这五个操作系统发行版提供最新的软件包，完整的扩展插件。

Code OS Distro x86_64 PG17 PG16 PG15 PG14 PG13 PG12 Arm64 PG17 PG16 PG15 PG14 PG13 PG12
EL9 RHEL 9 / Rocky9 / Alma9 el9.x86_64 el9.arm64
EL8 RHEL 8 / Rocky8 / Alma8 / Anolis8 el8.x86_64 el8.arm64
U24 Ubuntu 24.04 (noble) u24.x86_64 u24.arm64
U22 Ubuntu 22.04 (jammy) u22.x86_64 u22.arm64
D12 Debian 12 (bookworm) d12.x86_64 d12.arm64
D11 Debian 11 (bullseye) d12.x86_64 d11.arm64
U20 Ubuntu 20.04 (focal) d12.x86_64 u20.arm64
EL7 RHEL7 / CentOS7 / UOS … d12.x86_64 el7.arm64

= 首要版本支持； = 配置可选支持； = 过期版本商业支持

ARM 支持

ARM 架构最近不断攻城略地，尤其是在云计算领域，ARM 服务器的市场份额正在逐渐增加。早在俩年前，就有用户提出对 ARM 架构支持的需求。 其实 Pigsty 在早先做 “国产化系统” 适配的时候，就已经有一个 ARM 支持了。但是在开源版本中提供 ARM64 架构支持，v3.1 版本是第一次。

当然，目前的版本，ARM 还处在一个 Beta 状态：功能是有了，也能跑通，但是到底效果怎么样还是要跑一段时间，有了反馈才知道。

目前 Pigsty 的主体功能已经都完成适配了，比如 Grafana / Prometheus 全家桶这些我也都打好了 ARM 的软件包， 尚未支持的部分主要是 PG 扩展 —— 特指由 Pigsty 维护的 140 个扩展 —— 目前还没有提供 ARM 支持，已经在做了。 不过，如果你用到的扩展都是 PGDG 中已经提供的（比如 postgis, pgvector 这种），那么没有问题。

目前，ARM 版本在 EL9，Debian 12，Ubuntu 22.04 上运行状态良好。 EL8 有一些PGDG官方包缺失，Ubuntu24有个别扩展缺失，所以目前还不建议在这两个系统上使用 ARM 版本。

我准备将 ARM 试点运行一两个小版本，当扩展齐全之后，我会将其标记为 GA。欢迎各位朋友试用 ARM 版本并向我提出反馈意见。

配置简化

另一个在 Pigsty v3.1 中进行的显著改进是配置简化，如何管理不同操作系统发行版，大小版本的软件包差异一直是一个比较让人头疼的问题。

比如，因为很多操作系统发行版上的包名，可用软件集合其实是有一些区别的，所以在此前的版本里，Pigsty 会根据每个操作系统发行版生成一个独立的配置文件。 但是这样很快就会出现排列组合爆炸，比如，Pigsty 默认提供十几种场景下的配置模板，如果每个模板都要针对 5 - 7 个 操作系统版本生成，那么总数就要爆炸了。

但计算机科学中的任何问题都可以通过增加一个间接层来解决，而这个问题呢也也不例外。在 v3.1 版本中，Pigsty 引入了一个新的配置文件 package_map，用于定义软件包的别名。 然后针对每个操作系统发行版，我们都会生成一个 node_id/vars 配置文件，将固定的包别名翻译为操作系统上具体的软件包列表。

config.png

比如，Supabase 自建模板中启用了几十个扩展，用户只需要提供扩展的名字就可以了，至于芯片架构，操作系统版本，PG版本，包名之类的细节差异全都在内部处理好了。

pg_extensions: # extensions to be installed on this cluster
- supabase   # essential extensions for supabase
- timescaledb postgis pg_graphql pg_jsonschema wrappers pg_search pg_analytics pg_parquet plv8 duckdb_fdw pg_cron pg_timetable pgqr
- supautils pg_plan_filter passwordcheck plpgsql_check pgaudit pgsodium pg_vault pgjwt pg_ecdsa pg_session_jwt index_advisor
- pgvector pgvectorscale pg_summarize pg_tiktoken pg_tle pg_stat_monitor hypopg pg_hint_plan pg_http pg_net pg_smtp_client pg_idkit

举个例子，如果你想下载安装 PG 16 的内核与扩展，以前你需要把下载列表和安装列表里的包全换成16的版本，现在你只需要简单的修改一个 pg_version 参数就行了。 最后的效果非常好，基本实现了所有操作系统发行版都能使用相同的配置文件进行安装，将不同系统的差异与管理复杂度都隐藏在了内部。

基础设施改进

除了功能上的改进之外，我们还在不断改善基础设施。例如在 v3.0 引入的安装 MSSQL 兼容的 Babelfish 内核，Oracle 兼容的 IvorySQL 内核，以及国产 PolarDB 内核，都要求用户使用一个外部仓库在线安装。

现在，Pigsty 官方仓库直接提供了 Babelfish，IvorySQL，PolarDB 等内核的镜像仓库，安装这些“异国风味”PG替换内核变得更加简单了 —— 现在的效果就是，不需要什么额外的配置，使用预置模板一键安装即可。

此外，我们还维护着 Prometheus 与 Grafana 的 YUM/ATP x AMD/ARM 软件仓库，并实时跟进这些可观测性组件的版本。在这次升级中，Prometheus 升级到了 v3 大版本，而 VictoriaLogs 也正式发布了 v1 版本。 总的来说，如果你需要用到这些监控软件，Pigsty 的仓库也能帮到您。

MinIO 改进

最后我们来聊一下开源对象存储自建，MinIO。 Pigsty 将 MinIO 用作 PostgreSQL 的备份存储，与 Supabase 的底层存储服务， 并致力于将 MinIO 的部署门槛压低到有手就行 —— Deploy in minutes, Scale to millions。

在我们最早内部使用 MinIO 的时候，还是 0.x 的版本，而从那时到现在 MinIO 也有了很大的进步。 当年我们用 MinIO 存 25 PB 数据，因为 MinIO 不支持在线扩容，所以只能拆出了七八个独立集群依次使用。 而现在 MinIO 虽然仍然不能在线修改磁盘/节点数量，但可以通过添加存储池 - 迁移 - 淘汰旧存储池的方式实现平滑扩容了。

minio.png

在 Pigsty v3.1 中，我重新通读了 MinIO 的文档，并根据新版本的特性调整了 MinIO 的最佳实践配置模板与SOP。 除了之前的 MinIO 单机单盘，单机多盘，多机多盘模式，我们还支持了多存储池部署模式，并提供了 Pigsty 中 MinIO 的管理预案 —— 包括磁盘故障，节点故障的处理，集群上下线，存储扩缩容，使用 VIP 与 HAProxy 对外提供高可用接入的方案，全都有据可查，几行命令就能轻松解决。

对象存储是云上的基石性服务，MinIO 作为开源对象存储的代表，其性能与功能都非常优秀，更重要的是，它是一个云中立的开源软件。

您也可以使用 MinIO 来替代云上的对象存储服务，正如《DHH：下云超预期，能省一个亿》所述， 他们云上有 10PB 的对象存储（列表价每年300万），SavingPlan打折后每年130万美元，合 93万人民币 / PB·年。 而 1.2 PB的专用存储服务器一台十几万人民币上下，三副本冗余， 整几台套上MinIO就是对象存储了。 再加上网电运维，整个五年TCO 也超不过云上一年的折后消费，所以这里蕴含着惊人的降本增效潜力。 如果你的的业务在大量使用对象存储，那么本地 MinIO 自建 + Cloudflare 可能是非常值得考虑的一个更优解。

服务体系

Pigsty v3.1 达到了一个我比较满意的状态，接下来我的工作重心会放在服务体系的构建上。

Pigsty 是个开源免费的软件，它已经解决了 PG 运维中会遇到的绝大多数问题。如果你自己是开源老司机，真遇上疑难杂症自己也可以解决。 但是对于一些大型企业用户，特别是那些没有专职 DBA 的企业来说，还是需要有人来“兜底”的，毕竟，开源软件的核心就是 NO WARRANTY。

正如《PolarDB20块好兄弟：数据库到底应该卖什么价》中所述，体面数据库服务其实是有市场公允价的，一般在 1~2万人民币 / vCPU·年。 不论你是去买 Oracle 的服务支持，还是 EDB，Fujitsu 的开源PG服务，或者是 AWS 的 RDS / Aurora ，其实都是这个价位。

之前我定的服务价格太低，已经引起海内外同行微词 —— 乃这不是破坏市场，低价倾销吗？你作为国内顶级PG专家定这个价还公开，让我们怎么办。

price.png

所以这次我也重新调整了一下定价体系，基本锚定业界平均定价水平。反正这也是你情我愿的双向选择，欢迎有兴趣的朋友们选购专业服务，打钱支持！新人新办法，老客老价格。

v3.1.0

亮点特性

  • PostgreSQL 17 现已成为默认使用的主要版本 (17.2)
  • Ubuntu 24.04 系统支持
  • arm 架构支持：EL9, Debian12, Ubuntu 22.04
  • Supabase 一键自建，新的剧本 supabase.yml
  • MinIO 最佳实践改进，配置模板与 Vagrant 模板
  • 提供了一系列开箱即用的配置模板与文档说明。
  • 允许在 configure 过程中使用 -v|--version 指定使用的 PG 大版本。
  • 调整 PG 默认插件策略：默认安装 pg_repack, wal2json 以及 pgvector 三个关键扩展。
  • 大幅简化 repo_packages 本地软件源构建逻辑，允许在 repo_packages 中使用软件包组别名
  • 提供了 WiltonDB，IvorySQL，PolarDB 的软件源镜像，简化三者的安装。
  • 默认启用数据库校验和。
  • 修复 ETCD 与 MINIO 日志面板

软件升级

  • PostgreSQL 17.2, 16.6, 15.10, 14.15, 13.18, 12.22
  • PostgreSQL 扩展版本变动请参考：https://pgext.cloud/zh
  • Patroni 4.0.4
  • MinIO 20241107 / MCLI 20241117
  • Rclone 1.68.2
  • Prometheus: 2.54.0 -> 3.0.0
  • VictoriaMetrics 1.102.1 -> 1.106.1
  • VictoriaLogs v0.28.0 -> 1.0.0
  • vslogcli 1.0.0
  • MySQL Exporter 0.15.1 -> 0.16.0
  • Redis Exporter 1.62.0 -> 1.66.0
  • MongoDB Exporter 0.41.2 -> 0.42.0
  • Keepalived Exporter 1.3.3 -> 1.4.0
  • DuckDB 1.1.2 -> 1.1.3
  • etcd 3.5.16 -> 3.5.17
  • tigerbeetle 16.8 -> 0.16.13

API变更

  • repo_upstream: 针对每个具体的操作系统发行版生成默认值：roles/node_id/vars
  • repo_packages: 允许使用 package_map 中定义的别名。
  • repo_extra_packages: 新增未指定时的默认值，允许使用 package_map 中定义的别名。
  • pg_checksum: 默认值修改为 true，默认打开。
  • pg_packages: 默认值修改为：postgresql, wal2json pg_repack pgvector, patroni pgbouncer pgbackrest pg_exporter pgbadger vip-manager
  • pg_extensions: 默认值修改为空数组 []。
  • infra_portal: 允许为 home 服务器指定 path，替代默认的本地仓库路径 nginx_home (/www)

30 - Pigsty v3.0：海量扩展，插拔内核，RDS服务

原文发布于 VONNG。

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

亮点特性

扩展大爆炸：

Pigsty v3 提供了史无前例的 340 个可用扩展插件。 包括 121 个扩展 RPM包 与 133 个 DEB包，数量已经超过了 PGDG 官方仓库提供的扩展数量总和（135 RPM/ 109 DEB）。 而且，Pigsty 还将EL系统与Debian生态的独有PG扩展插件相互移植，实现了两大发行版的插件生态大对齐。

- timescaledb periods temporal_tables emaj table_version pg_cron pg_later pg_background pg_timetable
- postgis pgrouting pointcloud pg_h3 q3c ogr_fdw geoip #pg_geohash #mobilitydb
- pgvector pgvectorscale pg_vectorize pg_similarity pg_tiktoken pgml #smlar
- pg_search pg_bigm zhparser hunspell
- hydra pg_lakehouse pg_duckdb duckdb_fdw pg_fkpart pg_partman plproxy #pg_strom citus
- pg_hint_plan age hll rum pg_graphql pg_jsonschema jsquery index_advisor hypopg imgsmlr pg_ivm pgmq pgq #rdkit
- pg_tle plv8 pllua plprql pldebugger plpgsql_check plprofiler plsh #pljava plr pgtap faker dbt2
- prefix semver pgunit md5hash asn1oid roaringbitmap pgfaceting pgsphere pg_country pg_currency pgmp numeral pg_rational pguint ip4r timestamp9 chkpass #pg_uri #pgemailaddr #acl #debversion #pg_rrule
- topn pg_gzip pg_http pg_net pg_html5_email_address pgsql_tweaks pg_extra_time pg_timeit count_distinct extra_window_functions first_last_agg tdigest aggs_for_arrays pg_arraymath pg_idkit pg_uuidv7 permuteseq pg_hashids
- sequential_uuids pg_math pg_random pg_base36 pg_base62 floatvec pg_financial pgjwt pg_hashlib shacrypt cryptint pg_ecdsa pgpcre icu_ext envvar url_encode #pg_zstd #aggs_for_vecs #quantile #lower_quantile #pgqr #pg_protobuf
- pg_repack pg_squeeze pg_dirtyread pgfincore pgdd ddlx pg_prioritize pg_checksums pg_readonly safeupdate pg_permissions pgautofailover pg_catcheck preprepare pgcozy pg_orphaned pg_crash pg_cheat_funcs pg_savior table_log pg_fio #pgpool pgagent
- pg_profile pg_show_plans pg_stat_kcache pg_stat_monitor pg_qualstats pg_store_plans pg_track_settings pg_wait_sampling system_stats pg_meta pgnodemx pg_sqlog bgw_replstatus pgmeminfo toastinfo pagevis powa pg_top #pg_statviz #pgexporter_ext #pg_mon
- passwordcheck supautils pgsodium pg_vault anonymizer pg_tde pgsmcrypto pgaudit pgauditlogtofile pg_auth_mon credcheck pgcryptokey pg_jobmon logerrors login_hook set_user pg_snakeoil pgextwlist pg_auditor noset #sslutils
- wrappers multicorn mysql_fdw tds_fdw sqlite_fdw pgbouncer_fdw mongo_fdw redis_fdw pg_redis_pubsub kafka_fdw hdfs_fdw firebird_fdw aws_s3 log_fdw #oracle_fdw #db2_fdw
- orafce pgtt session_variable pg_statement_rollback pg_dbms_metadata pg_dbms_lock pgmemcache #pg_dbms_job #wiltondb
- pglogical pgl_ddl_deploy pg_failover_slots wal2json wal2mongo decoderbufs decoder_raw mimeo pgcopydb pgloader pg_fact_loader pg_bulkload pg_comparator pgimportdoc pgexportdoc #repmgr #slony
- gis-stack rag-stack fdw-stack fts-stack etl-stack feat-stack olap-stack supa-stack stat-stack json-stack

换内核：

Pigsty v3 允许您更换 PostgreSQL 内核，目前支持了 SQL Server 兼容的 Babelfish （线缆协议级仿真），Oracle 兼容的 IvorySQL，以及 PG 版的 RAC PolarDB；此外，现在自托管 Supabase 也在 Debian 系统中可用。 您可以让 Pigsty 中带有 HA，IaC，PITR，监控的生产级 PostgreSQL 集群仿真 MSSQL (via WiltonDB)，Oracle via (IvorySQL)，Oracle RAC (via PolarDB), MongoDB（via FerretDB），以及 Firebase （via Supabase）。

企业版：

我们现在提供 Pigsty Pro 专业版，在开源版的功能基础上提供增值服务。专业版提供额外的功能模块：MSSQL，Oracle，Mongo，K8S，Victoria，Kafka，TigerBeetle 等……，并提供更广泛的 PG 大版本、操作系统、芯片架构的支持。 提供针对全系操作系统精准小版本定制的离线安装包，以及 EL7，Debian 11，Ubuntu 20.04 等过保老系统的支持；此外，专业版还提供内核可插拔定制服务，并对PolarDB PG/Oracle 的原生部署、监控管控支持以满足“国产化”需要。

使用以下命令快速安装：

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

重大变更

本次 Pigsty 发布调整大版本号，从 2.x 升级到 3.0，带有一些重大变更：

  • 首要支持操作系统调整为：EL 8 / EL 9 / Debian 12 / Ubuntu 22.04

    • EL7 / Debian 11 / Ubuntu 20.04 等系统进入弃用阶段，不再提供支持
    • 有在这些系统上运行需求的用户请考虑我们的 订阅服务

  • 默认使用在线安装，不再提供离线软件包，从而解决操作系统小版本兼容性问题。

    • bootstrap 过程现在不再询问是否下载离线安装包，但如果 /tmp/pkg.tgz 存在，仍然会自动使用离线安装包。
    • 有离线安装需求请自行制作离线软件包或考虑我们的 订阅服务

  • Pigsty 使用的上游软件仓库进行统一调整，地址变更，并对所有软件包进行 GPG 签名与校验

    • 标准仓库： https://repo.pigsty.io/{apt/yum}
    • 国内镜像： https://repo.pigsty.cc/{apt/yum}

  • API 参数变更与配置模板变更

    • EL 系与 Debian 系配置模板现在收拢统一，有差异的参数统一放置于 roles/node_id/vars/ 目录进行管理。
    • 配置目录变更，所有配置文件模板统一放置在 conf 目录下，并分为 default, dbms, demo, build 四大类。

其他新特性

  • PG OLAP 分析能力史诗级加强：DuckDB 1.0.0，DuckDB FDW，以及 PG Lakehouse，Hydra 移植至 Deb 系统中。
  • PG 向量检索与全文检索能力加强：Vectorscale 提供 DiskANN 向量索引，Hunspell 分词字典支持，pg_search 0.9.1。
  • 帮助 ParadeDB 解决了软件包构建问题，现在我们在 Debian/Ubuntu 上也能提供这一扩展。
  • Supabase 所需的扩展在 Debian/Ubuntu 上全部可用，Supabase 现在可在全OS上自托管。
  • 提供了场景化预置扩展堆栈的能力，如果您不知道安装哪些扩展，我们准备了针对特定应用场景的扩展推荐包（Stack）。
  • 针对所有 PostgreSQL 生态的扩展，制作了元数据表格、文档、索引、名称映射，针对 EL与Deb 进行对齐，确保扩展可用性。
  • 为了解决 DockerHub 被 Ban 的问题，我们加强了 proxy_env 参数的功能并简化其配置方式。
  • 建设了一个专用的新软件仓库，提供了 12-17 版本的全部扩展插件，其中，PG16的扩展仓库会在 Pigsty 默认的版本中实装。
  • 现有软件仓库升级改造，使用标准的签名与校验机制，确保软件包的完整性与安全性。APT 仓库采用新的标准布局通过 reprepro 构建。
  • 提供了 1,2,3,4,43 节点的沙箱环境：meta, dual, trio, full, prod，以及针对 7 大 OS Distro 的快捷配置模板。
  • PG Exporter 新增了 PostgreSQL 17 与 pgBouncer 1.23 新监控指标收集器的定义，与使用这些指标的 Grafana Panel
  • 监控面板修缮，修复了各种问题，为 PGSQL Pgbouncer 与 PGSQL Patroni 监控面板添加了日志仪表盘。
  • 使用全新的 cache.yml Ansible 剧本，替换了原有制作离线软件包的 bin/cache 与 bin/release-pkg 脚本。

API变更

  • 新参数选项： pg_mode 现在支持的模式有 pgsql, citus, gpsql, mssql, ivory, polar，用于指定 PostgreSQL 集群的模式
    • pgsql： 标准 PostgreSQL 高可用集群
    • citus： Citus 水平分布式 PostgreSQL 原生高可用集群
    • gpsql： 用于 Greenplum 与 GP 兼容数据库的监控（专业版）
    • mssql： 安装 WiltonDB / Babelfish，提供 Microsoft SQL Server 兼容性模式的标准 PostgreSQL 高可用集群，线缆协议级支持，扩展不可用
    • ivory： 安装 IvorySQL 提供的 Oracle 兼容性 PostgreSQL 高可用集群，Oracle语法/数据类型/函数/存储过程兼容，扩展不可用 （专业版）
    • polar： 安装 PolarDB for PostgreSQL （PG RAC）开源版本，提供国产化数据库能力支持，扩展不可用。（专业版）
  • 新参数： pg_parameters，用于在实例级别指定 postgresql.auto.conf 中的参数，覆盖集群配置，实现不同实例成员的个性化配置。
  • 新参数： pg_files，用于将额外的文件拷贝到PGDATA数据目录，针对需要License文件的商业版PostgreSQL分叉内核设计。
  • 新参数： repo_extra_packages，用于额外指定需要下载的软件包，与 repo_packages 共同使用，便于指定OS版本独有的扩展列表。
  • 参数重命名： patroni_citus_db 重命名为 pg_primary_db，用于指定集群中的主要数据库（在 Citus 模式中使用）
  • 参数强化：proxy_env 中的代理服务器配置会写入 Docker Daemon，解决科学上网问题，configure -x 选项会自动在配置中写入当前环境中的代理服务器配置。
  • 参数强化：repo_url_packages 中的 repo.pigsty.io 会在区域为中国时自动替换为 repo.pigsty.cc，解决科学上网问题，此外，现在可以指定下载后的文件名称。
  • 参数强化：pg_databases.extensions 中的 extension 字段现在可以支持字典与扩展名字符串两种模式，字典模式提供 version 支持，允许安装特定版本的扩展。
  • 参数强化：repo_upstream 参数如果没有显式覆盖定义，将从 rpm.yml 或 deb.yml 中定义的 repo_upstream_default 提取对应系统的默认值。
  • 参数强化：repo_packages 参数如果没有显式覆盖定义，将从 rpm.yml 或 deb.yml 中定义的 repo_packages_default 提取对应系统的默认值。
  • 参数强化：infra_packages 参数如果没有显式覆盖定义，将从 rpm.yml 或 deb.yml 中定义的 infra_packages_default 提取对应系统的默认值。
  • 参数强化：node_default_packages 参数如果没有显式覆盖定义，将从 rpm.yml 或 deb.yml 中定义的 node_packages_default 提取对应系统的默认值。
  • 参数强化：pg_packages 与 pg_extensions 中的扩展现在都会从 rpm.yml 或 deb.yml 中定义的 pg_package_map 执行一次查找与翻译。
  • 参数强化：node_packages 与 pg_extensions 参数中指定的软件包在安装时会升级至最新版本， node_packages 中现在默认值变为 [openssh-server]，帮助修复 OpenSSH CVE
  • 参数强化：pg_dbsu_uid 会自动根据操作系统类型调整为 26 （EL）或 543 （Debian），避免了手工调整。
  • Boostrap 逻辑变化，不再下载离线软件包，添加 -k|--keep 参数，用于指定在本地安装 ansible 时是否保留现有的软件源。
  • Configure 移除了 -m|--mode 参数，使用 -m|--conf 参数指定配置文件，使用 -x|--proxy 参数指定代理服务器配置，不再尝试修复 ssh 本机问题。
  • 设置了 pgbouncer 默认参数，max_prepared_statements = 128 启用了事物池化模式下的准备语句支持，并设置 server_lifetime 为 600，
  • 修改了 patroni 模板默认参数，统一增大 max_worker_processes +8 可用后端进程，提高 max_wal_senders 与 max_replication_slots 至 50，并增大 OLAP 模板临时文件的大小限制为主磁盘的 1/5

版本升级

截止至发布时刻，Pigsty 主要组件的版本升级如下：

Pigsty 重新编译了所有 PostgreSQL 扩展插件，PostgreSQL 扩展插件的最新版本，请参考 扩展列表

新应用

Pigsty 现在提供开箱即用的 Dify 与 Odoo Docker Compose 模板：

  • Dify： AI智能体工作流编排与 LLMOps
  • Odoo： 企业级开源 ERP 系统

Pigsty 专业版现在提供试点的 Kubernetes 部署支持与 Kafka KRaft 集群部署与监控支持

  • KUBE： 使用 cri-dockerd 或 containerd 部署由 Pigsty 托管的 Kubernetes 集群
  • KAFKA：部署由 Kraft 协议支持的高可用 Kafka 集群

问题修复

  • 通过 node_packages 中的默认值 [openssh-server]，CVE-2024-6387 可以在 Pigsty 安装过程中被自动修复。
  • 修复了 Loki 解析 Nginx 日志标签基数过大导致的内存消耗问题。
  • 修复了 EL8 系统中上游 Ansible 依赖变化导致的 bootstrap 失效问题（python3.11-jmespath 升级至 python3.12-jmespath）

31 - 使用Pigsty自建Dify：AI工作流平台

原文发布于 VONNG。

Dify 是一个生成式 AI 应用创新引擎，开源的 LLM 应用开发平台。提供从 Agent 构建到 AI workflow 编排、RAG 检索、模型管理等能力，帮助用户轻松构建和运营生成式 AI 原生应用。

当然，像这样的一个 AI 工作流编排软件，在底下也少不得用到数据库 —— Dify 便是用 PostgreSQL 存储数据的，当然还有 Redis 缓存，与一个专用的向量数据库。Docker 镜像拉起来本地玩玩可以，生产环境部署的话，数据库肯定不能这么搞，高可用，备份，监控啥都没有。 好在 Pigsty 就提供了开箱即用的生产级高可用 PostgreSQL 集群，也正好提供了 Dify 需要用到的 Redis 与 S3 （MinIO） 服务，也提供了 Nginx 可以对外暴露 Web 服务，堪称 Dify 最佳拍档。

docker-compose.png

有了 Pigsty，你只需要用 docker compose 拉起无状态的蓝圈部分就好了，状态放在由外部服务由 Pigsty 管理。

这里我不得不吐槽一下 Dify 模板的设计，元数据都已经用 PostgreSQL 存储了，你直接加个 pgvector 不就能拿来当向量数据库了？更让人想吐槽的是 pgvector 竟然还是一个单独的镜像与容器，你直接用一个带 pgvector 的 PG 镜像不就行了？ Dify “支持” 了一堆花里胡哨的向量数据库，但你既然已经选定了 PostgreSQL 了，向量数据库默认也用 pgvector 就是自然而然地选择了。同理，我觉得 Dify 官方应该考虑一下把 Redis 去掉，Celery 任务队列又不是不能用 PostgreSQL 作为后端存储，弄那么多数据库纯属吃饱了撑着。如无必要，勿增实体。

所以 Pigsty 提供的 Dify Docker Compose 模板 也对官方的样例做了一些修改，把 db 和 redis 两个数据库镜像给去掉了，使用由 Pigsty 管理的实例，向量数据库固定使用 pgvector，复用同一个 PostgreSQL 实例。

最后上面那个架构就被简化为无状态的：dify-api，dify-web，dify-worker 三个无状态容器，可以随意创建销毁。当然还有两个可选的 ssrf_proxy 与 nginx，用于提供代理与些许安全特性。 还有一点状态尾巴是 文件系统卷，存放私钥之类的东西，定期备份一下就好了，也可以使用 MinIO 替代。

参考资料：

Pigsty的准备工作

我们用 单机安装 的 Pigsty 为例，假设你有一台 IP 地址为 10.10.10.10 的机器，已经 安装好了单机 Pigsty。

当然，我们需要在 Pigsty 配置文件 pigsty.yml 中定义一下我们所需的数据库集群。 这里定义了一个名为 pg-meta 的集群，其中有一个名为 dbuser_dify 的超级业务用户（它这个实现的有点挫，在 Migration 脚本里面执行了 CREATE EXTENSION ），一个安装了 pgvector 扩展插件的数据库 dify，以及一条特定的防火墙规则，允许用户通过密码从任何地方访问数据库（你也可以将其限制为docker的网段 172.0.0.0/8 之类更精确的范围）。

同时，上面还定义了一个单实例的标准 Redis 集群 redis-dify，设置了密码 redis.dify。

pg-meta:
  hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } }
  vars:
    pg_cluster: pg-meta
    pg_users: [ { name: dbuser_dify ,password: DBUser.Dify  ,superuser: true ,pgbouncer: true ,roles: [ dbrole_admin ] } ]
    pg_databases: [ { name: dify, owner: dbuser_dify, extensions: [ { name: pgvector } ] } ]
    pg_hba_rules: [ { user: dbuser_dify , db: all ,addr: world ,auth: pwd ,title: 'allow dify user world pwd access' } ]

redis-dify:
  hosts: { 10.10.10.10: { redis_node: 1 , redis_instances: { 6379: { } } } }
  vars: { redis_cluster: redis-dify ,redis_password: 'redis.dify' ,redis_max_memory: 64MB }

这里出于演示目的，我们全部使用单实例配置，你可以参考 Pigsty 文档部署 高可用 的 PG 集群与 Redis 集群。总之，在定义完成后，使用以下命令创建 PG 和 Redis 。

bin/pgsql-add  pg-meta                # create the dify database cluster
bin/redis-add  redis-dify             # create redis cluster

当然，您也可以在现有的 PostgreSQL 集群，例如 pg-meta 上新定义业务用户与业务数据库，并通过以下命令创建：

bin/pgsql-user pg-meta dbuser_dify    # create dify biz user
bin/pgsql-db   pg-meta dify           # create dify biz database

您应该可以通过以下的连接串，访问到 PostgreSQL 与 Redis，当然连接信息请根据实际情况进行修改。

psql postgres://dbuser_dify:[email protected]:5432/dify -c 'SELECT 1'
redis-cli -u redis://[email protected]:6379/0 ping

当你确认这两个连接串可用后，大功告成，你可以开始部署 Dify 了。

这里出于演示方便的原因，使用IP直连的土办法，如果是多节点的高可用 PG 集群，请参考 接入 一节。

当然，上面的部分是假设你已经是 Pigsty 用户，了解如何部署 PostgreSQL 与 Redis 集群。你可以直接跳过下一节，查看 Dify 如何配置。

从零开始的一些说明

如果您已经了解如何配置使用 Pigsty，可以略过本节。

从零安装 Pigsty 需要 准备 一台符合要求的机器节点： Linux / x86_64，静态 IP，使用带有免密 sudo 权限的用户，执行以下命令：

curl -fsSL https://repo.pigsty.cc/get | bash

然后依次完成以下步骤：

cd ~/pigsty      # 下载源码包解压后进入 Pigsty 源码目录，完成后续 准备、配置、安装 三个步骤
./bootstrap      # 【可选项】用于确保 Ansible 正常安装，如果 /tmp/pkg.tgz 离线包则使用它
./configure      # 【可选项】执行环境检测，并生成相应的推荐配置文件，如果知道如何配置可以跳过

# …… 这里请修改自动生成的配置 pigsty.yml ，将上面的集群定义填入 all.children 部分内

./install.yml    # 根据生成的配置文件开始在当前节点上执行安装，使用离线安装包大概需要10分钟完成

您应当将上面的 PostgreSQL 集群与 Redis 集群定义填入 pigsty.yml 文件中，然后执行 install.yml 完成安装。

Redis安装问题

Pigsty 默认不会安装 Redis，所以您需要使用 redis.yml 剧本显式完成 Redis 安装：

./redis.yml

Docker安装问题

Pigsty 默认不会在当前节点安装 Docker，所以您需要使用 docker.yml 剧本安装 Docker。

./docker.yml

Docker Hub 被墙问题

请注意，对于中国大陆用户来说，Docker Hub 与各镜像站点目前出于封锁状态，需要 “科学上网” 才能拉取 Dify 所需的镜像，您可以考虑 docker save|load，或者为 Docker Daemon 配置代理。

要为 Docker Daemon 配置代理，您需要在 proxy_env 中指定 http_proxy 与 https_proxy 环境变量，该参数会在 docker_config 任务中被写入 /etc/docker/daemon.json 中：

{
  "proxies": {
    "http-proxy": "http://192.168.x.x:8118",
    "https-proxy": "http://192.168.x.x:8118",
    "no-proxy": "localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,*.pigsty,*.aliyun.com,mirrors.*,*.myqcloud.com,*.tsinghua.edu.cn"
  }
}

当然您也可以直接在配置文件中填入您的 HTTP/HTTPS 代理地址，并使用 systemctl restart docker 重启生效。

$ docker compose pull
[+] Pulling 5/5
✔ worker Skipped - Image is already being pulled by api
✔ web Pulled
✔ api Pulled
✔ ssrf_proxy Pulled
✔ nginx Pulled

配置代理后，镜像都可以成功拉取了。当然您也可以使用其他可用的镜像站点，例如 quay.io 等。

Dify的配置工作

Dify 的配置参数一如往常地放在 .env 文件中，内容如下所示：

所有参数都顾名思义，已经填入了在 Pigsty默认沙箱环境 中可以直接工作的默认值，数据库连接信息请根据您的真实配置，与上面 PG / Redis 集群配置保持一致即可。 我们建议你随便改一下这个 SECRET_KEY 字段，可以使用 openssl rand -base64 42 生成一个强密钥。

# meta parameter
DIFY_PORT=8001 # expose dify nginx service with port 8001 by default
LOG_LEVEL=INFO # The log level for the application. Supported values are `DEBUG`, `INFO`, `WARNING`, `ERROR`, `CRITICAL`
SECRET_KEY=sk-9f73s3ljTXVcMT3Blb3ljTqtsKiGHXVcMT3BlbkFJLK7U # A secret key for signing and encryption, gen with `openssl rand -base64 42`

# postgres credential
PG_USERNAME=dbuser_dify
PG_PASSWORD=DBUser.Dify
PG_HOST=10.10.10.10
PG_PORT=5432
PG_DATABASE=dify

# redis credential
REDIS_HOST=10.10.10.10
REDIS_PORT=6379
REDIS_USERNAME=''
REDIS_PASSWORD=redis.dify

# minio/s3 [OPTIONAL] when STORAGE_TYPE=s3
STORAGE_TYPE=local
S3_ENDPOINT='https://sss.pigsty'
S3_BUCKET_NAME='infra'
S3_ACCESS_KEY='dba'
S3_SECRET_KEY='S3User.DBA'
S3_REGION='us-east-1'

填好连接信息后，我们就可以使用 Docker Compose 拉起 Dify 服务了：

cd pigsty/app/dify && make up

使用Nginx暴露Web服务

Dify 的 Docker Compose 模板里面已经包含了一个 Nginx Server，占据了宿主机的 80 端口。如果你的这台机器就是拿来专门跑 Dify 的那没问题。如果你用的是 Pigsty 单机安装，那么这台宿主机上的 80 端口已经被 Pigsty 部署的 Nginx Web Portal 占据了。

所以，Pigsty 提供的模板中，DIFY_PORT 默认使用了 8001，并通过宿主机上 Pigsty 部署的 Nginx 转发至此端口。当然我们也提供选项B，你也可以直接在 /etc/nginx/conf.d/dify.conf 里使用样例配置，直接指向 Dify 的 web 与 api 端口。

在 pigsty.yml 配置文件中的 infra_portal 参数中新增一行 Dify 的配置

infra_portal:                     # domain names and upstream servers
  home         : { domain: h.pigsty }
  grafana      : { domain: g.pigsty ,endpoint: "${admin_ip}:3000" , websocket: true }
  prometheus   : { domain: p.pigsty ,endpoint: "${admin_ip}:9090" }
  alertmanager : { domain: a.pigsty ,endpoint: "${admin_ip}:9093" }
  blackbox     : { endpoint: "${admin_ip}:9115" }
  loki         : { endpoint: "${admin_ip}:3100" }
  
  dify         : { domain: dify.pigsty ,endpoint: "10.10.10.10:8001", websocket: true }

执行以下剧本，重新生成 Nginx 配置、证书并应用：

./infra.yml -t nginx

当然如果要通过域名访问，你要把自己的域名 dify.pigsty 添加到域名服务器，或者简单地写入：/etc/hosts 或 C:\Windows\System32\drivers\etc\hosts 之类的静态域名解析文件。

然后，你就可以从浏览器中，通过 http://dify.pigsty 访问 Dify IDE 了。

32 - Pigsty v2.7：集异璧之大成

原文发布于 VONNG。

GitHub Release | 发布注记

Pigsty v2.7：集异璧之大成

2024-05-20，Pigsty v2.7 发布了。在这个版本中收录的可用扩展插件数量，达到了惊人的 255 个，成功让 PostgreSQL 的 全能性 又达到了一个全新高度！

同时，我们提供了一些新的 Docker 应用模板，例如开源的企业 ERP 软件全家桶 —— Odoo，Jupyter Notebook，并率先提供了 Supabase GA 版本的支持。 同时，我们还为后续容器版本的推出扫清了障碍；提供了帮助用户应付国产信创检查的方案 —— PolarDB 支持；并正式进行了专业版与开源版的产品功能区分。

扩展尽入吾彀中

在《PostgreSQL 正在吞噬数据库世界》一文中，我抛出了一个观点：PostgreSQL 并不是一个简单的关系型数据库，而是一个数据管理的抽象框架，具有囊括一切，吞噬整个数据库世界的力量。

而 PG 之所以能做到这一点，除了 开源、先进 这两点外，真正的秘诀在于 扩展 —— 极致可扩展性，与繁荣的扩展生态 是 PostgreSQL 独一无二的特点，也是它从无数数据库中脱颖而出的法宝与秘诀。

因此，在 Pigsty v2.7 版本中，我们重新审视了整个 PostgreSQL 生态的所有扩展插件，将其中一些佼佼者收录其中，我们新收录的扩展如下：

扩展 版本 说明
pg_jsonschema 0.3.1 提供 JSON Schema 校验能力
wrappers 0.3.1 Supabase 提供的外部数据源包装器捆绑包
duckdb_fdw 1.1 DuckDB 外部数据源包装器 (libduck 0.10.2)
pg_search 0.7.0 ParadeDB BM25 算法全文检索插件，ES 全文检索
pg_lakehouse 0.7.0 ParadeDB 湖仓分析引擎
pg_analytics 0.6.1 加速 PostgreSQL 内部的分析查询处理
pgmq 1.5.2 轻量级消息队列，类似于 AWS SQS 和 RSMQ.
pg_tier 0.0.3 支将将冷数据分级存储到 AWS S3
pg_vectorize 0.15.0 在 PG 中实现 RAG 向量检索的封装
pg_later 0.1.0 现在执行 SQL，并在稍后获取结果
pg_idkit 0.2.3 生成各式各样的唯一标识符：UUIDv6，ULID，KSUID
plprql 0.1.0 在 PostgreSQL 使用 PRQL——管线式关系查询语言
pgsmcrypto 0.1.0 为 PostgreSQL 提供商密算法支持：SM2,SM3,SM4
pg_tiktoken 0.0.1 计算 OpenAI 使用的 Token 数量
pgdd 0.5.2 提供通过标准 SQL 查询数据库目录集簇的能力
parquet_s3_fdw 1.1.0 针对 S3/MinIO 上的 Parquet 文件的外部数据源包装器
plv8 3.2.2 PL/JavaScript (v8) 可信过程程序语言
md5hash 1.0.1 提供 128 位 MD5 的原生数据类型
pg_tde 1.0-alpha PostgreSQL 的实验性加密存储引擎。
pg_dirtyread 2.6 从 PostgreSQL 表中读取未清理的死元组，用于脏读

这里面有许多使用 Rust 和 pgrx 开发的扩展插件，许多扩展都提供了非常强大的能力 —— 比如说：

Supabase 出品的 wrappers 看上去是一个扩展，但它其实提供了一个用 Rust 编写 FDW 的插件，提供了对 十种 外部数据源的包装访问！

FDW Description Read Modify
HelloWorld A demo FDW to show how to develop a basic FDW.
BigQuery A FDW for Google BigQuery ✅ ✅
Clickhouse A FDW for ClickHouse ✅ ✅
Stripe A FDW for Stripe API ✅ ✅
Firebase A FDW for Google Firebase ✅ ❌
Airtable A FDW for Airtable API ✅ ❌
S3 A FDW for AWS S3 ✅ ❌
Logflare A FDW for Logflare ✅ ❌
Auth0 A FDW for Auth0 ✅ ❌
SQL Server A FDW for Microsoft SQL Server ✅ ❌
Redis A FDW for Redis ✅ ❌
AWS Cognito A FDW for AWS Cognito ✅ ❌

这意味着，你现在可以用 PostgreSQL 读写 BigQuery，ClickHouse，以及支付服务 Stripe 数据了。Firebase，Airtable，S3，Logflare，Auth0，SQL Server，Redis，Cognito 也提供了通过 PostgreSQL，使用 SQL 读取的能力。

再比如 plprql 扩展，提供了一种类似于 SQL 的全新数据库查询语言 PRQL：

from invoices
filter invoice_date >= @1970-01-16
derive {
  transaction_fees = 0.8,
  income = total - transaction_fees
}
filter income > 1
group customer_id (
  aggregate {
    average total,
    sum_income = sum income,
    ct = count total,
  }
)
sort {-sum_income}
take 10
join c=customers (==customer_id)
derive name = f"{c.last_name}, {c.first_name}"
select {
  c.customer_id, name, sum_income
}
derive db_version = s"version()"

同时，新加入 Pigsty 的 plv8 扩展，允许你使用 Javascript 在 PostgreSQL 中编写存储过程，PostgreSQL 的存储过程语言支持之丰富，实在是让人惊叹！

pl

再比如说 parquet_s3_fdw，看上去只是让你访问 S3 上存储的 Parquet 文件，但它的意义是 —— PG 可以成为真正的湖仓了 —— 等效于新增了一个没有存储容量限制的分析引擎！

构建在它基础上的 pg_tier，更是提供了便利的分级冷存储功能 —— 你可以将 PG 中很少访问的海量冷存储，用 SQL 轻松归档到 S3 / MinIO 上去！

如果您觉得仅仅是 Parquet 太不过瘾，那么由 ParadeDB 提供的 pg_lakehouse，则把这件事拔高到了一个新高度 —— 你现在可以直接将 PG 作为湖仓使用，读取 S3 / MinIO / 本地文件系统上的 Parquet，CSV，JSON，Avro，DeltaLake，以及 后续的 ORC 格式文件，用于湖仓数据分析！

CREATE EXTENSION pg_lakehouse;
CREATE FOREIGN DATA WRAPPER s3_wrapper HANDLER s3_fdw_handler VALIDATOR s3_fdw_validator;

-- Provide S3 credentials
CREATE SERVER s3_server FOREIGN DATA WRAPPER s3_wrapper
OPTIONS (region 'us-east-1', allow_anonymous 'true');

-- Create foreign table
CREATE FOREIGN TABLE trips (
    "VendorID"              INT,
    "tpep_pickup_datetime"  TIMESTAMP,
    "tpep_dropoff_datetime" TIMESTAMP,
    "passenger_count"       BIGINT,
    "trip_distance"         DOUBLE PRECISION,
    "RatecodeID"            DOUBLE PRECISION,
    "store_and_fwd_flag"    TEXT,
    "PULocationID"          REAL,
    "DOLocationID"          REAL,
    "payment_type"          DOUBLE PRECISION,
    "fare_amount"           DOUBLE PRECISION,
    "extra"                 DOUBLE PRECISION,
    "mta_tax"               DOUBLE PRECISION,
    "tip_amount"            DOUBLE PRECISION,
    "tolls_amount"          DOUBLE PRECISION,
    "improvement_surcharge" DOUBLE PRECISION,
    "total_amount"          DOUBLE PRECISION
)
SERVER s3_server
OPTIONS (path 's3://paradedb-benchmarks/yellow_tripdata_2024-01.parquet', extension 'parquet');

-- Success! Now you can query the remote Parquet file like a regular Postgres table
SELECT COUNT(*) FROM trips;
## count
 2964624
(1 row)

当然，同样由 ParadeDB 出品的 pg_analytics 与 pg_search 扩展也非常值得一提，前者提供了第一梯队的分析性能，而后者提供了 ElasticSearch BM25 全文检索能力的的 PG 替代品。

此外，Tembo 也提供了四个使用 Rust 编写的实用 PG 扩展，例如，他们出品的 pgmq 就可以在 PG 上提供一个轻量的消息队列 API，类似于 AWS 的 SQS 与 RSMQ，作为 pgq 的替代与补充。

在 AI 人工智能方向上，pgvector 0.7 引入了重大的升级，现在支持稀疏向量（让 pg_sparse 原地退役了！），支持 half float 量化，向量最大维度翻倍到了 4000 维，添加了 binary 量化模式（维度可达 64K ），添加了两种新的距离度量与相应的索引。最重要的是，现在还支持用 SIMD 指令了，性能相比一年前有了翻天覆地的改善！

  • Added halfvec type
  • Added sparsevec type
  • Added support for indexing bit type
  • Added support for indexing L1 distance with HNSW
  • Added binary_quantize function
  • Added hamming_distance function
  • Added jaccard_distance function
  • Added l2_normalize function
  • Added subvector function
  • Added concatenate operator for vectors
  • Added CPU dispatching for distance functions on Linux x86-64
  • Updated comparison operators to support vectors with different dimensions

v0.7 changelog

当然，还有其他一些 AI 相关的扩展插件，例如 pg_vectorize 可以帮助你封装实现一个 RAG 服务，新的 pg_tiktoken 可以帮助你在 PG 中，计算调用 OpenAI 模型时所需的 Token 数量。此外，pg_similarity 可以提供 17 种额外的距离度量函数，imgsmlr 可以提供图片相似度处理函数， bigm 可以提供基于二元组的全文检索支持， zhparser 可以提供中文分词能力。

在新的数据类型支持上，md5hash 允许你直接高效存储 128 位的 MD5 摘要，而不是一长串字符文本。 pg_idkit 允许你在数据库中直接生成十多种不同类型的 ID 方案（UUIDv6，UUIDv7，nanoid，ksuid，ulid，Timeflake，PushID，xid，cuid，cuid 等），rrule 扩展更是允许你在数据库中存储、解析、处理“日历重复事件”这一神奇的数据类型。

此外，还有一些扩展，能在数据库管理上提供帮助。pgdd 允许你直接使用 SQL，管理与访问 PG 的数据库目录，pg_later 允许你异步执行 SQL 命令并取回结果。pg_dirtyread 允许你进行脏读，读取尚未被垃圾回收的数据，进行数据抢救，pg_show_plans 可以显示出当前正在运行查询的执行计划！

在加密能力上，pg_tde 扩展提供了一个实验性的 PG 透明加密的存储引擎，用于确保即使你的硬盘被人拔了，数据也不会泄漏。 pgsmcrypto 则为 PostgreSQL 提供了 “国产数据库” 的商密算法（SM2,3,4）支持。

PG 集异璧之大成

加上 以前的扩展，在 Pigsty v2.7 中，在所有操作系统上可用的 PG 扩展数量达到了 255 个之多。 我们可以自豪地说，在整个 PostgreSQL 生态中，没有一个发行版或者服务提供商，能达到我们的收录的这个扩展数量：

extensions

在 EL 系操作系统上，总共有 230 个可用的 RPM 扩展插件，其中包括 73 个 PG 自带的扩展和 157 个第三方扩展，其中由 Pigsty 维护的占 34 个。 在 Debian 与 Ubuntu 系操作系统上，总共有 189 个可用的 DEB 扩展插件，其中包括 73 个 PG 自带的扩展和 116 个第三方扩展，其中由 Pigsty 维护的占 10 个。

完整的扩展列表，请参考 扩展列表

所有的扩展，被我们按照功能与用途分为了 11 个大类，方便用户根据主题选用：

类目 扩展
TYPE pg_uuidv7, pgmp, semver, timestamp9, uint, roaringbitmap, unit, prefix, md5hash, ip4r, asn1oid, pg_rrule, pg_rational, debversion, numeral, pgfaceting
GIS pointcloud, pgrouting, h3, address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster, postgis_sfcgal, address_standardizer, postgis, h3_postgis, pointcloud_postgis, geoip, mobilitydb
SHARD pg_fkpart, pg_partman, plproxy, citus
TEST pgtap, faker, dbt2
SEARCH pg_bigm, pg_search, zhparser
ETL pg_bulkload, wal2json, pg_fact_loader, decoderbufs
REPL pglogical_origin, pglogical, repmgr, londiste, mimeo, pglogical_ticker
SEC pgaudit, pgsodium, anon, passwordcracklib, supabase_vault, pgauditlogtofile, set_user, login_hook, pgcryptokey, pg_jobmon, logerrors, pg_auth_mon, pgsmcrypto, pg_tde, credcheck, table_log, pg_snakeoil
OLAP pg_lakehouse, duckdb_fdw, citus_columnar, parquet_s3_fdw, columnar, pg_analytics, timescaledb, pg_tier
FUNC count_distinct, pgsql_tweaks, tdigest, topn, pgjwt, pg_net, extra_window_functions, http, gzip, pg_later, pg_idkit, pg_background, pgpcre, first_last_agg, icu_ext, q3c, pg_sphere
FDW hdfs_fdw, mysql_fdw, pgbouncer_fdw, mongo_fdw, sqlite_fdw, tds_fdw, ogr_fdw, oracle_fdw, multicorn, db2_fdw, wrappers
LANG plpgsql_check, plsh, pllua, plr, plluau, pldbgapi, plv8, plprql, pg_tle, pljava, hstore_plluau, hstore_pllua, omnidb_plpgsql_debugger
SIM orafce, pg_extra_time, pgmemcache, pg_dbms_job, mysqlcompat, pg_dbms_metadata, pg_dbms_lock
ADMIN pg_readonly, pg_squeeze, pgfincore, pgl_ddl_deploy, prioritize, ddlx, pgagent, pg_repack, pg_cron, pgpool_recovery, pgpool_regclass, pgpool_adm, pg_dirtyread, pgdd, pgautofailover, safeupdate, toastinfo
STAT pg_permissions, pg_qualstats, pg_stat_kcache, pg_stat_monitor, pg_track_settings, pg_wait_sampling, plprofiler, powa, pgexporter_ext, system_stats, pg_store_plans, pgmeminfo, pg_profile, pg_show_plans, pg_statviz
AI pg_tiktoken, imgsmlr, svector, pg_similarity, pgml, vectorize, vector
FEAT periods, pg_ivm, jsquery, hll, pgtt, rum, pg_hint_plan, age, temporal_tables, table_version, pg_graphql, pgq, pgmq, pg_strom, pg_jsonschema, hypopg, emaj, pgq_node, pre_prepare, rdkit

这些扩展之间，许多都可以相互组合使用，产生协同效应，产生 1+1 » 2 的神奇效果。

正如 TimescaleDB CEO Ajay 在 《为什么 PostgreSQL 是未来数据的基石？》 一文中所述，PostgreSQL 正在成为事实上的数据库标准。

通过极致可扩展性的魔法，PostgreSQL 集异璧之大成，做到了守正出奇，实现了主干极致稳定性与功能敏捷性的统一 。 扎实的基本盘配上惊人的演进速度，让它成为了数据库世界中的一个异数，彻底改变了数据库世界的游戏规则。

时至当下，PostgreSQL 已是不可挡。而 Pigsty 让 PostgreSQL 如虎添翼，插上一对起飞的翅膀。

国产信创数据库？

在中国做数据库赛道，绕不开的一个问题就是“国产化”与“信创”。关于这个主题，我已经写过很多文章深入探讨过了：

我的观点是：整个国产信创数据库行业完全基于一个事实上根本不成立的假设 —— 所谓 “数据库卡脖子” 的风险。在开源的 PostgreSQL 面前，所谓卡脖子是个伪命题 —— 如果被欧美严厉制裁的俄国企业们数据库没有崩溃，中国也完全可以同样拿 PG 做同样的事，而不是弄出一堆换皮魔改或土法炼钢的劣质轮子出来。

许多国产数据库都是这样的：企业花点钱买一套“国产 xxx”放在那里，上面来检查了，就拿出来糊弄一下，实际上该用啥还是继续用啥（我要给这种务实的态度点个赞！👍） 但是很多时候，即使客户想要用的就是原生 PG，但没有一块 “国产” 的牌子，确实是很难走立项采购流程的，我们就有一些客户面临这样让人头大的难题。

不过大部分用户也不愿意当傻狍子和冤大头，许多有国产化要求的企业都是这样的：花点钱买一套“国产 xxx”放在那里，上面来检查了，就拿出来糊弄一下，实际上该用啥还是继续用啥（我要给这种务实的态度点个赞！👍） 但是很多时候，即使客户想要用的就是原生 PG，但没有一块 “国产” 的牌子，确实是很难走立项采购流程的，我们就有一些客户面临这样让人头大的难题。

因此，我们想了一个绝妙的折衷办法 —— PolarDB for PostgreSQL。根据 【安全可靠测评结果公告（2023 年第 1 号）】，附表三、集中式数据库： PolarDB 属于自主可控，安全可靠的国产信创数据库。（中国信息安全测评中心-产品测评公告，证书编号：CNITSEC2022I&OE0047）

中国信息安全测评中心-产品测评公告
证号： CNITSEC2022I&OE0047
发证日期： 2022-04-26
截至时间： 2025-04-25
产品名称： 阿里云 PolarDB V2.0 内核核心模块
厂商： 阿里云计算有限公司
认证级别： 自主原创
认证评价：

最妙的是，PolarDB PG 是开源的。所以 Pigsty 提供了对 PolarDB PG 的完整监控支持，以及使用 Docker 进行部署的能力，可以帮助客户快速拉起一个“国产数据库”稻草人，无论是应付检查，还是作为立项采购的名头，都非常好用！ 而且相对于其他那些过时落后，魔改的亲妈都不认识的杂种 PG 国产库，PolarDB 的含 P 量很高，所以如果想用，真的是可以拿来当成一个 PG 11 用起来的。

最后说点实际的，如果你问我，有什么功能是“国产数据库”有，而 PostgreSQL 没有的，我还真知道一个 —— 所谓的 “商密” 算法。最主要的是三个： 用于替代 RSA 的 SM2 算法，用于替代 MD5/SHA 的 SM3 算法，用于替代 DES/AES 的 SM4 算法。但现在，原生的 PostgreSQL 也可以通过 smcrypto 扩展插件也可以提供商密算法支持了！

开箱即用的 ERP

与 “国产数据库” 类似，许多国产 ERP 软件也是处在一个很尴尬的位置上，因为已经有一个足够好的开源 ERP 系统了 —— Odoo （原名 OpenERP）。

不少 Pigsty 的用户是拿着 PG 去跑 Odoo 的，这引起了我的好奇，于是我也混入了 Odoo 社区学习，也自己搭了一套试了一把，确实非常牛逼，要是早点试试这么好的东西，就不去折腾什么土法建站了。

odoo-intro.png

Odoo 插件非常多，功能强大远超我想象，堪称企业应用全家桶大王。

作为开源免费的软件，Odoo 靠高级扩展插件收钱，这个订阅价格也不算贵。要是一分都不想花，Odoo 社区也提供了这些高级扩展插件的免费开源平替版本… —— 高级付费插件（比如财务模块）也有社区开源版！

odoo-module.png

Odoo 使用，且仅使用了 PostgreSQL 作为数据存储。整套 ERP 软件，只需要一个 PG 数据库，一个 Docker 镜像就可以搞定了！堪称是 PostgreSQL 杀手级应用的典范。

作为一个 PostgreSQL 发行版，我没理由不去支持 Odoo。因此在 Pigsty v2.7 中提供了一个 Docker Compose 模板，可以一键拉起 Odoo。你还可以复用 Pigsty 提供的基础设施，轻松通过 Nginx 对外暴露 Web 服务，提供 HTTPS 接入。

最后能实现的效果是，在一台裸虚拟机上，你只需要几行命令就可以拉起生产质量的企业级 ERP 系统！关于 Odoo，后面我会专门出一期教程，介绍如何利用 Pigsty 自建 ERP 系统。

PITR 与监控面板

像 Odoo 这样的 ERP 系统，对数据库的要求与传统互联网行业非常不一样。例如：我在 Odoo 社区看到了如下对话：“我的 Odoo 已经用了好几年了，现在 PostgreSQL 里的数据量已经到 2.5GB 了”，下面朋友回复 —— “那真的是非常大了！”

2.5 GB 的数据量，对于互联网规模的应用来说简直是微不足道。但是对于一个 ERP 系统来说，这已经是一个非常大的数据库了。比起性能 & 高可用，像 ERP 这样的系统更关注的是数据完整性与机密性，很多时候，也就是拿一台服务器就跑起来了，不要 HA，只要有备份与 时间点恢复 （PITR） 就行。

Pigsty 已经提供了开箱即用的 PITR，允许用户回滚到任意时间点。但是这个过程所需的信息和反馈却散落在监控系统中的不同角落中，因此在 Pigsty v2.7 中，Pigsty 提供了一个专用的监控面板 PGSQL PITR，用于提供 PITR 时间点回复过程的上下文。

pitr.png

后面，我们会专门出一期教程，介绍如何利用 Pigsty 的 PITR 功能，实现企业级的数据备份与恢复。

开源版与专业版

在 《Pigsty v2.6：PostgreSQL 踢馆 OLAP》 中，我已经提到过我们将区分 Pigsty 开源版与 专业版。

在 Pigsty v2.7 中，我们将开源版支持的操作系统发行版收敛到 Redhat，Debian，Ubuntu 这三个主干上来。我们提供 PostgreSQL 16 在 EL8，Debian12，Ubuntu22.04 的第一类支持，并提供可以无需互联网进行安装的开源版离线软件包。 当然，EL7，EL9，Debian11，Ubuntu20.04 这些系统还是可以继续使用 Pigsty 的，但是不会有离线软件包，只能通过联网安装的模式进行首次部署。

Pigsty 开源版 Pigsty 基础版 Pigsty 专业版 Pigsty 企业版
开源免费！ 50,000 ¥ / 年 150,000 ¥ / 年 400,000 ¥ / 年
自给自足的开源老司机 或 5,000 ¥/月 或 15,000 ¥/月 或 40,000 ¥/月
PG 支持：16 PG 支持：15，16 PG 支持：12 - 16 PG 支持：9.0 - 16
OS 支持：三系主力版本 OS 支持：五系最新小版本 OS 支持：五系全部小版本 OS 支持：按需定制
EL 8.9 / Debian 12 / Ubuntu 22.04 EL 7.9/8.9/9.3，Ubuntu 20.04/22.04，Debian 11/12 EL 7.x/8.x/9.x，Ubuntu 20.x/22.x，Debian 11.x/12.x EL，Debian，Ubuntu，云上 Linux，国产 OS 与 ARM
功能：核心模块 功能：所有模块 功能：所有模块 功能：所有模块
SLA：无 SLA：工作日时效内响应 SLA：5 x 8 (<4h) SLA：7 x 24 (紧急 on-call)
社区公益支持答疑 提供基础咨询服务 提供专业咨询服务 提供企业级咨询服务

Pigsty 专业版与开源的区别主要在于兼容性与功能模块，例如 PostgreSQL 大版本支持范围，操作系统大版本支持范围，芯片架构支持范围。

在原本的功能设计中，开源版将只包括 INFRA，NODE，PGSQL，ETCD 四个与 PostgreSQL 服务紧密关联的核心模块，我纠结了很久是否要将 MinIO，Redis，FerretDB (Mongo), 以及 Docker 四个 扩展模块 划到专业版中，但最终还是决定将其保留在开源版里 —— 因为它们已经开源了，没道理再阉割掉。 但是与 PostgreSQL 相关性不大的其他模块以及后续的新功能模块，例如 Greenplum，MySQL，DuckDB，Kafka，Mongo，SealOS (Cloud) 都一定会划归专业版中。

在兼容性上，Pigsty 专业版将提供 PG 完整生命周期 12 - 16 五个大版本，在七个主力大版本与其兼容系统上的支持，专业版采用按需定制的方式，交付专业版源码包，以及用户所需操作系统精准小版本的全功能离线软件安装包，包含所有生命周期内 PG 大版本的所有可用扩展插件。 另外，在这个版本中，我们自己维护了完整的 ARM64 Prometheus & Grafana 软件源，也可以在专业版中提供 Arm64 的芯片架构支持了，如果有需要跑在 arm 服务器，或者 “国产芯片” 上，这是一个不错的特性。

总的来说，Pigsty v2.7 的开源/专业版区分，在不影响开源用户使用体验的前提下，又给了企业用户一个充分的付费理由；）。

展望未来

总的来说，Pigsty 已经达到我心目中比较理想的状态了。在功能上，它已经做的足够好了！在某些方面已经远超 RDS 了（比如扩展支持与监控系统）。

但正所谓，酒香也怕巷子深 —— 所以接下来的工作重点会更多地转移到运营、营销、销售上去。开源项目的持续运营离不开用户与客户的支持，如果 Pigsty 帮助到了您，欢迎考虑赞助我们，或采购我们的服务订阅～。

当然，说起运营 —— 就在下周，也就是五月 28 号，我将去温哥华参加 2024 PostgreSQL 开发者大会，a.k.a 第一届 PGConf.Dev （以前叫 PG Con）。共同探讨 PostgreSQL 的未来，并更进一步地把 Pigsty 推向全球！

v2.7.0 发布注记

亮点特性

新增了大量强力扩展插件，特别是一些使用 rust 与 pgrx 进行开发的强力扩展：

  • pg_search v0.7.0：使用 BM25 算法对 SQL 表进行全文搜索
  • pg_lakehouse v0.7.0：在对象存储（如 S3）和表格式（如 DeltaLake）上进行查询的引擎
  • pg_analytics v0.6.1：加速 PostgreSQL 内部的分析查询处理
  • pg_graphql v1.5.4：为 PostgreSQL 数据库提供 GraphQL 支持
  • pg_jsonschema v0.3.1：提供 JSON Schema 校验的 PostgreSQL 扩展
  • wrappers v0.3.1：由 Supabase 提供的 PostgreSQL 外部数据封装器集合
  • pgmq v1.5.2：轻量级消息队列，类似于 AWS SQS 和 RSMQ
  • pg_tier v0.0.3：支将将冷数据分级存储到 AWS S3
  • pg_vectorize v0.15.0: 在 PG 中实现 RAG 向量检索的封装
  • pg_later v0.1.0：现在执行 SQL，并在稍后获取结果
  • pg_idkit v0.2.3：生成多种流行类型的标识符（UUID）
  • plprql v0.1.0：在 PostgreSQL 中使用 PRQL 查询语言
  • pgsmcrypto v0.1.0：PostgreSQL 的国密 SM 算法扩展
  • pg_tiktoken v0.0.1：计算 OpenAI 使用的 Token 数量
  • pgdd v0.5.2：通过纯 SQL 接口，访问数据目录的元数据

当然，也有一些使用原生 C 和 C++ 开发的强力扩展：

  • parquet_s3_fdw 1.1.0：从 S3 存取 Parquet 格式文件，作为湖仓之用
  • plv8 3.2.2：使用 V8 引擎，允许在 PostgreSQL 中使用 Javascript 语言编写存储过程
  • md5hash 1.0.1：用于存储原生 MD5 哈希数据类型，而非文本。
  • pg_tde 1.0 alpha：PostgreSQL 的实验性加密存储引擎。
  • pg_dirtyread 2.6：从 PostgreSQL 表中读取未清理的死元组，用于脏读
  • 新的 deb PGDG 扩展：pg_roaringbitmap, pgfaceting, mobilitydb, pgsql-http, pg_hint_plan, pg_statviz, pg_rrule
  • 新的 rpm PGDG 扩展：pg_profile, pg_show_plans, 使用 PGDG 的 pgsql_http, pgsql_gzip, pg_net, pg_bigm 替代 Pigsty 维护的 RPM。

新特性

  • 允许 Pigsty 在特定 Docker 虚拟机镜像中运行。
  • 针对 Ubuntu 与 EL 系操作系统发行版准备了 INFRA & PGSQL 模块的 arm64 软件包
  • 新安装脚本，可从 cloudflare 下载软件，可以指定版本，提供更完善的提示信息。
  • 新增的 PGSQL PITR 监控面板，用于在 PITR 过程中提供更好的可观测性
  • 针对在 Docker 虚拟机镜像中运行 Pigsty 进行了一系列铺垫与准备。
  • 新增了 防呆设计，避免在非 Pigsty 纳管的节点上运行 pgsql.yml 剧本 （AdamYLK）
  • 针对每个支持的发行版大版本配置了独立的配置文件：el7，el8，el9，debian11，debian12，ubuntu20，ubuntu22

Docker 应用模板

  • Odoo：开源 ERP 软件与插件
  • Jupyter：使用容器运行 Jupyter Notebook
  • PolarDB：运行“国产数据库” PolarDB，应付信创检查！
  • supabase：更新至最近的 GA 版本
  • bytebase：使用 latest 标签替代特定版本号。
  • pg_exporter：更新了 Docker 镜像的例子。

软件版本升级

  • PostgreSQL 16.3
  • Patroni 3.3.0
  • pgBackRest 2.51
  • VIP-Manager v2.5.0
  • Haproxy 2.9.7
  • Grafana 10.4.2
  • Prometheus 2.51
  • Loki & Promtail：3.0.0 (警告：大版本非兼容性变更！)
  • Alertmanager 0.27.0
  • BlackBox Exporter 0.25.0
  • Node Exporter 1.8.0
  • pgBackrest Exporter 0.17.0
  • duckdb 0.10.2
  • etcd 3.5.13
  • minio-20240510014138 / mcli-20240509170424
  • pev2 v1.8.0 -> v1.11.0
  • pgvector 0.6.1 -> 0.7.0
  • pg_tle: v1.3.4 -> v1.4.0
  • hydra: v1.1.1 -> v1.1.2
  • duckdb_fdw：v1.1.0 重新针对 libduckdb 0.10.2 进行编译
  • pg_bm25 0.5.6 -> pg_search 0.7.0
  • pg_analytics: 0.5.6 -> 0.6.1
  • pg_graphql: 1.5.0 -> 1.5.4
  • pg_net 0.8.0 -> 0.9.1
  • pg_sparse (deprecated)

缺陷修复

  • 修复了 pg_exporters 角色中的变量空白问题。
  • 修复了 minio_cluster 变量没有在全局配置中注释掉的问题
  • 修复了 EL7 模板中的 postgis34 插件名称问题，应该使用 postgis33
  • 修复了 EL8 python3.11-cryptography 依赖名的问题，上游现在变更为 python3-cryptography。
  • 修复了 /pg/bin/pg-role 无法在非交互式 Shell 模式下获取操作系统用户名的问题
  • 修复了 /pg/bin/pg-pitr 无法正确提示 -X -P 选项的问题

API 变更

  • 新参数 node_write_etc_hosts，用于控制是否向目标节点的 /etc/hosts 文件写入静态 DNS 解析记录
  • 新增了 prometheus_sd_dir 参数，用于指定 Prometheus 静态服务发现的目标文件目录
  • configure 脚本新增了 -x|--proxy 参数，用于将当前环境的代理信息写入配置文件 by @waitingsong in https://github.com/Vonng/pigsty/pull/405
  • 不再使用 Promtail & Loki 解析 Infra 节点上的 Nginx 日志细节标签，因为这样会导致标签基数爆炸。
  • 在 Prometheus 配置中使用 alertmanager API v2 替代 v1
  • 在 PGSQL 模块中，使用 /pg/cert/ca.crt 代替 /etc/pki/ca.crt，降低对节点根证书的依赖。

新的贡献者

完整的变更日志: https://github.com/Vonng/pigsty/compar

离线软件包校验和 

ec271a1d34b2b1360f78bfa635986c3a  pigsty-pkg-v2.7.0.el8.x86_64.tgz
f3304bfd896b7e3234d81d8ff4b83577  pigsty-pkg-v2.7.0.debian12.x86_64.tgz
5b071c2a651e8d1e68fc02e7e922f2b3  pigsty-pkg-v2.7.0.ubuntu22.x86_64.tgz

发布版本：微信公众号

33 - Pigsty v2.6：PG 踢馆 OLAP

原文发布于 VONNG。

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

二月的最后一天里，Pigsty v2.6 正式发布了 🎉。这个版本正式使用 PostgreSQL 16 作为默认的大版本，并引入了一系列全新的扩展，包括 ParadeDB 与 DuckDB ，让 PostgreSQL 的 OLAP 分析能力提高到一个全新的水准，喊一声 HTAP 标杆，数据库全能王当之无愧。

此外，我们还全面翻新了 Pigsty 官方网站、文档与博客，提出了更为凝练的六条核心价值主张。在全球范围内，我们使用了由 Cloudflare 支持的全新域名 pigsty.io 。作为默认的官方站地址与仓库地址。原有的 pigsty.cc 域名、网站、仓库继续在国内作为镜像提供服务。

最后，我们还正式推出了明码标价的 Pigsty 专业版与服务订阅，为那些需要更强支持力度的用户提供进阶功能与兜底选项。

分析性能史诗级加强

TPC-H 和 Clickbench 是分析领域的权威评测，Clickbench 上有许多 OLAP 数据库性能的横向对比，可以作为量化参考依据。例如在这个最有代表性的例子中，我们可以看到许多知名的数据库组件的相对性能表现（耗时越短越好）：

olap.jpg

c6a.4xlarge, 500gb gp2 / 10亿条记录

在这张图表上我们标注出了 PostgreSQL 与生态扩展插件的性能表现。原生未经过调优的 PostgreSQL 耗时（x1000），调优后可以达到（x47），同时，PG生态还有三个与分析有关系的扩展：列存 Hydra（x42），时序扩展 TimescaleDB（x103），以及分布式扩展 Citus（x262）。但与专注于 OLAP 的第一梯队组件：Umbra，ClickHouse，Databend，SelectDB（x3~x4）相比仍然有十几倍的性能差距。然而最近出现的 ParadeDB 和 DuckDB 的出现改变了这一点！

ParadeDB 提供的 PG 原生扩展 pg_analytics 实现了第二梯队（x10）的性能表现，与第一梯队的 OLAP 数据库只有 3～4 倍的性能差距。比起额外的好处来说：ACID，数据新鲜性，无需 ETL，额外学习成本，维护独立的新服务，（更别提它还提供了 ElasticSearch 质量的全文检索能力），这种性能差距通常是可以接受的。

而 DuckDB （x3.2）则把 OLAP 拔高到了一个全新高度 —— 抛开 Umbra 这种学术类研究数据库的用例，DuckDB 也许是 OLAP 实战性能最快的分析数据库。虽然说它并不是 PG 的扩展插件，但它是一个嵌入式组件，而 DuckDB FDW 以及 pg_quack 这样的项目能让 PostgreSQL 充分利用到 DuckDB 带来的完整分析性能红利！

duck.jpg

来自 ParadeDB 创始人与 DuckdbFDW 作者的感谢致意

全新的价值主张

价值主张是数据库发行版的灵魂，在这个版本中，我们提出了 六条核心价值，如下图所示：

value1.jpg

这张图列出了 PostgreSQL 要解决的六个核心问题：Postgres 的可扩展性，基础设施的可靠性，图形化的可观测性，服务的可用性，工具的可维护性，以及扩展模块和三方组件可组合性。

value2.jpg

Pigsty 的六条缩写正好构成 PIGSTY 首字母缩写 —— 除了 PostgreSQL in Great STYle 之外，这六点价值主张提供了另外一种缩写解释：

Postgres, Infras, Graphics, Service, Toolbox, Yours.

你的图形化 Postgres 基础设施服务工具箱。

同时我们还重新设计了 Logo，从戴墨镜的装象猪头变成了六边形组合，配色正好是这些关键组件的颜色（PG蓝，ETCD青，Grafana橙，Ansible黑，Redis/MinIO 红，Nginx绿），是上图大六边形的一个浓缩精简版本。原来的墨镜小猪将作为 Pigsty 项目的吉祥物继续存在。

mascot.jpg

全新的网站

在这个版本中，我们重新翻修了老网站。使用了最新版本的 Docsy 作为文档框架，并更新调整了大量内容。我们放弃了花哨繁而不实的设计，直接把将 Pigsty 的价值主张与核心特性放在 Landing Page 上。

web1.jpg

而真正的内容，都在文档目录里，我们重新梳理设计了文档的目录结构

web2.jpg

当然，抛下了纯 Markdown 的执念后，我们也可以在文档内容中使用一些好看的样式与花活。

web3.jpg

除了文档外，我们也整理了一下最近的文章纳入 Pigsty 博客。重新划分为六个专栏：云计算泥石流，数据库老司机，以及 PostgreSQL 的生态、开发、管理、内核四个板块。

web4.jpg

与此同时， Pigsty 提供的软件源也有了全球的镜像仓库，由 Cloudflare R2 强力驱动。并托管在 Cloudflare 上，为全球用户都带来丝滑的访问体验（当然国内可以继续使用 pigsty.cc ）。

PostgreSQL 16 成为默认版本

最后一个值得一提的特性是，在 Pigsty v2.6 中，PostgreSQL 16 (16.2) 正式取代先前的 PostgreSQL 15，成为默认的数据库大版本。

在三个月前的 《Pigsty v2.5.1发布：PG16能打了吗？》 中，我们已经指出 PostgreSQL 的主要扩展插件已经就位，加上第二个小版本发布，可以上生产环境了。

而 Pigsty v2.6 正值 PostgreSQL 16.2 第三个小版本发布，Hydra，PGML，AGE 这几个重要扩展也跟进了 PG 16，所以我们决定，正式将默认的 PG 大版本升级为 16 ，而且将成为开源版唯一支持的 PG 大版本（EL7除外）。

因此，在这个版本中，我们做出的另一个重要的技术决策是：在开源版中移除了默认囊括的 PG 12 - 15 软件包与扩展。Pigsty 并非不支持 PG 12 - 15，只需要稍微调整配置文件，就可以轻松使用老版本的 PostgreSQL 扩展插件，只是我们不会再针对这些版本启用集成测试了（虽然在老版本的 Pigsty 里已经测试的很充分了）。

pg16.jpg

同理，我们也将开源版本的支持范围进一步收窄，缩小到 EL 8 / EL 9 与 Ubuntu 22.04 这三个使用范围最广的操作系统发行版上来。因为在 Pigsty 2.5 的时候，我们支持的是 PG 12 - 16 五个大版本乘以七个操作系统发行版，共 34 种排列组合，加上后续的 ARM 适配支持，给测试带来了很大压力。

让开源版聚焦于一个核心PG大版本与三个主流操作系统大版本，可以更好的利用研发带宽，满足最广大开源用户的使用需求。同理，这并不意味着 Pigsty 不能在老系统上用了，你依然可以在 EL7，Ubuntu 20.04，Debian 11/12 上丝滑运行，但我们不会为这些操作系统提供离线软件包，冒烟测试与支持了。

对于小众冷门操作系统系统与过时大版本的支持，并不是占总体绝大多数用户所需要的，却需要耗费许多额外的精力与成本，因此纳入了我们的付费商业支持中。

开源版与专业版划分

有一些开源用户反馈 —— 我并不需要那些和 PostgreSQL 关系不大的东西来拖慢下载安装速度并增加管理复杂度 —— 什么 Redis, MinIO, Docker, K8S，Supabase 之类的，虽然你觉得这些东西能给 PG 打辅助，但花里胡哨的东西只会拖慢我出刀的速度。

具体的功能切割方式还没有确定与落地，因此 2.6 也许是最后一个全功能的 Pigsty 开源版本。但基本原则是，开源版将保留所有的核心功能模块与PG扩展插件（PGSQL, INFRA, NODE, ETCD），而与 PostgreSQL 关系没有那么紧密的模块，在后续可能会作为专业版的内容提供。

pro.jpg

在后面，Pigsty 开源版将专注于做好一件事 —— 提供可靠，高可用，可扩展的本地 PostgreSQL RDS 服务，当然像 Docker 模板这样的实用特性可能还是会留开源版中。

并不是说这些功能在开源版 Pigsty 里就没有了，我相信开源老师傅还是可以很轻松的仅仅通过修改配置文件就把它们重新弄出来，但这些功能不会成为开源版本的默认组成部分了。

商业订阅服务

开源是用爱发电的情怀事业，但要想让这条路走得更长，还需要商业的利益来浇灌。在这个版本中，我们正式推出了商业版本的 Pigsty，为有需要的用户提供更丰富的支持选项。

除了提供额外功能模块支持，Pigsty 专业订阅 还提供了咨询答疑与兜底服务。并且支持更为宽泛的操作系统与数据库版本，如下表所示：

svc.jpg

尽管 Pigsty 本身的宗旨便是让用户拥有开箱即用的数据库服务，甚至还带有硬件故障自愈的 HA 和为软件/人为失误兜底的时间点恢复PITR。也许你拉起了它，一年、两年、三年都没有遇到任何问题 —— 从概率上讲这蛮正常的。

但数据库出了问题，通常都是大问题。用不好数据库，也容易发展成大问题。所以我们也会为付费用户提供专家咨询与服务，作为最终的疑难杂症兜底。（例子：我们抢救过一个烤糊的，没有备份的 Gitlab 数据库）。与此同时，我们也可以提供专业 PostgreSQL DBA 的咨询服务。提供备份、安全、合规建议，管理开发最佳实践，性能评估与优化，设计建议与答疑解惑。

sub.jpg

许多时候，化腐朽为神奇，能带来几个数量级改善的秘密就是专家的一句话。对于以可扩展性作为灵魂，扩展生态极度繁荣的 PostgreSQL 来说更是如此。我们的服务可以确保您的每一分钱都花得物有所值，并花在真正的刀刃上。

展望未来

Pigsty 的下一个大版本计划升级到 v3 ，将会正式落地开源版与专业版的功能划分。我们会在 Ubuntu / Debian 系操作系统中补完缺失的扩展 Deb 包，并提供一个命令行工具来封装管理操作。也许会将 Pigsty 本身打成一个 RPM / Deb 包提供，我们还计划提供 MYSQL 监控部署的 Beta 支持。

在监控系统上，我们会针对 PG 16 提供的 IO 指标重新调整 PostgreSQL 监控面板的样式。提供对 MySQL 的监控能力，尝试使用 Vector 作为日志收集组件 Promtail 的备选替换。我们已经有了针对阿里云 RDS PG 与 PolarDB 的监控，我们也计划在 v3.0 中提供对 AWS RDS 与 Aurora 的监控支持。

在基础设施建设上，我们会选择放弃“便宜”腾讯云 CDN，全面拥抱更可靠更快速且更便宜的 Cloudflare，为全球用户提供服务。腾讯云 CDN 也许可以作为国内的镜像站点，提供专业版的加速服务。

Pigsty 的产品与接口在 v2.6 和 v3.0 将会固化收敛，因为在产品与技术上，它已经做的足够好了！甚至在某些方面已经远超 RDS 了（比如扩展支持与监控系统！）所以接下来的工作终点会转移到营销与销售上来。开源项目的持续运营离不开用户与客户的支持，如果 Pigsty 帮助到了您，欢迎考虑赞助我们，或采购我们的服务订阅～。

v2.6.0

亮点特性

软件配置变更

  • 使用 node_repo_modules 替换 node_repo_method 参数，并移除 node_repo_local_urls 参数。
  • 暂时关闭 Grafana 统一告警功能，避免 “Database Locked” 错误。
  • 新增 node_repo_modules 参数，用于指定在节点上添加的上游仓库源。
  • 移除 node_local_repo_urls，其功能由 node_repo_modules & repo_upstream 替代。
  • 移除 node_repo_method 参数，其功能由 node_repo_modules 替代。
  • 在 repo_upstream 添加新的 local 源，并通过 node_repo_modules 使用，替代 node_local_repo_urls 的功能
  • 重排 node_default_packages，infra_packages，pg_packages，pg_extensions 参数默认值。
  • 在 repo_upstream 中替换 repo_upstream.baseurl 时，如果 EL8/9 PGDG小版本特定的仓库可用，使用 major.minor 而不是 major 替换 $releasever，提高小版本兼容性。

软件版本升级

  • Grafana 10.3
  • Prometheus 2.47
  • node_exporter 1.7.0
  • HAProxy 2.9.5
  • Loki / Promtail 2.9.4
  • minio-20240216110548 / mcli-20240217011557
  • etcd 3.5.11
  • Redis 7.2.4
  • Bytebase 2.13.2
  • DuckDB 0.10.0
  • FerretDB 1.19
  • Metabase：新Docker应用模板

PostgreSQL扩展插件

  • PostgreSQL 小版本升级： 16.2, 15.6, 14.11, 13.14, 12.18
  • PostgreSQL 16： 现在被提升为默认主版本
  • pg_exporter 0.6.1：安全修复
  • Patroni 3.2.2
  • pgBadger 12.4
  • pgBackRest 2.50
  • vip-manager 2.3.0
  • PostGIS 3.4.2
  • TimescaleDB 2.14.1
  • 向量扩展 PGVector 0.6.0：新增并行创建 HNSW 索引功能
  • 新增扩展插件 duckdb_fdw v1.1 ，支持读写 DuckDB 数据 v1.1
  • 新增扩展插件 pgsql-gzip ，用于支持 Gzip 压缩解压缩 v1.0.0
  • 新增扩展插件 pg_sparse，高效处理稀疏向量（ParadeDB） v0.5.6
  • 新增扩展插件 pg_bm25，用于支持高质量全文检索 BM25 算法的插件（ParadeDB） v0.5.6
  • 新增扩展插件 pg_analytics，支持 SIMD 与列式存储的PG分析插件（ParadeDB） v0.5.6
  • 升级AIML插件 pgml 至 v2.8.1，新增 PG 16 支持。
  • 升级列式存储插件 hydra 版本至 v1.1.1，新增 PG 16 支持。
  • 升级图扩展插件 age 至 v1.5.0，新增 PG 16 支持。
  • 升级GraphQL插件 pg_graphql 版本至 v1.5.0 ，支持 Supabase。
330e9bc16a2f65d57264965bf98174ff  pigsty-v2.6.0.tgz
81abcd0ced798e1198740ab13317c29a  pigsty-pkg-v2.6.0.debian11.x86_64.tgz
7304f4458c9abd3a14245eaf72f4eeb4  pigsty-pkg-v2.6.0.debian12.x86_64.tgz
f914fbb12f90dffc4e29f183753736bb  pigsty-pkg-v2.6.0.el7.x86_64.tgz
fc23d122d0743d1c1cb871ca686449c0  pigsty-pkg-v2.6.0.el8.x86_64.tgz
9d258dbcecefd232f3a18bcce512b75e  pigsty-pkg-v2.6.0.el9.x86_64.tgz
901ee668621682f99799de8932fb716c  pigsty-pkg-v2.6.0.ubuntu20.x86_64.tgz
39872cf774c1fe22697c428be2fc2c22  pigsty-pkg-v2.6.0.ubuntu22.x86_64.tgz

34 - Pigsty v2.5：Ubuntu & PG16

原文发布于 VONNG。

GitHub Release | 发布注记

Pigsty v2.5：Ubuntu & PG16

时值 1024 程序员节，Pigsty v2.5.0 发布了 🎉，这个版本添加了对 Ubuntu 与 Debian 系操作系统的支持，加上原有的 EL7/8/9 支持，可谓实现了主流 Linux 操作系统大满贯。

此外，Pigsty 正式支持了自托管的 Supabase 与 PostgresML，以及列式存储插件 hydra，激光雷达点云支持插件 pointcloud，图像相似度计算插件 imgsmlr，扩展距离函数包 pg_similarity 以及多语言模糊检索插件 pg_bigm。

在监控上，Pigsty 优化了 PostgreSQL 监控面板体验，新增了 Patroni & Exporter 监控面板，根据查询宏观优化方法论重新设计了 PGSQL Query 监控面板。

关于 Pigsty

Pigsty 是一个开箱即用的 PostgreSQL 发行版，提供本地优先的 RDS PG 开源替代。它让用户用云数据库 RDS 几分之一的纯硬件成本，自助运行更好的企业级 PostgreSQL 数据库服务。更多介绍请访问 pigsty.cc。

intro

Ubuntu/Debian 支持

在《临水照花看 Ubuntu 与 Debian：Pigsty v2.5》中，我们已经预告了对 Ubuntu / Debian 系操作系统的支持（以下简称 Deb 支持）。从两年前 0.x 版本的时代，就有用户提出想要 Ubuntu 和 Debian 操作系统支持了，所以我觉得这是一件非常正确且重要的事情。

作为一个选择构建于 裸操作系统上 的数据库发行版，支持一种新操作系统并不像容器化数据库打个镜像那么简单。有许多的适配工作需要去做。首当其冲的就是包不齐的问题，好比 Prometheus 就没有官方提供的 DEB 源，不得不自己维护打包并提供一个软件仓库。

apt-yum-repo

Pigsty 维护的 APT/YUM 源

包管理的巨大差别，要求你针对 DEB 系重写整个 bootstrap / 构建本地软件源的逻辑。发行版的 FHS，习惯规约差异需要你一个一个去适配处理。你要解决的不仅是 PostgreSQL 内核和一百多个扩展的完整性兼容性问题，还有 etcd / minio / redis / grafana / prometheus / haproxy 等各种组件的问题。好在 Pigsty 克服了这些问题，让 Ubuntu / Debian 也有了和 EL 7-9 一样完整的丝滑体验。

one-click-install

一键安装 Pigsty

在使用体验上，Deb 系 支持的功能集与 EL 系几乎完全相同，唯一的例外是 supabase 及其使用的几个专用扩展还没有完成移植。除此之外，Deb 系还有一些独有的扩展插件，例如化学分子式扩展 RDKit，激光雷达点云数据扩展 pointcloud / 扩展距离函数包 pg_similarity （这两个给力扩展反向移植到 EL 了）。想要完整发挥 PostgresML + CUDA 的实力，更是非 Ubuntu 不可。

Pigsty 在自动配置过程中添加了 Debian / Ubuntu 系统的识别，单机安装时会自动使用对应的配置模板。Deb 系的模板相比 EL 系只有 8 个参数的默认值有区别 —— 因为两种发行版的包名是不一样的，所以像 xx_packages 的参数肯定是需要调整的。除此之外需要就只有 上游源 repo_upstream，本地源 node_repo_local_urls，以及默认的 pg_dbsu_uid 了（DEB 包没有分配固定 UID）。

ubuntu-config

Ubuntu 系统的声明式配置文件

这些参数通常都不需要用户来调整，所以在 Pigsty 使用流程上，Deb 系可以说几乎没有任何区别了：实际上 Pigsty 的离线软件包构建模版就是这么工作的：一次性在七种不同的操作系统上完成完整的 Pigsty 安装，无需任何特殊处理。

新的扩展插件

Pigsty v2.5 收纳了几款用户呼声比较高的扩展插件。首当其冲的便是 PostgresML。尽管在上一个版本中，Pigsty 已经提供了在 EL8 / EL9 上使用 PostgresML 的能力，但搞 AI 的操作系统基本上都是清一色的 Ubuntu，最起码 CUDA 驱动装起来方便啊。

所以 Pigsty v2.5 中，您可以在 Ubuntu 上运行原生的 PostgresML 集群了。你不需要折腾什么 NVIDIA Docker 之类的东西，pip 安装好 python 依赖，直接起飞就可以。使用 SQL 训练模型，调用模型，让你的整个 AI 工作流都在数据库中完成！

postgresml

第二个值得一提的扩展插件是 pointcloud[1]。因为地理空间扩展 PostGIS 的存在，PostgreSQL 一直是自动驾驶/电车公司的心头好。而 PointCloud 则将 PostgreSQL 与 PostGIS 的力量推广到一个新的边界。激光雷达会不断扫描周围并生成所谓 “点云” 数据。pointcloud 插件提供了 PcPoint & PcPatch 两种数据类型与四十个功能函数，允许您对超高维度的点集进行高效存储、检索与运算。这个插件在 PGDG APT 源中原生提供，而 Pigsty 将其移植到了 EL 系统上，让所有系统的用户都可以用上。

pointcloud

imgsmlr[2] 则是一个以图搜图的插件。尽管现在已经有许多 AI 模型可以将图片编码成高维向量，使用 pgvector 进行语义搜索以图搜图。但 imgsmlr 最有趣的地方在于，它不需要任何外部依赖，可以直接在数据库内完成所有功能。用作者的说法是：我做这个插件的目的不是提供最先进的图像搜索方法，而是告诉你们如何编写一个 PostgreSQL 扩展，来干甚至是图像处理这种非典型的数据库任务。

imgsmlr

首先将 PNG/JPG 图片使用 Haar 小波变换的方式处理为 16K 大小的模式与 64 字节的摘要签名，然后利用 GiST 索引检索摘要的方式来高效实现以图搜图。使用 imgsmlr 从 4 亿随机图片中召回最相似的 10 张大约耗时 600ms。”

另一个有趣的扩展 pg_similarity[3] 默认在 Ubuntu/Debian 的 APT 源中提供，Pigsty 将其移植到了 EL 上。它提供了 17 种文本距离度量函数的高效 C 语言实现，极大丰富了检索排序的能力。另一个相关的插件是 pg_bigm，它类似 PG 自带的 pg_trgm，唯一的区别是用二字组替代三字组实现模糊检索，对中日韩语言的全文检索支持效果更好。

pg-similarity

除此之外，我们还将 Supabase 的支持更新到最新版本：20231013070755。您可以在 EL8/EL9 系统上使用 Pigsty 提供的 PostgreSQL 数据库来自托管 Supabase。

算上 PostgreSQL 自带的扩展，Pigsty 2.5 支持的扩展插件已经达到了 150+。尽管有这么多的插件，但请注意，它们全都是 选装项。Pigsty 为所有 PostgreSQL 大版本都提供了 pg_repack，wal2json，passwordcheck_cracklib （EL）这几个重要的扩展，默认安装的三方扩展只有在线治理膨胀的 pg_repack。其他的扩展如果不安装，对现有系统不会产生任何额外的影响和负担。

监控系统调整

Pigsty v2.5 在监控系统上也进行了调整，将两年没升级的 pg_exporter 更新至了 v0.6.0，新增了 TLS 支持，修复了两个依赖组件的安全问题，打好了 ARM64 软件包并使用最新的指标定义文件。同时，在 pg_query 指标收集器中添加了与共享缓冲区 I/O 有关的四个指标，进一步丰富了 PGSQL Query 中提供的信息。

首先是新增的监控面板：PGSQL Patroni，提供了一个集群高可用状态的完整视图。对于分析历史服务健康状态，主从切换原因都大有帮助。

patroni-dashboard

然后是 PGSQL Exporter，提供了 PG Exporter 和 Pgbouncer Exporter 自我监控的详细指标与日志。可以用于优化调整监控系统本身的性能。

exporter-dashboard

在各种监控大盘的组件导航面板中，都可以点击 Patroni Exporter 的指示块直接跳转到这些组件的详情页中：

component-nav

PGSQL Query 监控面板现在分为五栏：Overview 概览，核心指标 QPS/RT，对时间微分指标，对调用次数的微分指标，百分比指标。遵循了宏观查询优化的方法论进行优化。

减少资源消耗：降低资源饱和的风险，优化 CPU/内存/IO，通常以查询总耗时/总 IO 作为优化目标。使用 dM/dt：指标 M 基于时间的微分，即每秒的增量。

改善用户体验：最常见的优化目标，在 OLTP 系统中，通常以降低查询平均响应时间作为优化目标。使用 dM/dc：指标 M 基于调用次数的微分，即每次调用的增量。

平衡工作负载：确保不同查询组之间的资源使用/性能表现的比例关系得当。使用 M%，即某一类查询指标占总数的比例。

PGSQL 首屏是最核心的查询性能指标：QPS 与 RT —— 以及它们的 1 分钟，5 分钟，15 分钟均值，抖动情况与分布范围。

query-qps-rt

接下来，便是用于优化用户体验的 dM/dc 类指标，这里的 M 指标包括：

  • 每次查询平均返回的行数
  • 每次查询的平均执行时长
  • 每次查询平均产生的 WAL 大小
  • 每次查询平均耗费的 I/O 时间
  • 每次查询平均读写的缓冲区块大小
  • 每次平均访问/写脏的缓冲区块大小
query-dmc

随后是用于 减少资源消耗 的 dM/dt 类指标，这里的 M 指标基本同上，不同之处在于它是针对时间的微分而不是针对调用次数的微分：

query-dmt

最后一栏中，我们展示了用于平衡工作负载的 %M 类指标。用于揭示这个特定查询组在整个工作负载中的比例与相对位置，标黑加粗显示，点击特定查询可以原地跳转查看另一组查询的性能表现，非常方便。

query-percent

除了上面三个 Dashboard 之外，Pigsty 也对许多其他面板进行了优化改进与问题修复。许多面板的信息栏现在会提供更详细的信息：这个面板展现了什么指标，用于解决什么问题，等等等。我们也引入了三个新的 Grafana 插件用于支持 CSV/JSON 数据源，以及变量面板。

下个版本做点啥？

Pigsty 的下一个版本是 v2.6.0，除了进一步巩固 Ubuntu/Debian 的支持成熟度，这个版本的关注焦点将会关注两件事：MySQL 支持与命令行工具。

Pigsty 将提供基本的（主从，但没有 HA） MySQL 安装部署支持，并提供基于 Grafana / Prometheus / MysqldExporter 的监控。因为 MySQL 5.7 将于本月 EOL，相信这样的能力会让更多的 MySQL 用户接触 PostgreSQL 并方便地迁移上来。

此外，我们还会进一步探索 Infra 组件容器化，调研使用 VictoriaMetrics 默认替换 Prometheus，或者使用 Vector 与 VictoriaLogs 替代 Loki 与 Promtail 的可行性。并设计一个更加好用的管控命令行工具 pigsty-cli，对 Greenplum 7.0 的部署提供正式支持，当这些任务都完成后，Pigsty 就将迎来第三个大版本 v3 了。

发布注记

PGSQL x Pigsty：数据库全能王来了

如何用 Pigsty 监控现有 PostgreSQL (RDS/PolarDB/自建)？

Pigsty 特性与快速上手

EL 系操作系统发行版哪家强？

临水照花看 Ubuntu 与 Debian：Pigsty v2.5

PostgreSQL：世界上最成功的数据库

Pigsty 2.4：PG16 支持，RDS 监控与新扩展！

Pigsty v2.3.1：HNSW 版 PGVECTOR 来了！

Pigsty v2.3 发布：应用生态丰富

Pigsty v2.2 发布 —— 监控系统大升级

Pigsty v2.1 发布：向量扩展 / PG12-16 支持

Pigsty v2.0.2 更好的开源 RDS 替代：Pigsty

Pigsty v2.0 发布，炮打 RDS

Pigsty v2 正式发布：更好的 RDS PG 开源替代

Pigsty v1.5.1 发布

Pigsty v1.5 发布与新特性

Pigsty v1.4 正式发布！

Pigsty v1.4 前瞻

Pigsty v1.3.1 安装教程

开箱即用的 Redis 发行版 —— Pigsty v1.3

Pigsty v1.2 发布

Pigsty v1.1 发布/新功能介绍

Pigsty v1 正式发布：开箱即用的 PostgreSQL 开源发行版

References

v2.5.0 

curl https://get.pigsty.cc/latest | bash

亮点特性

  • Ubuntu / Debian 支持：bullseye，bookworm，jammy，focal

  • 使用 CDN repo.pigsty.cc 软件源，提供 rpm/deb 软件包下载。

  • Anolis 操作系统支持（ 兼容 EL 8.8 ）。

  • 使用 PostgreSQL 16 替代 PostgreSQL 14 作为备选主要支持版本

  • 新增了 PGSQL Exporter / PGSQL Patroni 监控面板，重做 PGSQL Query 面板

  • 扩展更新：

    • PostGIS 版本至 3.4（ EL8/EL9 ），EL7 仍使用 PostGIS 3.3
    • 移除 pg_embedding，因为开发者不再对其进行维护，建议使用 pgvector 替换。
    • 新扩展（EL）：点云插件 pointcloud 支持，Ubuntu 原生带有此扩展。
    • 新扩展（EL）： imgsmlr， pg_similarity，pg_bigm 用于搜索。
    • 重新编译 pg_filedump 为 PG 大版本无关的软件包……
    • 新收纳 hydra 列存储扩展，不再默认安装 citus 扩展。

  • 软件更新：

    • Grafana 更新至 v10.1.5
    • Prometheus 更新至 v2.47
    • Promtail/Loki 更新至 v2.9.1
    • Node Exporter 更新至 v1.6.1
    • Bytebase 更新至 v2.10.0
    • patroni 更新至 v3.1.2
    • pgbouncer 更新至 v1.21.0
    • pg_exporter 更新至 v0.6.0
    • pgbackrest 更新至 v2.48.0
    • pgbadger 更新至 v12.2
    • pg_graphql 更新至 v1.4.0
    • pg_net 更新至 v0.7.3
    • ferretdb 更新至 v0.12.1
    • sealos 更新至 4.3.5
    • Supabase 支持更新至 20231013070755

Ubuntu 支持说明

Pigsty 支持了 Ubuntu 22.04 (jammy) 与 20.04 (focal) 两个 LTS 版本，并提供相应的离线软件安装包。

相比 EL 系操作系统，一些参数的默认值需要显式指定调整，详情请参考 ubuntu.yml

  • repo_upstream：按照 Ubuntu/Debian 的包名进行了调整
  • repo_packages：按照 Ubuntu/Debian 的包名进行了调整
  • node_repo_local_urls：默认值为 ['deb [trusted=yes] http://${admin_ip}/pigsty ./']
  • node_default_packages：
    • zlib -> zlib1g, readline -> libreadline-dev
    • vim-minimal -> vim-tiny, bind-utils -> dnsutils, perf -> linux-tools-generic,
    • 新增软件包 acl，确保 Ansible 权限设置正常工作
  • infra_packages：所有含 _ 的包要替换为 - 版本，此外 postgresql-client-16 用于替换 postgresql16
  • pg_packages：Ubuntu 下惯用 - 替代 _，不需要手工安装 patroni-etcd 包。
  • pg_extensions：扩展名称与 EL 系不太一样，Ubuntu 下缺少 passwordcheck_cracklib 扩展。
  • pg_dbsu_uid：Ubuntu 下 Deb 包不显式指定 uid，需要手动指定，Pigsty 默认分配为 543

API 变更

默认值变化：

  • repo_modules 现在的默认值为 infra,node,pgsql,redis,minio，启用所有上游源

  • repo_upstream 发生变化，现在添加了 Pigsty Infra/MinIO/Redis/PGSQL 模块化软件源

  • repo_packages 发生变化，移除未使用的 karma,mtail,dellhw_exporter，移除了 PG14 主要扩展，新增了 PG16 主要扩展，添加了 virtualenv 包。

  • node_default_packages 发生变化，默认安装 python3-pip 组件。

  • pg_libs: timescaledb 从 shared_preload_libraries 中移除，现在默认不自动启用。

  • pg_extensions 发生变化，不再默认安装 Citus 扩展，默认安装 passwordcheck_cracklib 扩展，EL8,9 PostGIS 默认版本升级至 3.4

    - pg_repack_${pg_version}* wal2json_${pg_version}* passwordcheck_cracklib_${pg_version}*
- postgis34_${pg_version}* timescaledb-2-postgresql-${pg_version}* pgvector_${pg_version}*

  • Patroni 所有模板默认移除 wal_keep_size 参数，避免触发 Patroni 3.1.1 的错误，其功能由 min_wal_size 覆盖。

87e0be2edc35b18709d7722976e305b0  pigsty-pkg-v2.5.0.el7.x86_64.tgz
e71304d6f53ea6c0f8e2231f238e8204  pigsty-pkg-v2.5.0.el8.x86_64.tgz
39728496c134e4352436d69b02226ee8  pigsty-pkg-v2.5.0.el9.x86_64.tgz
e3f548a6c7961af6107ffeee3eabc9a7  pigsty-pkg-v2.5.0.debian11.x86_64.tgz
1e469cc86a19702e48d7c1a37e2f14f9  pigsty-pkg-v2.5.0.debian12.x86_64.tgz
cc3af3b7c12f98969d3c6962f7c4bd8f  pigsty-pkg-v2.5.0.ubuntu20.x86_64.tgz
c5b2b1a4867eee624e57aed58ac65a80  pigsty-pkg-v2.5.0.ubuntu22.x86_64.tgz

v2.5.1

跟进 PostgreSQL v16.1，v15.5，14.10，13.13，12.17，11.22 小版本例行更新。

现在 PostgreSQL 16 的所有重要扩展已经就位（新增 pg_repack 与 timescaledb 支持）

  • 软件更新：

    • PostgreSQL to v16.1, v15.5, 14.10, 13.13, 12.17, 11.22
    • Patroni v3.2.0
    • PgBackrest v2.49
    • Citus 12.1
    • TimescaleDB 2.13
    • Grafana v10.2.0
    • FerretDB 1.15
    • SealOS 4.3.7
    • Bytebase 2.11.1

  • 移除 PGCAT 监控面板中查询对 monitor 模式前缀（允许用户将 pg_stat_statements 扩展装到别的地方）

  • 新的配置模板 wool.yml，为阿里云免费 99 ECS 单机针对设计。

  • 为 EL9 新增 python3-jmespath 软件包，解决 Ansible 依赖更新后 bootstrap 缺少 jmespath 的问题

31ee48df1007151009c060e0edbd74de  pigsty-pkg-v2.5.1.el7.x86_64.tgz
a40f1b864ae8a19d9431bcd8e74fa116  pigsty-pkg-v2.5.1.el8.x86_64.tgz
c976cd4431fc70367124fda4e2eac0a7  pigsty-pkg-v2.5.1.el9.x86_64.tgz
7fc1b5bdd3afa267a5fc1d7cb1f3c9a7  pigsty-pkg-v2.5.1.debian11.x86_64.tgz
add0731dc7ed37f134d3cb5b6646624e  pigsty-pkg-v2.5.1.debian12.x86_64.tgz
99048d09fa75ccb8db8e22e2a3b41f28  pigsty-pkg-v2.5.1.ubuntu20.x86_64.tgz
431668425f8ce19388d38e5bfa3a948c  pigsty-pkg-v2.5.1.ubuntu22.x86_64.tgz

发布版本：微信公众号

35 - PGSQL x Pigsty: 数据库全能王来了

原文发布于 VONNG。

Pigsty v2.4.1已于 9 月 24 日正式发布。核心关注点是：如何聚拢PostgreSQL 生态里游离的超能力，发挥出 1 + 1 远大于 2 的协同增幅效果。

我们引入了 12 个由自己编译打包、整合维护的全新扩展，并加入了三个强力组件的原生支持： Suapbase，PostgresML 与 FerretDB。让 Pigsty 收录的扩展数量已经达到了破纪录的 150 个，全部开箱即用！

图片

在这些新增/现有扩展的加持下，PostgreSQL —— 这个世界上最先进的开源关系型数据库，已经堪称是 数据库全能王 了。

图片

Supabase 是一个有着 57K Star 的明星项目，基于 PostgreSQL 提供 Firebase 的开源替代。而 PostgresML 则是在 Postgres 里搞大模型训练调用/经典机器学习算法的当红炸子鸡。FerretDB 则提供基于 PG 的 MongoDB 兼容性：Pigsty 与这些社区都建立了良好的合作关系。

Supabase

我先前一直倡导一种基于 PostgreSQL 进行低代码开发的理念 —— 你只要设计好数据库模式，其实大部分后端代码编写是可以自动化生成的。

像 PostgREST 这样的工具可以自动从中反射生成定义良好，文档详实的 RESTful API。也有像 PostGraphile 这样的工具可以自动反射出 GraphQL API，最后，使用 Kong 这样的 API 网关套一层，解决好认证、日志、限流的问题。用户完全可以在一行后端代码都不写的情况下，完成一个完整业务应用的开发。

Pigsty 确实也整合并提供了这些趁手的工具，但而 supabase 不仅实现了上面这个愿景，更是将其实现到了一个全新的高度。

图片

Supabase 帮全栈应用开发者补完了从数据库到前端之间的鸿沟：一键完成各种认证接入（邮件密码/手机号/魔法连接/社交网站登陆等等）；自动生成数据库 REST API 与 GraphQL API，通过 Websocket 发送数据库变更的实时通知，提供完整的文件上传下载/断点续传/图片变换/CDN 分发功能，以及在全球分发管理 CDN 边缘 TS 函数，还提供一个优雅的管理控制台 GUI 与命令行工具管理所有一切。

Suapbase 的所有的功能都围绕 PostgreSQL 这个核心，并通过 Kong API 网关对外暴露。有了 Supabase，用户不需要再操心经典“后端”的实现细节，只需要做好数据库模型设计，与前端 API 调用就够了。

图片

supabase 组件架构图

Supabase 封装了一部分 PostgreSQL 数据库管理的工作，包括一个单实例的 PostgreSQL 内核，加上自行维护的 pg_graphql, pg_net,vault,pgjwt 等扩展插件，充分利用了触发器，全文检索，密钥存储功能。提供了基础的 PITR 备份支持，还不错的安全管理最佳实践，与一个数据库管控 GUI 工具：Supabase Studio，可以说，对于一个起步阶段的应用来说是没问题的。

图片

当然对于一个严肃的生产应用来说，数据库这部分还有许多问题有待解决：Supabase 的 Postgres 中仍然缺少 PostgreSQL 生态里的许多功能扩展，单实例+PITR 的设计也不足以克服硬件失效带来的可用性冲击。在可靠性，安全性，性能，可观测性上也都还有许多薄弱环节。

但是不用担心，Pigsty 会帮助 Supabase 解决这些问题 —— 您现在可以使用由 Pigsty 所创建托管都故障自愈的多节点高可用 PostgreSQL 集群来承载 Supabase 上层的无状态服务部分。开源生态的魅力就在这里 —— 每个人干好自己最擅长的事情，而所有人都可以从中受益！

图片

一键拉起 Supabase 所需的数据库

您只需要使用默认的 supabase 模板，即可一键部署 Supabase 所需要的数据库集群，您不需要操心用户、扩展、模式、HBA 这些细节。只需要在.env配置文件模板中填入数据库连接串，然后 docker compose up，你的 supabase 就立即进入可用状态了！

PostgresML

另一个 2.4 带来的的重大更新是 PostgresML。AI 时代带火了向量数据库，这个方向上pgvector 已经交出了一份足够令人满意的答卷。但是存储嵌入只是 AI 生态对数据库需求的一部分，AI 的灵魂还是模型。PostgresML 则弥补了这一点缺憾：现在您可以在数据库中用 SQL 调用经典机器学习算法，以及直接调用 —— Hugging Face 上的模型，进行训练，微调，与预测。

图片

PostgresML 是用 RUST 编写的扩展，在一些运算密集型任务上使用 RUST linalg / BLAS 线性代数库取得了相比 Python 8x - 40x 的性能表现。更重要的是：它为 Python3 机器学习/AI 工具链提供了 SQL Binding。以前您需要自行处理模型的选用，下载，部署与管理问题。而现在您不需要再了解这些繁琐的细节了！直接用拿着模型名字调函数就够了！

图片

PostgresML 可以直接下载 Hugging Face 上的模型，对输入进行 Embedding，生成向量，并使用 pgvector 进行存储。让整个语义搜索的工作流在数据库内部完成闭环！原地完成数据准备、训练微调、预测输出、结果存储。

图片

尽管 PostgresML 提供了官方 Docker 镜像，但它与各种 Postgrs 衍生镜像有着同样的问题 —— 难以利用好 PostgreSQL 生态系统的合力。您没有办法轻易为其加装想要的扩展并与其组合使用，以及，单机容器实例对于生产应用实在是过于简陋了。

Pigsty 可以帮您解决这个问题，您可以在拥有地理、时序、图、向量、全文检索、GraphQL，HA / PITR / IaC / Monitor 等能力的同时，一键加装 PostgresML 扩展。PGML 与其他扩展的唯一区别就是，需要一些额外的 python / pip / virtualenv 环境的简单配置。但我相信这两行命令肯定也难不倒你。\

FerretDB

FerretDB 是另一个非常有趣的项目，之前的名字叫 “MangoDB”，因为有碰瓷 “MongoDB” 的嫌疑，所以在 1.0 版本改成了现在的名字。但这不影响它的效果 —— 在 PostgreSQL 上提供 MongoDB Wire Protocol 支持，让 PG 假扮成一个 MongoDB！上次做这种事的插件是 AWS 的 Babelfish，让 PostgreSQL 兼容 SQL Service 的线缆协议假扮成 MSSQL。

图片

PostgreSQL 的 JSON功能 已经非常完善了：二进制存储 JSONB，GIN 任意字段索引，各种 JSON 处理函数，JSON PATH 和 JSON Schema，它早已是一个功能完备，性能强大的文档数据库了。PostgreSQL 生态里还有 mongo_fdw 这样的组件，允许用户用 SQL 来访问现有的 MongoDB 数据。

但是提供替代的功能，和直接仿真还是不一样的。FerretDB 就可以为使用 MongoDB 驱动的应用程序提供一个丝滑迁移到 PostgreSQL 的过渡方案。MongoDB 中的主要特性：文档数据模型、运算符/函数，索引、增删改查，聚合等等都没啥问题。不过您要是用到了一些高级特性，那就不一定照顾的到了。

Pigsty 在 1.x 中就提供了基于 Docker 的 FerretDB 模板，在 v2.3 中更是提供了原生的部署支持。在 v2.4.1 中，FerretDB 更新到了 v1.10 版本。它作为一个选装项，是丰富 PostgreSQL 生态大有裨益。Pigsty 社区已经与 FerretDB 社区成为了合作伙伴，后续将进行深度的合作与适配支持。

zhparser

PostgreSQL 的 JSON 特性可以对标 MongoDB，而在全文检索能力上也有对标 ElasticSearch 的东西 —— TSQuery 与 TSVector。不同于 MySQ L 凑数的 ngram “全文检索” 实现（PG 对应物叫 pg_trgm），PostgreSQL 自带了各种语言的分词算法，开箱即用。唯一让人遗憾的就是，许多西文都天然会使用空格进行分词，但中文分词的问题要麻烦的多，针对西文的自带分词算法并不好使。

图片

zhparser 的出现解决了这个问题。zhparser 使用 scws 项目进行中文分词，默认词库中标注了大量汉语词性，便于用户在创建分词配置时进行深度的定制。Pigsty 为 scws 与 zhparser 维护了 RPM 包，让用户可以开箱即用，体验完整的中文全文检索能力。

更有趣的是，向量数据库的语义搜索，也可以与这里的全文检索组合使用，向用户返回更具有可解释性的结果。

图片

Apache AGE

另一个在 v2.4 引入的 PostgreSQL 强力扩展插件是 Apache AGE，AGE 是 “A Graph Extension” 的缩写 —— “一个图数据库扩展”。AGE 最初是另一个 PostgreSQL 上的图数据库扩展 AgensGraph 的分叉，并在 2020 年进入 Apache 基金会，2022 毕业为顶级项目。

AGE 的功能就是为 PostgreSQL 添加图数据库的能力。尽管 PostgreSQL 本身已经提供了类似的机制 —— 递归查询。但是 AGE 把原汁原味的 Cypher 图查询语言添加到了 PG 里，而且还能完全兼容现有的 PostgreSQL ACID 能力。并允许你您混合执行 Cypher 查询与 SQL 查询进行数据分析。

图片

对于图数据库来说，Cypher 语言提供的 MATCH 非常有表达力。例如上面 4 行 Cypher 查询如果用 PostgreSQL 的标准建模方式与递归查询能力，其实也是可以实现的，但显然要啰嗦上许多。

图片

PG GraphQL

说起图来，除了 Neo4J 这类“图数据库”，还有一个与数据库有点关系的东西 —— GraphQL：这是与 REST API 对应的一种 API 设计新范式。

GraphQL 为 API 提供了一种声明式的查询语言：用户声明自己想要什么东西，并获取可预期的结果；一次请求可以拿到多种所需的资源，避免重复调用手动拼接；自带的类型系统、IDE 工具让 API 的使用更加简便。

这也是 supabase 超能力的一个重要来源 —— pg_graphql。这是一个使用 RUST 开发的 PG 插件，由 suapbase 团队维护。想要在托管 PostgreSQL 实例上运行 Supabase，首先要解决的就是这些 Supabase 专有扩展的问题。Pigsty 已经帮用户把这部分做了：不过只支持 EL 8/9 上的 PG 14/15。

图片

为 PostgreSQL 添加 GraphQL API 支持这件事，早在 七八年前就有人做过了，比如 postgraphql，就可以反射 PG 内部的模式，并自动生成查询数据库的 GraphQL API。

然而，还没有一个工具能像 pg_graphql 这样，直接在 PostgreSQL 数据库内部，通过内建函数的方式，提供了原生的 GraphQL 查询支持！这意味着你不需要维护任何额外的组件，就可以使用全新的语言来访问 PostgreSQL 的数据了。

PG NET/HTTP

用 SQL 接口发送接收 HTTP 请求并不是一个新鲜事儿，Oracle 的 UTL_HTTP 包就是干这个的。PostgreSQL 也可以通过各种语言的存储过程来发送 HTTP 请求。但 pgsql-http 与 pg_net 则利用原生的 curl API，提供了 SQL 直接可用的 HTTP 接口，发送同步/异步请求，并处理响应数据，这显然比写存储过程要优雅多了！

图片

您可以直接使用 SQL 构建 HTTP 请求，拼接首部，使用 pgcrypto 对请求进行签名。同步/异步发送 HTTP 请求，并使用 JSON 特性来解析处理结果，这项特性有着近乎无限的想象空间 —— 可以玩出许多“骚操作”。比如，如果你的咖啡机可以响应 HTTP 请求，那么调用 API 就能让你的数据库煮咖啡的能力了。

你可以在数据库内写爬虫，查询天气，拉取账单，也可以用这个能力来实现一些更有生产价值的功能，比如任务执行完毕后发送通知，或者当表/行出现增删改时通过 HTTP 请求与外部进行通信同步：或者实现类似于 Infra as CMDB SQL 的效果。

PG FileDump

pg_filedump 是 v2.4.1 引入的另一个“扩展”。它实际上是一个 PG 版本相关的二进制程序：可以用来从 PostgreSQL 数据页面中抽取数据。当您的数据库或者磁盘爆炸又没有备份的话，它会成为一棵救命稻草。

引入它的契机正是因为最近我们接了一个比较离谱的 PG 数据恢复的活儿，只有一些残余的二进制文件可供抽取还原。而 pg_filedump 就是这样一个趁手的工具。使用起来也很直接，用 -D 告诉 pg_filedump 如何解释表二进制文件里每一行的二进制数据就可以了。关于它的用法，后面我们准备了一篇关于底层数据恢复的案例，将于最近几天发出。

图片

尽管 pg_filedump 还存在一些局限性：例如对于复杂的 JSON/数组数据处理还有缺陷。但作为一个应急工具来说，已经足够好用了。我们针对 PG 12 - 16 提供了此扩展。我们希望您永远也不要用到这个扩展，但我们也希望：当您需要它的时候，它已经在那里了。

Hydra / Citus

Hydra 是一个列式存储扩展，旨在为 PostgreSQL 提供高性能的向量化列存储扩展。PostgreSQL 生态其实已经有一些列式存储扩展，例如 Citus 自带的 columnar，以及 TimescaleDB 针对时序数据的压缩列存引擎。不过看起来 hydra 在这个领域又达到了新的高度：在它给出的样例场景中（500G count），它可以达到令人震惊的加速比：从四五分钟到亚秒级。

图片

Hydra Fork 自 Citus 的列存插件 columnar，但进行了许多改进优化，例如矢量化执行，查询并性化，并进行了一系列针对性的调优。hydra 目前已经 1.0 GA，Pigsty 针对 PG13 - 15 提供了它的 RPM 包，放在 Pigsty 官方 yum 源中。

不过目前 Pigsty 的离线软件包里默认并没有收录它，因为它与 Citus 的 columnar 有同名冲突。Hydra 的列存插件号称可以原地替换掉 Citus 的列存实现，所以您依然可以方便地通过简单配置，一键安装替换。

图片

这里顺带一提，除了上面介绍的几个新增扩展外，Pigsty 本身也早已经支持了许多经典扩展，例如 Citus 就是最重要的扩展之一。Citus 可以将经典的主从 PG 集群原地改造为一个水平分片的分布式数据库集群，提供 scale out 与并行加速的能力。

Citus 被微软收购后变为 Azure 上的 Hyperscale for PostgreSQL 数据库，且使用 AGPLv3 协议完全开源。原本企业版的能力（例如在线分片平衡）也完全开源可用了，对于分布式 SQL 的支持程度要比许多基于中间件的方案还要靠谱得多。

图片

Pigsty 很早便提供了对 Citus 的第一等支持：您可以方便地一键搭建由 Patroni 管理的高可用 Citus 水平分布式集群组，享受灵活的动态扩缩容与分布式 HTAP 查询能力。

Embedding / Vector

向量数据库大火，PG 生态的 PGVECTOR 就是我们提进 PGDG 官方仓库的，所以我们之前也写了一些专题文章进行介绍（《PGVECTOR 与 AI 大模型》）。不过 PostgreSQL 生态的向量数据库扩展，可不是只有 pgvector 一个选手，另一个有些许竞争力的向量扩展是 pg_embedding。

pg_embedding 由 PostgreSQL 当红炸子鸡创业公司 neon 维护，主打的卖点是性能：HNSW 索引比 IVFFLAT 有一些显著的优势。不过 PGVector 在最近的版本 v0.5 之后也提供了 HNSW 索引，所以这里的利弊权衡就比较微妙了。

图片

不同于 pgvector 使用独立的新类型 vector，pg_embedding 是建立在 PostgreSQL 现有的浮点数组类型之上的：向量的数据类型是 PostgreSQL 原生的 real[]。这种做法有利有弊：好处是不需要一个新类型，坏处是它指定死了浮点数的精度（Float4），不利于后面添加降低精度/量化之类的功能实现。但总之，我们也将其收录到了 Pigsty 的扩展列表中，供用户选用与评估。

图片

此外，还有几个向量扩展插件，例如使用 RUST 重写的 pgvector.rs，以及刚冒出来的 Latern。前者功能已经被 PGVector 完整覆盖，后者则是 pg_embedding 的拙劣分支换皮，因此并未收入 Pigsty 中。

经典的时空扩展

除了上面介绍的几个新增扩展外，Pigsty 本身也早已经支持了许多经典扩展，例如 PostGIS 与 TimescaleDB。便是为 PostgreSQL 提供了地理空间时序事件处理的能力，堪称 PG 的杀手级扩展。每一个的分量都配得上一个专用数据库的称号，但它们却愿意选择成为 PG 生态的扩展，而不是自立门户。\

PostGIS 的能力不用过多介绍，做 GIS 的人都懂。MySQL，Mongo 这些数据库确实跟进了一些 ST_XX 空间函数，但是在 PostGIS 依然有着碾压性的优势：它已经成为了地理空间信息处理的事实标准了。

图片

TimescaleDB 为 PostgreSQL 提供了一系列非常实用的功能：强大的写入能力，完整的 SQL 能力，时间桶聚集函数，持续聚集，数据生命周期管理：设置分区/分级/压缩/降采样/保留策略，列存储/分布式实现，覆盖了时序相关数据的方方面面。\

图片

在 benchant 提供的时序数据库测评中，TimescaleDB 是唯一上榜的“扩展”，排在专用时序数据库 IoTDB 与 QuestDB 之后。尽管在性能单项上与榜一大哥有差距，但数据库领域比拼的从来都是综合实力 —— 它的背后，还站着整个 PostgreSQL 生态系统。

图片

专用数据库并非不好：专用组件在自己领域中的实力毋庸置疑。但正如向量数据库领域正在发生的事一样：那些使用多种专⻔数据库客户会不断遇到这类典型问题：数据冗余、大量不必要的数据搬运工作、分布式组件之间的缺乏数据一致性、额外的专业技能劳动力成本、额外的软件许可成本、有限的查询语言能力、可编程性和可扩展性、有限的工具集成、以及与真正数据库相比更差的数据完整性和可用性。

图片

其他扩展

Pigsty 提供了 150+ 扩展插件（包括 PG 自带的一些 Contrib 插件），一次性同时把所有 150 个扩展安装上去是可行的，尽管这可能是一种相当疯狂的做法。

好在所有的扩展插件都是可选项，您完全完全可以按需定制，选择自己想要启用哪些扩展插件。Pigsty 确保所有这些扩展都可以一键从 Yum 安装，正确地 CREATE EXTENSION 不出错。对于重要的核心扩展来说，Pigsty 更是通过各种测试确保它们可以稳定运行并协同工作。

图片

Pigsty 会为您默认安装一些重要的扩展：PostGIS，TimescaleDB，Citus，PGVector，PG Repack，wal2json。但并不是所有默认安装的扩展都会被激活：Pigsty 为您“自作主张”默认启用了 pg_stat_statements （查询监控），pg_repack （膨胀维护）以及 timescaledb（时序支持），您完全可以通过配置将其禁用。

图片

除了上面介绍的插件之外，PG 生态还有许多许多未被 PGDG 与 Pigsty 收录的扩展。如果您有一些想用的扩展没有被收录，欢迎在 Pigsty 仓库中提 Issue，或者使用 Pigsty 提供的编译基础设施自行打包、分发使用。

The Linux of Database

可以说，在上面这些扩展的加持之下，PostgreSQL 已经从一个强大的关系型数据库，变成一个怪兽级的多模态数据库全能王：自主可控自动驾驶时序地理空间 AI 向量分布式文档图谱全文检索可编程超融合联邦流批一体 HTAP Serverless 全栈式平台数据库。

PostgreSQL 是一专多长的全栈数据库，天生就是 HTAP，超融合数据库，基本单一组件便足以覆盖中小型企业绝大多数的数据库需求：在关系型 OLTP 上对标 Oracle/MySQL，有 JSONB/GIN 对标 MongoDB，有 PostGIS 对标地理空间数据库，有 TimescaleDB 来对标时序/流数据库，有 Citus/Hydra 来对标分布式/列存储/HTAP 数据库，有全文检索来对标 ElasticSearch，有 AGE/EdgeDB 来对标图数据库，有 pgvector 来对标专用向量数据库。这些惊人的多模态能力，正是源自 PG 的扩展能力。

图片

PostgreSQL 的可扩展机制与插件系统，让它不再仅仅是一个单线程演化的数据库内核，而可以有无数并行发展的支线，像量子计算一样同时探索各种方向上的可能性。每一个数据处理的细分垂直领域 PG 都不会缺席。就好比最近向量数据库领域大火，别的数据库都还没反应过来，PG 生态立刻就涌现出好几个相关插件，以迅雷不及掩耳之势抢占了这一块生态位。更有趣的是，扩展完全是按需启用的可选项**，并不会影响内核主干的稳定性**。

我认为在当下，数据库领域即将迎来 Linux 时刻 —— PostgreSQL 成为数据库领域的 Linux 内核。你并不难找到某个专业数据库在某个专业领域比 PostgreSQL 干的更漂亮：但没有一个其他数据库能够与所有扩展加持下的 PostgreSQL 比拼综合实力，包括 Oracle：是的，开源免费本身也是一种实力！

在一个相当可观的规模内，PostgreSQL 都可以独立扮演多面手的角色，一个数据库当多种组件使。更美妙的是，这些扩展的能力可以融合在一起，发挥 1+1 远大于 2 的效果来。单一数据组件选型可以极大地削减项目额外复杂度，节省大量成本与开发时间。如果真有那么一样技术可以满足你的各种数据需求，那么使用它就是最佳选择，而不是试图用多个组件来重新实现它。

而 Pigsty 的愿景，就是凝聚这些 PostgreSQL 生态的合力，并让所有这些能力，都对用户唾手可及。当然，那就是另一篇要说的故事了。

图片

发布版本：微信公众号

36 - 如何用Pigsty监控现有PostgreSQL (RDS/PolarDB/自建)？

原文发布于 VONNG。

Pigsty 是一个开箱即用的 PostgreSQL 发行版，与本地优先的 RDS 开源替代。但它也可以单独作为一个 PostgreSQL/主机监控系统来使用。本文以阿里云为例，介绍了用一台 ECS 安装部署 Pigsty，并用于监控云上的 PolarDB 与 RDS for PostgreSQL，为现有数据库带来极致的观测能力。

嵌入媒体

快速上手

使用 Pigsty 教程分为四个步骤：

1.申请用于部署 Pigsty 的 ECS 服务器 2.在 ECS 服务器上完整单机安装 Pigsty3.配置 PolarDB / RDS 的监控用户、模式、视图、黑白名单 4.将 RDS / PolarDB for PG 接入 Pigsty 监控系统中

只要您有阿里云账号，使用按量付费模式（需要账户余额¥100 以上），费用大致为 ¥4 / 小时，一小时内收工。

Why Pigsty

在讲 How 之前先说 Why。为什么要用一个额外的监控系统来做这件事？难道各家云厂商不是已经提供 RDS 监控了吗？没有错，只不过各家云厂商的 RDS PostgreSQL 的监控实在太简单了：这种程度的监控，对于回答数据库活着还是死了这件事也许足够了，但对于稍微高级一丁点儿的管理工作：性能优化，故障诊断都无能为力。

图片图片

Pigsty 的监控系统便是为了解决这个问题而生的。Pigsty 提供了基于开源的 Grafana / Prometheus 现代可观测性技术栈做监控的最佳实践。整套系统同样被设计为一键拉起，开箱即用的 INFRA 模块。Pigsty 所管理的任何组件都会被自动纳入监控之中，包括主机节点，负载均衡 HAProxy，数据库 Postgres，连接池 Pgbouncer，元数据库 ETCD，KV 缓存 Redis，对象存储 MinIO，……，以及整套监控基础设施本身。大量的 Grafana 监控面板与预置告警规则会让你的系统观测能力有质的提升。

图片

Pigsty 提供的监控面板概览\

无论是故障分析还是慢查询优化、无论是水位评估还是资源规划，Pigsty 为您提供全面的数据支撑，真正做到数据驱动。在 Pigsty 中，超过三千类监控指标被用于描述整个系统的方方面面，并被进一步加工、聚合、处理、分析、提炼并以符合直觉的可视化模式呈现在您的面前。从全局大盘总览，到某个数据库实例中单个对象（表，索引，函数）的增删改查详情都能一览无余。您可以随意上卷下钻横向跳转，浏览系统现状与历史趋势，并预测未来的演变。

图片

对于现有的 PostgreSQL 数据库特别是 RDS 云数据库来说，虽然 Pigsty 拿不到主机监控数据，也没有高可用/连接池等组件的监控数据，也缺少原生的数据库日志。但能利用好 PostgreSQL 本身的监控指标，已经有着足够强大的力量了。

您可以查阅公开 Demo：https://demo.pigsty.cc 来了解 Pigsty 监控系统提供的能力。

使用 Terraform 申请 ECS 服务器

单机安装 Pigsty 需要一台 x86_64 ECS 云服务器，EL 7-9 操作系统（建议使用 Rocky 8.6/9.1），规格最小 1C2G。您可以直接在控制台上申请资源，或者使用 Pigsty 提供的 Terraform 模板一键完成资源申请与置备。默认配置会使用固定的 10.10.10.10 IP 地址与密码 PigstyDemo4，并分配一个公网 IP 以供访问。

图片图片

在 ECS 上完整安装单机版 Pigsty

登陆 ECS 后，可以通过以下命令完成 Pigsty 的单机安装

bash -c "$(curl -fsSL https://get.pigsty.cc/latest)"   # 下载 Pigsty
cd ~/pigsty; ./bootstrap;                              # 提示下载离线软件包
./configure                                            # 配置 Pigsty
vi pigsty.yml  # 定制一些配置，比如修改各种密码
./install.yml  # 完成完整的单机安装，使用离线包完整安装约10分钟

Pigsty 的详细安装过程请参阅安装文档，整个过程耗时约十几分钟。

安装完成后，您可以通过 ECS 公网 IP 地址上的 3000 端口访问监控系统 Grafana，监控界面中会显示出完整的自我监控。例如本例中：http://59.110.161.154:3000/，默认用户名和密码为 admin / pigsty。

图片

我们建议您使用域名/https 访问 Pigsty 的 Web 界面，注意在生产环境使用时，我们强烈建议您修改默认密码，并谨慎对公网暴露界面。

图片

配置 PolarDB / RDS PG 监控

PolarDB 的配置细节在此不再赘述，关键是要有一个给监控用户使用的连接串，可以从 ECS 上访问 PolarDB 主库 / 从库，并确保相关监控用户具有足够的读取权限，以及相关监控扩展已经完成安装。

  • 创建集群，确保 PolarDB 与 ECS 在同一个可用区/子网内，可以从 ECS 访问 PolarDB。
  • 创建集群账号：管理用户 dbuser_dba，高权限账号，用来对集群进行进一步的配置。
  • 添加集群访问白名单：将 ECS 内网 IP 地址 10.10.10.10 添加到集群白名单中。
  • 创建一个业务数据库，这里以 test 为例。

配置好数据库集群的账号、白名单、数据库之后，使用高权限管理用户连接至新创建的数据库

$ psql postgres://dbuser_dba:[email protected]:1921/postgres

使用高权限用户创建专用监控用户，当然您也可以在控制台创建。

图片

强烈建议安装 pg_stat_statements 扩展，它可以提供非常重要的关于查询的

将现有 PG 数据库接入监控

为了将 RDS for PostgreSQL 实例与 PolarDB 实例纳入监控，您需要将这些目标实例的身份信息与连接信息告诉 Pigsty。编辑 pigsty.yml 配置文件，在 all.children.infra.vars.pg_exporters 定义这些待监控的远程数据库实例，这是一个字典，Key 为唯一分配的本地监控组件端口号，Value 为目标实例的配置信息。

图片

这里，我们接入了一个一主一从的 PolarDB 集群，并将其命名为 pg-polar，一个基础版（单节点）的 RDS for PostgreSQL 实例并命名为 pg-rds，以及一个高可用版本并带有一个只读节点的 RDS 集群 pg-rdsha。其配置如下所示，并不是所有参数都是必须的，通常来说，只有 pg_cluster，pg_seq，与 pg_host （pg_port，如果不是 5432） 是需要修改的，其他参数可以按需指定覆盖。

定义好这些配置选项后，您可以使用以下命令，将其纳入到 Pigsty 的监控系统中：

    bin/pgmon-add pg-polar
    bin/pgmon-add pg-rds
    bin/pgmon-add pg-rdsha

然后，您就可以在 Pigsty 监控系统中看到这三个新集群了。

图片

点击浅灰蓝色的集群名/实例名，即可跳转到对应集群/实例 PGRDS 监控面板上：

图片图片

点击浅灰蓝色的集群名/实例名，即可跳转到对应集群/实例 PGRDS 监控面板上：

首屏包含了最为关键的信息，集群实例成员，存活状态，数据库列表与导航，13 个核心监控指标。点击都可以展开更详细的信息。\

图片

在 PGRDS Cluster 与 PGRDS Instance 之间，可以方便地在图表元素上点击跳转，快速上卷下钻。

图片

同时，您依然可以复用 Overview / Database 层次的所有监控面板，查阅数据库内部的详细细节，比如每一类查询的 QPS / RT，或者每个表上的增删改查：

图片图片图片图片

Pigsty 的监控系统还允许您直接访问数据库的 Catalog （可选），从系统视图中查阅统计数据。例如锁等待 / TopSQL 等。

图片图片

更多监控系统的细节就不在此展开了，欢迎访问 Pigsty 文档或 Demo 在线体验。点击“查看原文”可访问 Bilibili 视频版教程。

如果您对 Pigsty 与 PostgreSQL 感兴趣，也欢迎微信搜索 pigsty-cc 添加 Pigsty 小助手，加入 PGSQL x Pigsty 交流群中。

发布版本：微信公众号

37 - Pigsty v2.4：监控云数据库

原文发布于 VONNG。

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

PostgreSQL 今天发布了新的大版本 16，带来了一系列改进。Pigsty在发布后的1小时内便立即跟进了全新版本 Pigsty v2.4 ，提供了对 PostgreSQL 16 正式版的完整支持。此外在 v2.4 中，还对监控已有PG实例，特别是 RDS for PostgreSQL 与 PolarDB 提供了额外的支持。Redis 监控基于 7.x 进行了改进，提供了自动化的基于 Sentinel 的高可用配置。

Pigsty v2.4 目前仍为 Beta 状态，可以使用以下命令快速上手。文档修缮完成后，将正式发布。

bash -c "$(curl -fsSL https://get.pigsty.cc/beta)"

图片

亮点特性

•PostgreSQL 16 正式发布，Pigsty在发布后1小时内提供支持。•可以监控云数据库，RDS for PostgreSQL，以及 PolarDB，提供全新的 PGRDS 监控面板•正式提供 商业支持与咨询服务。并发布首个 LTS 版本，为订阅客户提供最长5年的支持。•新扩展插件: Apache AGE ，在 PostgreSQL 上提供图数据库查询能力•新扩展插件: zhparser，中文分词，用于支持中文全文检索功能•新扩展插件: pg_roaringbitmap，高效实现 RoaringBitmap 位图功能•新扩展插件: pg_embedding，另一种基于 HNSW 索引的向量数据库插件hnsw alternative to pgvector•新扩展插件: pg_tle，由 AWS 出品的可信语言存储过程管理/发布/打包扩展•新扩展插件: pgsql-http，在数据库中使用 SQL 接口直接发送HTTP请求处理响应。•其他新增插件：pg_auth_mon，pg_checksums，pg_failover_slots，pg_readonly，postgresql-unit pg_store_plans，pg_uuidv7，set_user•Redis改进：支持 Redis 哨兵监控，配置主从集群的自动高可用。

API变化

•新增参数，REDIS.redis_sentinel_monitor，用于指定 Sentinel 集群监控的主库列表

PG16支持

Pigsty 也许是最早提供 PostgreSQL 16 支持的发行版，从 16 beta1 就开始，因此当 PostgreSQL 16 发布后一个小时，Pigsty 即完成了对正式版本的支持。你已经可以拉起 PostgreSQL 16 的高可用集群，尽管有个别重要扩展还没有在官方的 PGDG 仓库提供，例如 Citus 与 TimescaleDB。但其他一些扩展已经可用：包括 postgis34，pgvector， pg_squeeze，wal2json，pg_cron，以及由 Pigsty 所维护打包的扩展插件：zhparser，roaringbitmap，pg_embedding， pgsql-http 等。

PostgreSQL 16 有一些比较实用的新功能：从库逻辑解码与逻辑复制，针对I/O的新统计视图，全连接的并行执行，更好的冻结性能，符合 SQL/JSON 标准的新函数集，以及在HBA认证中使用正则表达式等等。

不过要注意的是，PGDG 官方仓库目前决定在 PostgreSQL 16 中放弃对 EL7 的支持，所以 PG16 仅在 EL8 与 EL9 及其兼容操作系统发行版中可用。

监控RDS与PolarDB

Pigsty v2.4 提供了对 RDS 监控的支持。特别是还添加了对 PolarDB 云数据库的监控支持。当您只有一个远程 PostgreSQL 连接串时，可以使用这种方式将其纳入 Pigsty 监控。

图片

样例：监控一个一主一从的 PolarDB RDS 集群

Pigsty v2.4 提供了对 RDS 监控的支持。特别是还添加了对 PolarDB 云数据库的监控支持。当您只有一个远程 PostgreSQL 连接串时，可以使用这种方式将其纳入 Pigsty 监控中。Pigsty 提供了两个全新 Dashboard：PGRDS Cluster 与 PGINS Cluster，用于呈现 RDS PG 的完整指标。

图片图片图片

商业支持

Pigsty v2.4 是第一个 LTS 版本，将为企业订阅用户提供3年的长时间支持。同时，我们将正式开始对外提供订阅与支持服务，欢迎有需求的用户联系我们采购。

https://pigsty.cc/zh/docs/support/

图片

REDIS高可用

Pigsty v2.4 中，我们提供了一个新的参数 redis_sentinel_monitor ，用于自动配置经典主从 Redis 集群的高可用。该参数只能在 Sentinel 集群上定义，定义中的主库将会自动被哨兵集群所纳管

图片

与此同时，我们也在 Redis 监控中添加了 Sentinel 相关指标与面板，并针对 Redis 7.x 的新特性进行了适配。

新扩展

Pigsty v2.4 提供了一系列的新扩展插件，包括尚未收录在 PGDG 官方仓库中的重要扩展。例如，图数据库插件 Apache AGE，中文分词全文检索插件 zhparser，HTTP插件pgsql-http，可信扩展打包插件 pg_tle ，位图插件 pg_roaringbitmap，以及向量数据库插件 PGVector 的另一种替代实现 pg_embedding ，等等等等。

所有插件都在 EL7 - EL9 上针对 PostgreSQL 12 至 PostgreSQL 16 进行编译打包，不过 EL7 因为编译器版本问题，尚未支持 pg_tle 与 pg_embedding 。这些 RPM 包将由 Pigsty 维护，并放置于 Pigsty 自己的 Yum 源中。

图片

例如，您可以使用 AGE 为 PostgreSQL 加装图数据库能力，创建 Graph，并使用 Cypher 查询语言与 SQL 语言一起探索图数据，实现 Neo4j 的效果。

图片

再比如，您可以使用 zhparser 中文分词插件，将中文文本与查询拆分为关键词，使用 PostgreSQL 经典的全文检索能力，实现搜索引擎与 ElasticSearch 的效果。

图片

更有甚者，你还可以使用 pgsql-http 插件，使用 SQL 接口来发送 HTTP 请求，处理 HTTP 响应。这让数据库可以与外部系统深度集成与交互，打开无尽的想象空间：

图片

您还可以使用 roaringbitmap ，使用极少的资源，高效地进行计数统计：

图片

具体细节就不在此展开了，后面我们会专门出一些文章，介绍这些强力扩展的使用方式。

欢迎大家使用 Pigsty 并提出反馈意见，加讨论群请微信搜索 Pigsty 小助手：pigsty-cc 。

v2.4.0

使用 bash -c "$(curl -fsSL https://get.pigsty.cc/latest)" 快速上手。

最新特性

  • PostgreSQL 16 正式发布，Pigsty提供支持。
  • 可以监控云数据库，RDS for PostgreSQL，以及 PolarDB，提供全新的 PGRDS 监控面板
  • 正式提供商业支持与咨询服务。并发布首个 LTS 版本，为订阅客户提供最长5年的支持。
  • 新扩展插件: Apache AGE, openCypher graph query engine on PostgreSQL
  • 新扩展插件: zhparser, full text search for Chinese language
  • 新扩展插件: pg_roaringbitmap, roaring bitmap for PostgreSQL
  • 新扩展插件: pg_embedding, hnsw alternative to pgvector
  • 新扩展插件: pg_tle, admin / manage stored procedure extensions
  • 新扩展插件: pgsql-http, issue http request with SQL interface
  • 新增插件： pg_auth_mon pg_checksums pg_failover_slots pg_readonly postgresql-unit pg_store_plans pg_uuidv7 set_user
  • Redis改进：支持 Redis 哨兵监控，配置主从集群的自动高可用。

API变化

  • 新增参数，REDIS.redis_sentinel_monitor，用于指定 Sentinel 集群监控的主库列表

问题修复

  • 修复 Grafana 10.1 注册数据源时缺少 uid 的问题
MD5 (pigsty-pkg-v2.4.0.el7.x86_64.tgz) = 257443e3c171439914cbfad8e9f72b17
MD5 (pigsty-pkg-v2.4.0.el8.x86_64.tgz) = 41ad8007ffbfe7d5e8ba5c4b51ff2adc
MD5 (pigsty-pkg-v2.4.0.el9.x86_64.tgz) = 9a950aed77a6df90b0265a6fa6029250

38 - Pigsty v2.3：丰富应用生态

原文发布于 VONNG。

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

Pigsty v2.3 发布了 🎉，在这个版本中进一步完善了监控系统、应用生态、并跟进 PostgreSQL 例行的小版本更新（CVE修复）。

Pigsty v2.3 跟随 PostgreSQL 主干小版本进行更新，包括 15.4, 14.9, 13.12, 12.16 以及 16.beta3，此更新修复了一个 CVE 安全漏洞。此外高可用管控 Patroni 也升级到 3.1 版本，解决了一些 BUG 。

v2.3 提供了对 FerretDB 的支持，它是一个构建在 PostgreSQL 之上，真正开源的 MongoDB 替代。用户可以使用 MongoDB 客户端访问它，但是真正的数据都存储在底层的 PostgreSQL 里。

v2.3 还默认添加了一款名为 NocoDB 的开源应用：这是 AirTable 的开源替代：这是一个数据库-电子表格的混合体，可以用低代码的方式快速打造一个多人在线协作应用。

Pigsty v2.3 新增了为主机节点集群绑定一个 L2 VIP 的功能，使用 VRRP 协议确保全链路上没有单点，并提供了完整的监控：keepalived_exporter 被用于收集监控数据。而且每一个 Node VIP （keepalived）与 PGSQL VIP （vip-manager）都会添加到 blackbox_exporter 的 ICMP / PING 监控列表中。

在监控系统上，Pigsty v2.3 在 v2.2 的基础上进行了打磨优化：新增了 VIP 监控，VIP 与节点 PING 指标被加入到 NODE / PGSQL 监控的醒目位置；PGSQL 监控新增了锁等待树视图；REDIS 监控进行了风格优化；MinIO 监控适配的新的监控指标名称；MySQL / MongoDB 监控新增了实现存根，为后续实现奠定基础。

顺带一提，PGSQL x Pigsty 交流群新开3群了，对 PostgreSQL 与 Pigsty 感兴趣的朋友可以直接扫码加入（仅限前200人），如果加入不了请微信搜索 pigsty-cc 小助手加入。

MongoDB 支持？

MongoDB 是一个很受欢迎的 NoSQL 文档数据库。但由于开源协议问题（SSPL），与软件定位问题（Postgres发型版），Pigsty 决定使用 FerretDB 来提供对 MongoDB 的支持。FerretDB 是一个有趣的开源项目：它让 PostgreSQL 可以提供 MongoDB 的能力。

ferretdb

MongoDB 与 PostgreSQL 是两个非常不同的数据库系统：MongoDB 使用文档模型，使用专用的查询语言进行交互 。但是鉴于 PostgreSQL 也提供了完整的 JSON/JSONB/GIN 功能支持，所以这么做在理论上也是完全可行的：FerretDB 负责将您的 SON 查询转换为 SQL 查询：

use test-- CREATE SCHEMA test;
db.dropDatabase()-- DROP DATABASE test;
db.createCollection('posts')-- CREATE TABLE posts(_data JSONB,...)
db.posts.insert({title: 'Post One',body: 'Body of post one',category: 'News',tags: ['news', 'events'],user: {name: 'John Doe',status: 'author'},date: Date()})-- INSERT INTO posts VALUES(...);
db.posts.find().limit(2).pretty()-- SELECT * FROM posts LIMIT 2;
db.posts.createIndex({ title: 1 })-- CREATE INDEX ON posts(_data->>'title');

在 Pigsty 定义一个 FerretDB 集群与其他类型的数据库并无二致，您仅需要提供核心的身份参数：集群名称与实例号。需要关注的是 mongo_pgurl 参数，它指定了 FerretDB 底层使用的 PostgreSQL 地址。

ferret:  hosts:    10.10.10.45: { mongo_seq: 1 }    10.10.10.46: { mongo_seq: 2 }    10.10.10.47: { mongo_seq: 3 }  vars:    mongo_cluster: ferret    mongo_pgurl: 'postgres://test:[email protected]:5436/test'

您可以直接填入一个已由 Pigsty 创建的任意 PostgreSQL 服务地址。数据库不需要预先配置什么，你只需要确保所使用的用户具有 DDL 权限即可。

ferretdb-monitoring

配置完成后，使用 ./mongo.yml -l ferret 即可完成安装。当然，如果您更喜欢使用容器，也可以直接 cd pigsty/app/ferretdb; make 使用 docker-compose 拉起 FerretDB 使用。安装完成后，您可以使用任何 MongoDB Client 访问 FerretDB，例如 MongoSH：

mongosh 'mongodb://test:[email protected]:27017/test?authMechanism=PLAIN'

对于那些希望从 MongoDB 迁移到 PostgreSQL 的用户来说，这是一种改造成本极小的折衷手段。Pigsty 同样提供了另一种支持方式 MongoFDW：在 PostgreSQL 中使用 SQL 查询现有的 MongoDB 集群。

新应用：NocoDB

在 Pigsty v2.3 中，添加了对 NocoDB 的内置支持，您可以使用默认的 Docker Compose 模板，一键拉起 NocoDB 并使用内置的 PostgreSQL 作为存储。

NocoDB 是 Airtable 的开源替代品，那 AirTable 又是什么呢？其实有点类似于 Google Docs / 腾讯云文档。但是提供了非常丰富的接口，钩子，可以用来实现一些非常强大的功能。

nocodb

NocoDB 可以让各种关系型数据库变身成为 Excel ，运行你自己的本地云文档软件。它也可以让用户用低代码的方式实现一些需求：比如你可以把自动生成的表单发送给别人填写，将结果自动整理成为实时共享、可协作、可编程的多维表格。

在 Pigsty 中，拉起 NocoDB 非常容易，只需要一行命令即可。您可以修改 .env 中的 DATABASE_URL 参数来使用不同的数据库。

cd ~/pigsty/app/nocodb; make up

Node VIP 支持

Pigsty v2.3 新增了为主机节点集群绑定一个 L2 VIP 的功能，使用 VRRP 协议确保全链路上没有单点，并提供了完整的监控。

在古早的 Pigsty 版本中（0.5前），曾经提供过基于 Keepalived 的 L2 VIP 功能实现。但随后被 HAProxy + VIP-Manager 所取代：HAProxy 不挑网络，可以进行灵活的健康检查、流量分发，更是提供了一个简单易用的管控界面。而 VIP Manager 则可以将一个 L2 VIP 绑定在数据库集群主库上。

但通用的 L2 VIP 需求仍然是存在的，例如，如果用户选择使用 HAProxy 集群接入，那么 HAProxy 本身的可靠性如何保证？尽管您可以使用 DNS LB 的方式进行切换，但 VRRP 在可靠性与易用性上显然更胜一筹。此外，MinIO / ETCD ，Prometheus 这些组件，有时也会有这样的需求。

想要为集群绑定一个 L2 VIP 其实很简单，只需要启用 vip_enabled，分配一个 VLAN 中唯一的 VirtualRouterID 号与 VIP 地址就可以了。默认情况下，所有集群成员使用 BACKUP 初始状态以非抢占模式工作。你可以通过设置 vip_role 与 vip_preempt 来改变这一行为。

vip-config

L2 VIP 会自动被纳入监控中。当 MASTER 宕机后， BACKUP 会立即进行接管。

vip-failover

监控系统改进

Pigsty v2.2 基于 Grafana 10 对监控系统进行了彻底的翻新重制。v2.3 在 v2.2 的基础上进行了更多优化。

例如，新增的 NODE VIP 监控面板用于展示一个 VIP 的状态：所属集群/成员，网络RT，KA的状态等等等等。

node-vip-dashboard

上图展示了一个 L2 VIP 自动故障转移的现场监控：绑定在 3 节点集群 MinIO 上。当原本的 Master （.27）宕机后，（.26）立即完成接管。

同样的信息也被展示在 NODE 与 PGSQL 监控面板的关键位置：例如，Overview 的实例列表中，现在就会添加 VIP 的快速导航（紫色）：

node-overviewpgsql-overview

同理，在 NODE Cluster 与 PGSQL Cluster 中也会在醒目处列出 VIP 与所有成员的 ICMP 可达性状态（Ping 网络延迟）。

node-cluster-pingpgsql-cluster-ping

此外，在 PGCAT 中新增了默认 1s 刷新的 PGCAT Locks 监控面板，可以直观的观察数据库当前活跃的情况，以及锁等待的情况。

pgcat-locks

锁等待会组织成一棵等待树，用 Level 与缩进标识层次。您可以选择不同的刷新率，最快每秒 10 次。

图片

在 REDIS 监控上，相关的监控面板也统一按照 PGSQL 与 NODE 的风格进行适配与调整：

redis-monitoring

更丝滑的构建流程

Pigsty v2.2 提供了官方 Yum 源，在 v2.3 中则默认启用了全站 HTTPS。所有

当您选择直接从互联网下载 Pigsty 所需的软件时，可能会遭遇到功夫网的烦恼。例如，默认的 Grafana / Prometheus Yum 源下载速度极慢。除此之外，还有一些零散的 RPM 包需要通过 Web URL 的方式，而不是 repotrack RPM 的方式进行下载。

在 Pigsty v2.2 中，解决了这个问题。Pigsty 提供了一个官方的 yum 源：http://get.pigsty.cc ，并配置为默认的上游源之一。所有零散的 RPM，需要翻墙的 RPM 都放置其中，可以有效加快在线安装/构建速度。

此外， Pigsty 还在 v2.2 中提供了对信创操作系统，统信 UOS 1050e uel20 的支持，满足一些特殊客户的特殊需求。Pigsty 针对这些系统重新编译了 PG相关的 RPM 包，为有需求的客户提供支持。

安装

Pigsty v2.3 的安装命令为：

bash -c “$(curl -fsSL https://get.pigsty.cc/latest)"

一行命令，即可在全新机器上完整安装 Pigsty. 如果您想要尝鲜 beta 版本，将 latest 换为 beta 即可。对于没有互联网访问的特殊环境，您也可以使用以下链接下载 Pigsty，以及打包了所有软件的离线安装包：

download

https://get.pigsty.cc/v2.3.0/pigsty-v2.3.0.tgz https://get.pigsty.cc/v2.3.0/pigsty-pkg-v2.3.0.el7.x86_64.tgz https://get.pigsty.cc/v2.3.0/pigsty-pkg-v2.3.0.el8.x86_64.tgz https://get.pigsty.cc/v2.3.0/pigsty-pkg-v2.3.0.el9.x86_64.tgz

以上，就是 Pigsty v2.3 带来的变化。

更多细节，请参考 Pigsty 官方文档：https://vonng.github.io/pigsty/ 与 Github Release Note： https://github.com/Vonng/pigsty/releases/tag/v2.3.0

v2.3.0

相关文章：《Pigsty v2.3 发布：应用生态丰富》

发布注记：https://github.com/Vonng/pigsty/releases/tag/v2.3.0

使用 bash -c "$(curl -fsSL https://get.pigsty.cc/latest)" 快速开始。

亮点特性

  • INFRA: 添加了对 NODE/PGSQL VIP 的监控支持
  • PGSQL: 通过小版本升级修复了 PostgreSQL CVE-2023-39417： 15.4, 14.9, 13.12, 12.16，以及 Patroni v3.1.0
  • NODE: 允许用户使用 keepalived 为一个节点集群绑定 L2 VIP
  • REPO: Pigsty 专用 yum 源优化精简，全站默认使用 HTTPS： get.pigsty.cc 与 demo.pigsty.cc
  • APP: 升级 app/bytebase 版本至 v2.6.0， app/ferretdb 版本至 v1.8；添加新的应用模板：nocodb，开源的 Airtable。
  • REDIS: 升级版本至 v7.2，并重制了 Redis 监控面板。
  • MONGO: 添加基于 FerretDB 1.8 实现的基本支持。
  • MYSQL: 添加了 Prometheus / Grafana / CA 中的代码存根，便于后续纳管。

API变化

新增一个新的参数组 NODE.NODE_VIP：包含 8 个新参数

  • NODE.VIP.vip_enabled：在此节点集群上启用 vip 吗？
  • NODE.VIP.vip_address：ipv4 格式的节点 vip 地址，如果启用了 vip，则必需
  • NODE.VIP.vip_vrid：必需，整数，1-255 在相同 VLAN 中应该是唯一的
  • NODE.VIP.vip_role：master/backup，默认为备份，用作初始角色
  • NODE.VIP.vip_preempt：可选，true/false，默认为 false，启用 vip 抢占
  • NODE.VIP.vip_interface：节点 vip 网络接口监听，eth0 默认
  • NODE.VIP.vip_dns_suffix：节点 vip dns 名称后缀，默认为 .vip
  • NODE.VIP.vip_exporter_port：keepalived 导出器监听端口，默认为 9650
MD5 (pigsty-pkg-v2.3.0.el7.x86_64.tgz) = 81db95f1c591008725175d280ad23615
MD5 (pigsty-pkg-v2.3.0.el8.x86_64.tgz) = 6f4d169b36f6ec4aa33bfd5901c9abbe
MD5 (pigsty-pkg-v2.3.0.el9.x86_64.tgz) = 4bc9ae920e7de6dd8988ca7ee681459d

v2.3.1

使用 bash -c "$(curl -fsSL https://get.pigsty.cc/latest)" 快速开始。

最新特性

  • pgvector 更新至 0.5，添加 hnsw 算法支持。
  • 支持 PostgreSQL 16 RC1 (el8/el9)
  • 默认包中添加了 SealOS 用于快速部署Kubernetes集群。

问题修复

  • 修复了 infra.repo.repo_pkg 任务：当 repo_packages 中包名包含 * 时，下载可能会受到 /www/pigsty 现有内容的影响。
  • 将 vip_dns_suffix 的默认值由 .vip 调整为空字符串，即集群本身的名称将默认作为节点集群的 L2 VIP
  • modprobe watchdog and chown watchdog if patroni_watchdog_mode is required
  • 当 pg_dbsu_sudo = limit and patroni_watchdog_mode = required 时，授予数据库 dbsu 以下命令的 sudo 执行权限
    • /usr/bin/sudo /sbin/modprobe softdog：在启动 Patroni 服务时确保 softdog 内核模块启用
    • /usr/bin/sudo /bin/chown {{ pg_dbsu }} /dev/watchdog: 在启动 Patroni 服务时，确保 watchdog 属主正确

文档更新

  • 向英文文档中添加了更新内容。
  • 添加了简体中文版本的内置文档，修复了 pigsty.cc 文档站的中文文档。

软件更新

  • PostgreSQL 16 RC1 for EL8/EL9
  • PGVector 0.5.0，支持 hnsw 索引
  • TimescaleDB 2.11.2
  • grafana 10.1.0
  • loki & promtail 2.8.4
  • redis-stack 7.2 on el7/8
  • mcli-20230829225506 / minio-20230829230735
  • ferretdb 1.9
  • sealos 4.3.3
  • pgbadger 1.12.2
ce69791eb622fa87c543096cdf11f970  pigsty-pkg-v2.3.1.el7.x86_64.tgz
495aba9d6d18ce1ebed6271e6c96b63a  pigsty-pkg-v2.3.1.el8.x86_64.tgz
38b45582cbc337ff363144980d0d7b64  pigsty-pkg-v2.3.1.el9.x86_64.tgz

39 - Pigsty v2.2：监控全面翻新

原文发布于 VONNG。

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

Pigsty v2.2 发布了 🎉，欢迎大家尝鲜！ 地表最强 PostgreSQL 监控系统迎来史诗级重大升级，基于 Grafana v10 彻底重制，将 PG 可观测性拔高到一个全新阶段，带来了全新的用户体验。Demo: http://demo.pigsty.cc 。

此外 Pigsty v2.2 还提供了一个 42 节点的生产仿真环境沙箱模板，支持了 Citus 12，PG 16beta2，提供了使用KVM虚拟机的vagrant模板，为零散/墙外RPM包提供了专用的 Pigsty Yum 源，并支持了国产信创操作系统统信UOS20。

欢迎大家试用尝鲜，提出反馈意见。加 PG x Pigsty 微信讨论群请搜 pigsty-cc 小助手。

另外：8月9号晚7点开源中国出品的直播 《 PostgreSQL vs MySQL》以及8月16号的DTCC 2023，我将代表 PG 一方出战与 MySQL 对喷：谁才是数据库一哥，欢迎大家收看。

监控系统重制：视觉配色

Pigsty v2.2 中，对监控面板进行了彻底的重制，充分利用 Grafana v10 的新特性，为用户带来耳目一新的可视化体验。

最直观的变化是色彩。Pigsty v2.2 采用了全新的配色方案.以 PGSQL Overview 面板为例，新配色方案降低了饱和度，整体视觉体验比旧版本更加协调美观。

图片

Pigsty v2.0 使用Grafana默认的高饱和配色

图片

Pigsty v2.2：失效实例标黑，点击可直达故障现场

在 Pigsty v2.2 的监控面板中使用了 PG蓝，Nginx绿，Redis红，Python黄，Grafana橙等颜色作为基准，这套配色方案的灵感来自这篇文章：SCI，但《天气之子》~当SCI论文插图遇上新海诚天气之子配色 https://zhuanlan.zhihu.com/p/619556088 。

color-scheme

监控系统重制：集群导航

当然除了配色，v2.2 也在内容编排和布局上重新进行了设计。例如，使用 Stats 色块统计替代了大量表格式导航，让有问题的服务能够在首屏即可一目了然。点击异常色块即可直达故障现场。

当然，老式的导航表格可以提供更丰富的信息，也并没有移除，而是移动到了专门的 Instances / Members 分栏中去。让我们以最常用的 PGSQL Cluster 面板为例：

图片

首屏是基于色块的图元导航，展现了集群组件存活状态与服务可用性，核心指标，负载水平与告警事件图。且提供了到集群内部资源 —— 实例，连接池，负载均衡器，服务，数据库的快速导航

图片

PGSQL Cluster 的表格式导航

具体的集群资源表，则是在第二栏中，以备查阅详情。配合后面的 指标栏与日志栏，完整的呈现了一个 PostgreSQL 数据库集群的核心状态。

图片

监控系统重制：实例

PGSQL Instance 展现了一个实例的详细状态，在 v2.2 中也进行了重制。最基本的设计原则就是：不是蓝/绿色的状态才需要关注。这样通过颜色视觉编码，用户可以在事故分析时快速定位一个数据库实例的故障根因。

图片

其他的实例，主机节点，ETCD，MinIO，Redis，也都使用了类似的设计，例如 Node Instance 的首屏就是这样的。

图片

Node Instance 的指标部分基本保持不变，但首屏概览部分进行了重制。MinIO Overview 亦然。

图片

Etcd Overview 则使用 State Timeline 来可视化 DCS 服务的可用性状态。例如下图展现了一个模拟 etcd 故障的现场：在一个5节点的 ETCD 集群中依次关闭各个实例，集群可以容忍两个节点故障，但3个节点故障将导致 ETCD 服务整体不可用（黄色的条转为暗蓝色，代表 ETCD 服务整体不可用）。

图片

当 DCS 出现故障时，依赖 ETCD 进行高可用的 PostgreSQL 集群默认会启用 FailSafeMode：在确认所有集群成员可达，不是自身而是DCS故障的前提下，可以避免出现主库降级的故障。而这一点，也会在 PG 的监控中体现出来

图片

监控系统重制：服务

另一个进行重新设计的部分是 Service 与 Proxy 。Service 面板现在添加了关于服务的重要信息：SLI ，通过条状的 Statetimeline，用户可以直观的看出服务中断情况，获取服务可用性指标，并理解负载均衡器与后端真实数据库服务器的状态。

图片

本例中，对 pg-test 集群的四个 HAProxy，分别进行了 排干，设置维护状态操作，然后关闭后端数据库服务器。只有当一个集群的全部实例都下线后， pg-test-replica 这个只读服务才会进入不可用状态。

图片

这是 pg-test 集群 1 号 HAProxy 负载均衡器的监控面板，每一个由其承载的服务都会列于其中，展示后端服务器状态并计算 SLI。HAProxy 本身的状态与监控放置在 Node Haproxy 监控面板中。

图片

在全局总览中，可以看到 Pigsty 中所有数据库服务的整体状态时间线与 SLI 指标。

监控系统重制：数据库统计

在 Pigsty 中，除了会对数据库服务器进行监控外，也会对数据库服务器所承载的逻辑对象 —— 数据库，表，查询，索引等逻辑。

PGSQL Databases 展示了集群层面的数据库统计指标。例如，在 pg-test 集群中有4个数据库实例，与一个数据库 test ，而这里就展示出了这4个实例数据库指标的水平对比。

图片

用户可以进一步下钻到 单个 数据库实例内部的统计，也就是 PGSQL Database 面板。这个面板提供了一些关于数据库与连接池的关键指标，但最重要的是，PGSQL Database 面板提供了对数据库内最活跃醒目的 表 与 查询 的索引 —— 这是两类最为重要的库内对象。

图片

用户可以进一步下钻到 单个 数据库实例内部的统计，也就是 PGSQL Database 面板。这个面板提供了一些关于数据库与连接池的关键指标，但最重要的是，PGSQL Database 面板提供了对数据库内最活跃醒目的 表 与 查询 的索引 —— 这是两类最为重要的库内对象。

图片图片

监控系统重制：系统目录

在 Pigsty 中，除了使用 pg exporter 采集到的指标数据之外，还会使用另外一类 可选 的重要补充数据 —— 系统目录。这也是 PGCAT 系列 Dashboard 所做的事情。PGCAT Instance 将直接访问数据库系统目录（使用最多8条监控只读连接），获取并呈现所需的信息。

例如，您可以获取数据库当前正在运行的活动，按照各种指标对数据库中的慢查询，无用索引，全表扫描进行定位与分析。查阅数据库的角色，会话，复制情况，配置修改状态，内存使用详情，备份与持久化的具体细节。

图片图片

如果说 PGCAT Instance 关注的是数据库服务器本身，那么 PGCAT Database 就更关注单个数据库内部的对象细节：例如 Schema，Table，Index，膨胀，Top SQL， Top Table，等等。

图片

每一个 Schema，Table ，Index 都可以点击下钻，进入更详细的专用面板中。例如 PGCAT Schema，就进一步展现了一个架构模式内的对象细节。

图片

数据库内的查询，也按照执行计划进行聚合，便于用户找到问题 SQL，快速定位慢查询问题。

图片

监控系统重制：表与查询

在 Pigsty 中，您可以查阅一张表的方方面面。PGCAT Table 面板可以让您查看表的元数据，上面的索引，每一列的统计信息，以及相关的查询。

图片

当然，您也可以使用 PGSQL Table 面板，从指标的维度，查阅一张表在任意历史时间段上的关键指标。点击表名即可轻松在两个视角进行切换。

图片

相应地，您也可以获取（具有相同执行计划）的同一类 SQL 的详细信息。

图片图片

在 Pigsty 中，还有许多关于特定主题的 Dashboard。限于篇幅，关于监控系统的介绍就是这些。最直观的体验方式，就是访问 Pigsty 提供的公开 Demo：http://demo.pigsty.cc ，亲自上手把玩一番。虽然这只是一个4台1C虚拟机的简陋环境，但用来展示Pigsty最基本的监控系统能力已经是足够了。

大号仿真环境

Pigsty 提供了一个基于 Vagrant 与 Virtualbox 的沙箱环境，可以跑在你的笔记本电脑/Mac上，有一个 1 节点的最小版本，和一个4节点的完整版本，用与演示与学习，而现在 v2.2 中又多了一个 42 节点的生产仿真版本沙箱。

生产沙箱的所有细节都由 prod.yml 这个五百行不到的配置文件描述，它可以轻松跑在一台普通的服务器物理机上，而拉起它过程与4节点并无二致：make prod install 即可完工。

图片

Pigsty v2.2 提供了基于 libvirt 的 Vagrantfile 模板，您只需要调整上面配置中的机器清单，即可一键创建出所需的虚拟机来。所有东西都可以轻松跑在一台 Dell R730 48C 256G 物理机上，二手价不到三千元。当然，您依然可以使用 Pigsty Terraform 模板一键在云厂商上拉起虚拟机。

安装完成后环境如下所示，包含两节点的监控基础设施，一主一备。5节点的专用 etcd 集群，3 节点的样例 MinIO 集群提供对象存储服务存放 PG 备份，还有一个两节点的专用 HAProxy 集群，可以统一为数据库服务提供负载均衡。

图片

在此之上，还有3套Redis数据库集群与10套规格各异的 PostgreSQL 数据库集群与，其中还包括一套开箱即用的 5 分片的 Citus 12 分布式 PostgreSQL 集群。

这个配置是中大型企业运行管理大规模数据库集群的参考样例，而您可以在单台物理服务器上用半个小时完整一键拉起。

更丝滑的构建流程

当您选择直接从互联网下载 Pigsty 所需的软件时，可能会遭遇到功夫网的烦恼。例如，默认的 Grafana / Prometheus Yum 源下载速度极慢。除此之外，还有一些零散的 RPM 包需要通过 Web URL 的方式，而不是 repotrack RPM 的方式进行下载。

在 Pigsty v2.2 中，解决了这个问题。Pigsty 提供了一个官方的 yum 源：http://get.pigsty.cc ，并配置为默认的上游源之一。所有零散的 RPM，需要翻墙的 RPM 都放置其中，可以有效加快在线安装/构建速度。

此外， Pigsty 还在 v2.2 中提供了对信创操作系统，统信 UOS 1050e uel20 的支持，满足一些特殊客户的特殊需求。Pigsty 针对这些系统重新编译了 PG相关的 RPM 包，为有需求的客户提供支持。

安装

从 v2.2 开始，Pigsty 的安装命令变为：

bash -c “$(curl -fsSL http://get.pigsty.cc/latest)"

一行命令，即可在全新机器上完整安装 Pigsty. 如果您想要尝鲜 beta 版本，将 latest 换为 beta 即可。对于没有互联网访问的特殊环境，您也可以使用以下链接下载 Pigsty，以及打包了所有软件的离线安装包：

http://get.pigsty.cc/v2.2.0/pigsty-v2.2.0.tgz
http://get.pigsty.cc/v2.2.0/pigsty-pkg-v2.2.0.el7.x86_64.tgz
http://get.pigsty.cc/v2.2.0/pigsty-pkg-v2.2.0.el8.x86_64.tgz
http://get.pigsty.cc/v2.2.0/pigsty-pkg-v2.2.0.el9.x86_64.tgz

以上，就是 Pigsty v2.2 带来的变化。

更多细节，请参考 Pigsty 官方文档：https://vonng.github.io/pigsty/ 与 Github Release Note： https://github.com/Vonng/pigsty/releases/tag/v2.2.0

v2.2.0

相关文章：《Pigsty v2.2 发布 —— 监控系统大升级》

发布注记：https://github.com/Vonng/pigsty/releases/tag/v2.2.0

快速开始： bash -c "$(curl -fsSL https://get.pigsty.cc/latest)"

亮点特性

  • 监控面板重做: https://demo.pigsty.cc
  • Vagrant沙箱重做: 支持 libvirt 与新的配置模板
  • Pigsty EL Yum 仓库: 统一收纳零碎 RPM，简化安装构建流程。
  • 操作系统兼容性: 新增信创操作系统 UOS-v20-1050e 支持
  • 新的配置模板：42 节点的生产仿真配置
  • 统一使用官方 PGDG citus 软件包（el7）

软件升级

  • PostgreSQL 16 beta2
  • Citus 12 / PostGIS 3.3.3 / TimescaleDB 2.11.1 / PGVector 0.44
  • patroni 3.0.4 / pgbackrest 2.47 / pgbouncer 1.20
  • grafana 10.0.3 / loki/promtail/logcli 2.8.3
  • etcd 3.5.9 / haproxy v2.8.1 / redis v7.0.12
  • minio 20230711212934 / mcli 20230711233044

Bug修复

  • 修复了 Docker 组权限的问题 [29434bd]https://github.com/Vonng/pigsty/commit/29434bdd39548d95d80a236de9099874ed564f9b
  • 将 infra 操作系统用户组作为额外的组，而不是首要用户组。
  • 修复了 Redis Sentinel Systemd 服务的自动启用状态 5c96feb
  • 放宽了 bootstrap & configure 的检查，特别是当 /etc/redhat-release 不存在的时候。
  • 升级到 Grafana 10，修复了 Grafana 9.x CVE-2023-1410
  • 在 CMDB pglog 模式中添加了 PG 14 - 16 的 command tags 与 错误代码。

API变化

新增1个变量

  • INFRA.NGINX.nginx_exporter_enabled: 现在用户可以通过设置这个参数来禁用 nginx_exporter 。

默认值变化:

  • repo_modules: node,pgsql,infra : redis 现在由 pigsty-el 仓库提供，不再需要 redis 模块。
  • repo_upstream:
    • 新增 pigsty-el: 与具体EL版本无关的RPM: 例如 grafana, minio, pg_exporter, 等等……
    • 新增 pigsty-misc: 与具体EL版本有关的RPM: 例如 redis, prometheus 全家桶，等等……
    • 移除 citus: 现在 PGDG 中有完整的 EL7 - EL9 citus 12 支持
    • 移除 remi: redis 现在由 pigsty-el 仓库提供，不再需要 redis 模块。
  • repo_packages:
    • ansible python3 python3-pip python3-requests python3.11-jmespath dnf-utils modulemd-tools # el7: python36-requests python36-idna yum-utils
    • grafana loki logcli promtail prometheus2 alertmanager karma pushgateway node_exporter blackbox_exporter nginx_exporter redis_exporter
    • redis etcd minio mcli haproxy vip-manager pg_exporter nginx createrepo_c sshpass chrony dnsmasq docker-ce docker-compose-plugin flamegraph
    • lz4 unzip bzip2 zlib yum pv jq git ncdu make patch bash lsof wget uuid tuned perf nvme-cli numactl grubby sysstat iotop htop rsync tcpdump
    • netcat socat ftp lrzsz net-tools ipvsadm bind-utils telnet audit ca-certificates openssl openssh-clients readline vim-minimal
    • postgresql13* wal2json_13* pg_repack_13* passwordcheck_cracklib_13* postgresql12* wal2json_12* pg_repack_12* passwordcheck_cracklib_12* postgresql16* timescaledb-tools
    • postgresql15 postgresql15* citus_15* pglogical_15* wal2json_15* pg_repack_15* pgvector_15* timescaledb-2-postgresql-15* postgis33_15* passwordcheck_cracklib_15* pg_cron_15*
    • postgresql14 postgresql14* citus_14* pglogical_14* wal2json_14* pg_repack_14* pgvector_14* timescaledb-2-postgresql-14* postgis33_14* passwordcheck_cracklib_14* pg_cron_14*
    • patroni patroni-etcd pgbouncer pgbadger pgbackrest pgloader pg_activity pg_partman_15 pg_permissions_15 pgaudit17_15 pgexportdoc_15 pgimportdoc_15 pg_statement_rollback_15*
    • orafce_15* mysqlcompat_15 mongo_fdw_15* tds_fdw_15* mysql_fdw_15 hdfs_fdw_15 sqlite_fdw_15 pgbouncer_fdw_15 multicorn2_15* powa_15* pg_stat_kcache_15* pg_stat_monitor_15* pg_qualstats_15 pg_track_settings_15 pg_wait_sampling_15 system_stats_15
    • plprofiler_15* plproxy_15 plsh_15* pldebugger_15 plpgsql_check_15* pgtt_15 pgq_15* pgsql_tweaks_15 count_distinct_15 hypopg_15 timestamp9_15* semver_15* prefix_15* rum_15 geoip_15 periods_15 ip4r_15 tdigest_15 hll_15 pgmp_15 extra_window_functions_15 topn_15
    • pg_background_15 e-maj_15 pg_catcheck_15 pg_prioritize_15 pgcopydb_15 pg_filedump_15 pgcryptokey_15 logerrors_15 pg_top_15 pg_comparator_15 pg_ivm_15* pgsodium_15* pgfincore_15* ddlx_15 credcheck_15 safeupdate_15 pg_squeeze_15* pg_fkpart_15 pg_jobmon_15
  • repo_url_packages:
  • node_default_packages:
    • lz4,unzip,bzip2,zlib,yum,pv,jq,git,ncdu,make,patch,bash,lsof,wget,uuid,tuned,nvme-cli,numactl,grubby,sysstat,iotop,htop,rsync,tcpdump
    • netcat,socat,ftp,lrzsz,net-tools,ipvsadm,bind-utils,telnet,audit,ca-certificates,openssl,readline,vim-minimal,node_exporter,etcd,haproxy,python3,python3-pip
  • infra_packages
    • grafana,loki,logcli,promtail,prometheus2,alertmanager,karma,pushgateway
    • node_exporter,blackbox_exporter,nginx_exporter,redis_exporter,pg_exporter
    • nginx,dnsmasq,ansible,postgresql15,redis,mcli,python3-requests
  • PGSERVICE in .pigsty 被移除了，取而代之的是 PGDATABASE=postgres，这用户只需 IP 地址就可以从管理节点访问特定实例。

目录结构变化:

  • bin/dns and bin/ssh 现在被移动到 vagrant/ 目录中。
MD5 (pigsty-pkg-v2.2.0.el7.x86_64.tgz) = 5fb6a449a234e36c0d895a35c76add3c
MD5 (pigsty-pkg-v2.2.0.el8.x86_64.tgz) = c7211730998d3b32671234e91f529fd0
MD5 (pigsty-pkg-v2.2.0.el9.x86_64.tgz) = 385432fe86ee0f8cbccbbc9454472fdd

40 - Pigsty v2.1：向量+PG全系支持！

原文发布于 VONNG。

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

随着 PostgreSQL 夏季小版本例行更新，与 16 Beta 的发布，Pigsty 也紧随PG社区发布了 v2.1 版本，这次更新支持了 16 Beta1 的高可用与新监控指标，也提供了 PG 12 - 15 版本的支持。同时，AI 向量扩展插件 PGVector 也于 2.0.2 正式进入 Pigsty 中并默认启用。

https://github.com/Vonng/pigsty/releases/tag/v2.1.0

向量数据库扩展 PGVector

最近向量数据库非常火爆，市面上有许多专用向量数据库产品，商业的有 Pinecone，Zilliz，开源的有 Milvus，Qdrant 等。在所有现有向量数据库中，pgvector 是一个独特的存在 —— 它选择了在现有的世界上最强大的开源关系型数据库 PostgreSQL 上以插件的形式添砖加瓦，而不是另起炉灶做成另一个专用的“数据库”。毕竟从零开始做好一个TP数据库还是非常难的。

pgvector 有着优雅简单易用的接口，不俗的性能表现，更是继承了PG生态的超能力集合。在以前，PGVECTOR 需要自行下载编译安装，所以我提了一个 Issue 把它加入到 PostgreSQL 全球开发组的官方仓库中。你只需要正常使用 PGDG 源即可直接 yum install pgvector_15 完成安装。在安装了 pgvector 的数据库实例中使用 CREATE EXTENSION vector 即可启用此扩展。

但是使用 Pigsty，你甚至都不需要这个过程。在3月底发布的 Pigsty v2.0.2 中，就已经默认集成并安装了 PGVector 扩展。你只需要 CREATE EXTENSION vector 即可开箱即用。PGVector 的使用方式，应用场景案例，工作原理，请参考本号前一篇文章：《AI大模型与向量数据库 PGVECTOR》。

同时透露一下，我们正在制作一个功能、性能、易用性更好的 PGVector 实现，将于后续版本纳入 Pigsty 中，敬请期待。

pgvector

PG16支持与可观测性

Pigsty 也许是最快提供 PostgreSQL 16 支持的发行版 —— 尽管目前仍然处于 Beta 状态，一些功能扩展仍然没有跟进，但你已经可以拉起 PostgreSQL 16 的高可用集群体验测试起来。PostgreSQL 16 有一些比较实用的新功能：从库逻辑解码与逻辑复制，针对I/O的新统计视图，全连接的并行执行，更好的冻结性能，符合 SQL/JSON 标准的新函数集，以及在HBA认证中使用正则表达式。

Pigsty 特别关注 PostgreSQL 16 中的可观测性改进，新的 pg_stat_io 视图，让用户可以直接从数据库内访问到重要的 I/O 统计指标，对于性能优化，故障分析具有非常重要的意义。在以前，用户只能在数据库/BGWriter上看到有限的统计指标，想要更精细的统计数据，只能关联操作系统层面的I/O指标进行分析。现在，你可以从后端进程类型/关系类型/操作类型三个维度，对读/写/追加/回刷/Fsync/命中/逐出等行为进行深入的洞察。

pg-stat-io

另外一个非常有价值的可观测性改进点是，pg_stat_all_tables 与 pg_stat_all_indexes 会记录最后一次顺序扫描 / 索引扫描的时间。尽管这个功能在 Pigsty 的监控系统中可以通过扫描统计图表实现，但官方提供直接的支持肯定更好：用户可以直观地得出一些结论：比如某一个索引是不是没用上可以考虑移除。此外，n_tup_newpage_upd 指标可以告诉我们表上有多少行在更新时不是在页内原地更新，而是移动到了一个新的页面上，这个指标对于优化 UPDATE 性能，调整表填充因子具有重要的参考价值。

PGSQL 12 - 15 支持

Pigsty 从 PostgreSQL 10 开始提供支持，但一直紧跟社区主干的最新版本。但用户确实会有使用旧版本的需求 —— 有的是外部组件最高就支持某个版本，有的是对最新的大版本有所顾虑希望谨慎升级，有的是因为想要从现有的低版本集群创建一个由 Pigsty 托管的 Standby Cluster 完成迁移。不管怎么样，对于较低版本的 PostgreSQL 支持是一个来自用户侧的真实需求。因此我们在 2.1 中，加入了 PG 12 -14 三个大版本的支持，并默认纳入离线软件包中。

每个大版本除了核心的软件包，也包括了相应版本的重要扩展插件：地理空间插件 PostGIS，时序数据库插件 TimescaleDB，分布式数据库插件 citus，向量数据库插件 PGVector，在线垃圾清理插件 pg_repack，CDC逻辑解码插件 wal2json 与 pglogical，定时任务插件 pg_cron，以及强制检查密码强度的插件 passwordcheck_cracklib ，确保每个大版本都可以享受到 PostgreSQL 生态的核心能力。

图片

PostgreSQL 11 其实也可以支持，但因为有一些扩展缺失，加之即将进入 EOL，所以就排除在本次更新中。对于新尝试 PostgreSQL 的用户，我们始终建议从最新的稳定大版本（目前为15）开始使用。如果您真的希望使用 10 或 11，也可以参照教程调整仓库中的软件包版本自行构建。

Grafana监控系统改进

随着 Grafana 版本升级至 v9.5.3 ， 全新的导航栏，面板布局让 Pigsty 的监控系统 UI 也随之焕然一新。所有监控面板都根据新 UI 的特性进行了微调与适配，一些不和谐的样式问题也得到了修正。

grafana-ui

在 Pigsty 2.1 中引入了4个来自 volkovlabs 的 Grafana 扩展插件。使用 Grafana + Echarts 进行数据可视化与分析一直是 Pigsty 所倡导和支持的一个功能亮点，奈何作者精力有限，难以在这个方向投入资源。

在 v2.1 发布前，我很高兴看到一个由专人维护的 Apache Echarts 面板插件 —— 终于可以松一口气，让自己维护的 echarts panel 退休了。有一个专业的创业团队选择这个方向进行拓展，并开发出一系列实用的扩展插件。可以使用后端数据渲染 SVG 与文本的动态文本插件，提供表单提交功能的 Form 插件，动态数据日历插件，等等等等。

volkovlabs

此外，Pigsty 还专门添加了 echarts-gl 的扩展资源，放置于 Grafana public/chart 目录下，允许用户使用 Pigsty 自带的 Grafana，无需互联网访问即可实现出 Apache Echarts 官方文档库中炫酷的三维地球等面板。

其他便利工具的改进

在 Pigsty 2.1 中，添加了 3 个便利命令，profile，validate，repo-add。

bin/validate 命令接受一个配置文件路径作为输入，它用来检查验证 Pigsty 配置文件的正确性。常见的问题，例如在不同集群里错误写入了同一个 IP，一些配置项的名称，类型错误，都可以自动检查抛出，更不用说最常见的YAML缩进格式错误了。用户修改配置之后，可以使用 bin/validate 确保自己的修改是有效合法的。

bin/repo-add 命令用于手工调整节点上的 YUM 仓库。当用户想要往本地软件仓库添加一些新的软件包时，经常需要使用 Ansible 剧本的子任务来进行管理，较为不便，现在您可以使用包装的命令行工具来完成这一点：比如，bin/repo-add infra node,pgsql 就会向 infra 分组的节点上添加分类为 node 与 pgsql 的软件源。

bin/profile 命令可以便捷地针对某个 IP 地址上特定 PID 的进程进行 perf 采样1分钟，并在 Pigsty Web服务器目录生成火焰图，用户可以直接从网页界面打开浏览，这个功能对于分析数据库内部的故障与性能瓶颈尤为有用。

v2.1.0

相关文章：Pigsty v2.1 发布：向量扩展 / PG12-16 支持

发布注记：https://github.com/Vonng/pigsty/releases/tag/v2.1.0

Highlight

  • PostgreSQL 16 beta 支持, 以及 12 ~ 15 的支持.
  • 为 PG 12 - 15 新增了 PGVector 扩展支持，用于存储 AI 嵌入。
  • 为 Grafana 添加了额外6个默认的扩展面板/数据源插件。
  • 添加 bin/profile 脚本用于执行远程 Profiling ，生成火焰图。
  • 添加 bin/validate 用于校验 pigsty.yml 配置文件合法性。
  • 添加 bin/repo-add 用于快速向节点添加 Yum 源定义。
  • PostgreSQL 16 可观测性：添加了 pg_stat_io 支持与相关监控面板

软件升级

  • PostgreSQL 15.3 , 14.8, 13.11, 12.15, 11.20, and 16 beta1
  • pgBackRest 2.46 / pgbouncer 1.19
  • Redis 7.0.11
  • Grafana v9.5.3
  • Loki / Promtail / Logcli 2.8.2
  • Prometheus 2.44
  • TimescaleDB 2.11.0
  • minio-20230518000536 / mcli-20230518165900
  • Bytebase v2.2.0

改进增强

  • 当添加本地用户的公钥时，所有的 id*.pub 都会被添加到远程机器上（例如椭圆曲线算法生成的密钥文件）

41 - 更好的开源RDS替代：Pigsty

原文发布于 VONNG。

引子：Why Pigsty

省却废话，直接抛出问题：我们需要更好的数据库内核，还是用好数据库内核的能力？哪项需求更为紧迫？哪一项才是更稀缺的能力？

现有内核，已经足够完美。

换皮魔改，大家多靠 PG；

再卷内核，没有边际效益。

来回折腾，多是无聊把戏。

图片

《为什么 PostgreSQL 是最成功的数据库？》

用户对于数据库的需求，和马斯洛的需求金字塔一样，有不同的层次。内核解决的是生理需求，然而很多更高层次的需求，是难以通过数据库内核 本身来解决的。

图片

《数据库用户需求金字塔》

解决这些需求，有两条主流道路：开源自建，或使用云数据库。自建类似于买车自己开，上云好比滴滴打出租。云数据库 太贵，好 DBA 难雇。租车省事，弹性十足，奈何定价离谱杀猪盘；买车自驾，体验更好，但想找到老司机，可要花不少功夫。

图片

《云数据库是不是杀猪盘》

有没有一种办法能扬长避短，结合两者的优点。让用户在即使缺少数据库专家支持的情况下，也能达到顶尖 DBA 自建八成的水平？既保留云的便利与弹性，又能用几乎接近于纯硬件成本的价格运行生产级数据库服务，省掉 50% ～ 90% 的 RDS 溢价？

女士们先生们，且看 Pigsty 2.0。

Postgres in Great STYle

—— 全盛状态的 PostgreSQL

图片

《Pigsty v2.0：更好的 RDS 开源替代》

Pigsty 曾经是一个开箱即用的 PG 数据库发行版，但现在，它旨在提供一个本地优先，功能完备，开源免费的 RDS 上位替代，帮助用户用好世界上最先进的开源关系型数据库 PostgreSQL。

Pigsty 源于我们自己的需求 —— 用好管好 PostgreSQL。但是，当我们说“用好”时，到底指的是什么呢？下面我们将从八个具体的维度来展开聊一聊。Pigsty 如何帮助用户满足这些需求。

兑卦：可扩展性

坐落在需求金字塔最底层的是生理需求，对数据库来说生理需求就是功能。可扩展性是 PostgreSQL 最大的王牌：PG 的功能可以通过插件的方式动态扩充，与时俱进。

图片

《PostgreSQL 好处都有啥》

PostgreSQL 是一个足够完美的数据库内核，但它需要更多工具与系统的配合，才能成为一个足够好的数据库服务，Pigsty 帮助 PG 完成这一步。

图片

Pigsty 是一个强力的数据库发行版，整合了 PG 生态中的各种组件与扩展：与外部数据源交互的 FDW，做变更数据捕获的 CDC，按需取用，玲琅满目。

特别是 PG 生态中最为强大的几个扩展插件，每一个都称得上是“独当一面”，拿出去随便包装一下，就可以当成一个全新的数据库，Pigsty 确保这些插件可以协同工作，提供一个开箱即用的分布式的时序地理空间向量数据库。

图片

您可以使用 PostGIS 处理地理空间数据，一行 SQL 解决 KNN 最近邻查询问题。

图片

您也可以使用 TimescaleDB 处理时序数据，自动压缩/滚动保留，并使用持续聚集来处理流式事件。

图片

您也可以使用 Citus 将单机主从 PG 集群原地扩展为分布式数据库，在不阻塞业务的情况下对分片进行重新均衡。

图片

您也可以使用 PGVector 存储 AI 模型的 Embedding，高效执行向量最近邻搜索，为 AI 添加持久记忆的功能。

图片

除了扩展，Pigsty 更是提供了运行企业级 RDS 服务的所需基础设施软件，所有组件均可在无需互联网访问的情况下，一键完成安装部署，生产可用。

图片

在 Pigsty 中功能组件被抽象 模块，可以自由组合以应对多变的需求场景。INFRA 模块带有完整的现代监控技术栈，而 NODE 模块则将节点调谐至指定状态并纳入监控。在多个节点上安装 PGSQL 模块会自动组建出一个基于主从复制的高可用数据库集群，而同样的 ETCD 模块则为数据库高可用提供共识与元数据存储。可选的 MINIO 模块可以用作图像视频等大文件存储并可选用为数据库备份仓库。与 PG 有着极佳相性的 REDIS 亦为 Pigsty 所支持。

你也可以开发自己的模块并自行扩展 Pigsty 的能力，更多的模块（如GPSQL, MYSQL, KAFKA，MONGO）将会在后续加入，

图片

Pigsty 还提供了可选的 Docker 模块与大量开箱即用的 Compose 模板。您可以使用 Pigsty 管理的高可用 PG 作为后端存储，以无状态的模式一键拉起这些软件。如果您的软件需要一个靠谱的 PG 数据库，Pigsty 也许是最简单的获取方案。

图片

更奇妙的是，您完全可以基于 Pigsty 内置的 Grafana 与 PG，Echarts，以低代码的方式，快速搭建起交互式的数据应用 Demo，并创造具有表现力的交互可视化作品。

图片

震卦：安全性

说完了功能可扩展性，让我们来聊一聊坐落在 RDS 需求金字塔第二层的需求 —— 安全。安全需求与生理需求同属基础需求，一个用于生产环境的严肃数据库系统至少应当满足这两类需求，才足以称得上是合格。

图片

很多土法自建的数据库都在这一需求层次里苦苦挣扎，而 Pigsty 可以帮您一步到位：加密备份一应俱全，只要硬件与密钥安全，您无需操心数据库的安全。

每套 Pigsty 部署都会创建一套自签名的 CA 用于签发证书，所有的网络通信都 可以使用 SSL 加密 防止抓包窃听，确保系统的机密性。

图片

针对 PG，Pigsty 提供了一套开箱即用的的访问控制体系，足以应对绝大多数应用场景下的安全需求。包括基本的职能分离 读/写/管理/ETL，以及配套的访问控制，确保默认配置便已 secure enough。

图片

针对软件缺陷或人为误操作造成的删表删库，Pigsty 提供了开箱即用的 PITR 时间点恢复能力，无需额外配置即默认启用。为完整性与可用性兜底！

图片

无论是备份还是时间点恢复，都简单到毫无门槛，一条命令搞定所有。如果您觉得本地目录/磁盘空间受限，亦可使用专用的 MinIO 集群或 S3 对象存储服务，保留任意长的回溯期限。

图片

PITR，ACL，SSL，确保您的数据安然无忧。

艮卦：可靠性

RDS 需求金字塔的第三层是：归属/社交需求。这意味着数据库不再是单打独斗的一个光杆司令，主库拥有了自己的追随者分担工作，并有高可用系统在故障时能让备库接管工作。

图片

Pigsty 让高可用与故障自愈成为 PG 的标配，基于 patroni，etcd，与 haproxy 打造的故障自愈架构，让您在面对硬件故障时游刃有余。在各行各业、大规模、长时间的生产运行，让这套架构的可靠性得到充分验证！

图片

Pigsty 可以通过自动故障切换来应对硬件故障，主库 Failover RTO 约为10 秒；一致性优先模式下，数据零损失 RPO = 0。这两个目标参数也可以根据您的实际情况进行调整与取舍。例如您觉得自己的网络质量非常好不会抖动，那么也完全可以将 RTO 设置为 1 秒钟。

图片

只要集群中有任意实例存活，PG 集群就可以对外提供完整的服务，而客户端只要连接至集群中的任意节点，即可访问完整的服务。经典主从数据库也能用出分布式数据库一样的体验。

图片

Pigsty 最大的部署案例是探探，有两万五千核的 PG 与 Redis 数据库，在三年间经历了数十次硬件故障与各类事故，但数据库依然可以长期保持 5 个 9 以上的可用性。此外，在军工航天、科研教学、金融电信、医疗互联网各行各业也有各种案例与应用

离卦：可维护性

图片

高可用架构把 PG 集群的可用性拔高到了一个全新高度，这也让数据库的维护不再痛苦。人生苦短，关爱运维，可维护性的需求，当然也归类为 爱与归属。\

Pigsty 非常在意用户的使用体验，谁是用户？各行各业的企业是我们的用户，但一线的 运维/研发/DBA，这些开发者才是 Pigsty 真正的用户。我们在可维护性上做了很多努力，打动用户靠的是实打实的产品能力

图片

正如前一节高可用中所述，Pigsty 在硬件故障时可以自动 Failover，让运维 DBA 能在晚上安心睡个好觉，第二天醒来再处理问题。当然 Pigsty 也可以主动进行 Switchover，主动切换 只有瞬间闪断；这将原本以分钟小时计的维护窗口，压低到秒级甚至亚秒级，为维护带来的极大便利。

Pigsty 可以监控现有 PG 实例，不论是 RDS 还是本地 PG；虽然纳管现有实例难度不低，但我们也自带迁移方案 无需业务停机，基于逻辑复制进行半自动迁移，流量切换甚至无需业务知悉。

图片

Pigsty 的安装更是极其简单，所有细节全靠一个配置清单。一条命令，就能在单机拉起，10 分钟不到即可生产 Ready。

此外 Pigsty 还有一个测试沙箱，用来开发演示或者研究学习。用 Vagrant + 虚拟机，一键在本地拉起。生产环境功能一模一样，配置最低只需要一 C 两 G。

图片

Pigsty 可以使用物理节点，也可以使用纯虚拟机。使用 Terraform，即可在云端一件拉起。使用样例配置文件，立刻就可以在阿里云/AWS 上一键拉起，部署所需的虚拟机，两分钟全部 Ready。

图片

Pigsty 为用户考虑到方方面面的管理细节，即便是新手对着 SOP，也能达到大师的六七成功力。

坎卦：可伸缩性

可靠与可维护性满足了 RDS 需求金字塔第三层 —— 爱与归属的需求。而金字塔的第四层则是尊重。对于数据库来说，安全可靠是本分，性能卓越才能出彩。

图片

Pigsty 确保 PG 的性能可以充分发挥，在相近硬件水平的 SYSBENCH 中，PG 性能表现冠绝群雄。

图片

《PostgreSQL 到底有多强？》

PGBENCH 单机点查 QPS 可达两百万，单机点写 QPS 可达七十万；性能怪兽，一台足矣。

图片

单机单卡轻松干到几十 TB。在现代 NVMe SSD 加持下，很多“分布式”数据库，都失去了存在意义。你可以通过无限拖从库的方式扩展只读能力，或使用内置 Citus 扩展，水平扩展主库的写入能力。

图片

Pigsty 原生支持连接池，Pgbouncer 优化，轻松应对海量并发。

图片

四种场景，提供预制参数模板；参数调优，自动根据机器规格进行；

图片

滚动升级，使用 Switchover 轻松实现硬件升降配，流量控制，使用 HAPROXY 对负载进行精细化管理。

图片

巽卦：ROI 性价比

性能很重要，但性价比才是第一产品力！再好的产品如果定价糊涂，也会体面尽失，一败涂地！

图片

云数据库就是最生动的案例，产品其实是不错的东西。尽管已经比 Oracle 这样的商业数据库便宜了一个数量级；但相比开源自建几倍到十几倍的离谱溢价，让上面的努力失去了大部分意义。

云算力贵吗？挺贵，比自建溢价几倍，但总体还说的过去。

图片

云存储贵吗？S3 对象存储不算太贵，但是，用来跑数据库的块存储，可以说价格突破天际！

图片

《块存储是不是杀猪盘？》

云数据库的定价模型工整的出奇，都是 EC2 价格乘以一个固定比例，当然云盘存储，通常单独计算处理。综上，云数据库相比开源自建，有着几倍到十几倍的溢价比例。

图片

以 64 核 512G 的机型为例，买一台用五年平均每年一万五，云上租一台每年几十万到一两百万，不到十几天的离谱租售比。

图片

任何理智的企业用户都看得明白这里面的道理：如果采购这种服务不是为了短期的，临时性的需求，那么绝对算得上是重大的财务失当行为。

Pigsty 可以立竿见影地帮助用户省钱，探探就是一个最直观的案例，规模 1 万 3 千核的 PG 数据库。这样的数量级，即使折扣拉满，阿里云数据库便宜点也要六七千万，如果使用使用 AWS RDS 大概两三亿。使用 Serverless WCU 计费更为离谱，能直接干到和 Oracle 一样的十亿数量级。

图片

但是用 Pigsty 开源自建。四个 DBA 含工资，每年一千万不到的成本，就能维护好两万五千核的数据库。Pigsty 可以帮助探探做到这一点，自然也可以帮助更多企业完成这个过程。

图片

如果用云服务器而不是 IDC 代维自建，使用 Pigsty 也能节省 RDS 和 ECS 中的差价，立竿见影节省一半成本起步，还是在不损失云的弹性前提下。

图片

乾卦：可观测性

可靠、可维护、可伸缩、性价比高的 RDS 服务，可以称得上是体面的数据库服务，而想要做到有品味，还需要可观测性与可控制性的加持。RDS 需求金字塔的第五层是认知需求。一个数据翔实的可观测系统能将数据库的治理水平拔高到一个全新高度。

图片

有些事情，是人有我优，人优我廉。但是对于可观测性来说，Pigsty 可以骄傲的说，这是人无我有。Pigsty 诞生的原因就是因为全世界都找不出一个能打的监控，所以我们才自己动手，正所谓甲方会武术，谁也挡不住。

图片

Pigsty 提供了基于开源的 Grafana / Prometheus 可观测性技术栈做监控的最佳实践：Prometheus 用于收集监控指标，Grafana 负责可视化呈现，Loki 用于日志收集与查询，Alertmanager 用于告警通知。PushGateway 用于批处理任务监控，Blackbox Exporter 负责检查服务可用性

图片

可以说，PostgreSQL 的可观测性数据全部被 Pigsty 收录囊中，总计 3000 多类的数据指标，将成为数字化，智能化的基础养料。更难得的是，这些指标数据会被加工、聚合、处理、分析、提炼、浓缩并以符合直觉的可视化模式呈现在您的面前。

图片

无论是故障分析还是慢查询优化、无论是水位评估还是资源规划，Pigsty 的监控系统为您提供全面的数据支撑，真正做到数据驱动。从全局大盘总揽，到某个数据库实例中单个对象（表，索引，函数）的增删改查详情都能一览无余。您可以随意上卷下钻横向跳转，浏览系统现状与历史趋势，并预测未来的演变。

图片

我们以 BI 的方式，从指标日志中提取洞察，构建上下文环境用于问题分析。我们提供了一个公开的 Demo 站点，展示此监控系统的能力， http://demo.pigsty.cc

图片图片图片图片

坤卦：可控制性

RDS 需求金字塔的第六层是审美需求。对于数据库来说，这意味着可观测性的对偶属性：可控制性。以一种优雅的方式进行控制与管理：Infrastrcuture as Code。

图片

Pigsty 将 IaC 拔高到新的高度，即 Database as Code。不像 RDS 还需要使用 Terraform 这样的工具来曲线救国，您可以用声明式的配置来管理部署各种组件。传统的运维方式关注过程，要创建/销毁/扩缩容数据库集群，用户需要按照手册依次执行各种命令；而现代管理方式关注状态，用户声明式的表达自己想要什么，而系统自动调整至用户所描述的状态。

图片

您可以使用 Terraform，声明式地管理基础 IaaS 资源；使用 Pigsty，声明式地管理 RDS 集群；可以使用内置的 Bytebase，声明式地去管理数据库内的对象。

图片

对真正有品位、有追求的工程师来说，在 GUI 鼠标点点是驴粪蛋表面光，如果您只有一两套数据库，也许 ClickOps并没有问题，但对于一个大规模生产环境的管理来说，IaC 才是最佳实践硬道理。像前文提到的高可用 3 节点数据库，只需要 10 行不到的描述。

图片

您可以用同样的方式完成 主从，集群，Sentinel 的 Redis 集群部署。

图片

您可以一键创建多节点的 ETCD 集群，为 PG 集群提供高可用的 DCS 服务

图片

也可以轻松部署分布式 MinIO 集群，作为可选的集中式数据库备份仓库

图片

5 节点 HA Citus 分布式数据库集群，配置依然非常简单。

图片

您也可以深度定制 DB 内容与业务用户，200+可深度定制的参数，足以满足最龟毛的 DBA 的定制服务。

尽管这里有这么多的配置参数，但你也无需感到恐慌打怵。部署一个单机数据库，只有 4 个必选身份参数。想要添加定时备份任务？一行 Crontab 定义，一条命令完成部署！

图片

想要扩容一台只读从库，添加一行配置就能满足。

图片

想要启用同步提交，没有复制延迟的从库，并对外暴露同步读取服务，也只需要一个参数。

图片

Pigsty 默认会使用 HAPROXY 分发流量，但你依然可以为集群绑定一个 VIP 避免 LB 单点。而这所需的也不过是 VIP 地址与网卡名参数。

图片

你还可以 Fork 现有集群，搭建异地灾备集群甚至延迟从库。一旦出现各种失误，你可以快速从延迟从库中恢复。如何创建延迟从库？三行配置，一个 UPstream 参数。

图片

小结：更好的 RDS 替代

刚才我们逐层递进介绍了需求金字塔，概括起来也就不过就是四句话：人无我有，人有我优，人优我易，人易我廉。这里我们的参照对象是云 RDS。

图片

尽管阿里腾讯最近也有可用区也爆出来了大故障，但在基本的功能安全可靠需求上，云数据库做的并不赖。尽管用的是网络存储云盘，但性能也算说得过去；更是在弹性/Serverless 上更是卷出了全新高度，只可惜因为十几倍的杀猪定价让 ROI 跌破谷底，显得不那么体面。更重要的是，在更高层面上的功能几乎是一片空白，用户需求无从满足。

图片

我们的目标不仅仅是做一个 RDS 的开源替代。云 RDS 有的我们都会有，更重要的是，云 RDS 没有的，我们也会有，而且我们要做的更好，让开源免费的软件，在各方面吊打商业付费的 RDS 服务。

Pigsty —— 让天下没有难用的数据库！谢谢大家。

References

发布版本：微信公众号

42 - 炮打 RDS，Pigsty v2.0 发布

原文发布于 VONNG。

图片

大家好，Pigsty 的作者冯若航。

我相信在座的不少人都对我比较熟悉，

因此我就实打实给大家透个底。

这两天社区嘉宾聚在一起喝大酒，

所以很抱歉今天临时赶工 PPT，

给大家贡献一段数据库脱口秀的把戏。

所以如果出现嘴炮误伤，

请台下的各位 友商 不要着急，

因为有可能，我真的就是故意。

今天给大家带来的分享主题，

不出意料是告别 Pigsty V1。

我们将在此时隆重发布 2.0 版本！

为云数据库带来本地优先的开源平替！

PGSQL 已经是足够完美的数据库内核引擎发动机，

业界需要的不是魔改换皮的无聊把戏。

用户不需要更多同质化的数据库内核，

稀缺的是把现有内核真正用好的能力。

造车厂的工程师，不会不自量力，

认为自己开起赛车来，比舒马赫还要牛逼。

能干好这件事的，数据库内核原厂没戏

只能靠资深甲方用户的 DBA 老司机。

想找能用好开源数据库的老师傅，

太稀缺金贵还真要下不少功夫。

所以也因此出现了云数据库，

提供帮助用户用好数据库内核的服务。

云数据库本应走一条体体面面的大路，

用共享规模效应压低成本，提供更廉价的服务。

奈何他们选择了一条恰烂钱的死路，

不思进取，只想使用大锅饭的水平糊弄用户。

更可恶的是把 20 块钱的硬件卖出十几倍天价，

利用信息不对称对用户进行杀猪！

v2 版本的 Pigsty，旨在改变这种状态，

提供本地优先、好用又开源的 RDS PG 替代。

PIGSTY 的缩写全称，是 PG in GREAT STYLE，

意思就是：让 PG 进入全盛状态。

Pigsty 让您在缺乏数据库专家的情况下，

也有能力自助管理企业级数据库服务。

您可以使用几分之一的硬件成本价格，

运行生产级的 PostgreSQL RDS 服务。

Pigsty 使用 AGPLv3 完全开源彻底免费，

无需向云厂商缴纳价格高昂的 “无专家税”。

即使您真的没有专家，

也无需对数据库感到害怕。

我们有免费社区热心答疑，

也提供商业订阅兜底。

说了这么多引子，终于迎来今天分享的正主。

v2 版本的 Pigsty，从 开箱即用的数据库发行版 变为

本地优先的 RDS PG 开源上位替代！

有一些人，喜欢使用各种时髦词汇吹牛逼。

HTAP、存算分离

Serverless，湖仓一体.

可惜技术名字对用户来说没有意义，

甲方在意的是各种实打实的 X-ability，

Observability & Controllability；Reliability & Extensibility；

Scalability & Maintainability，以及 Simplicity，and Security

当然有些用户会看 niubility，

就是你讲故事吹牛逼的能力，

表过不提，还是看你实打实解决痛点痒点问题的能力。

可观测性，可控制性；可靠性，可扩展性；

可伸缩性、可维护性、简单性、安全性。

那么 Pigsty 在这些性上，又有如何的表现力？

**可观测性（Observability）**是天；

乾卦，天行健，君子以自强不息；Pigsty 使用现代可观测性技术栈为 PostgreSQL 打造了一款无与伦比的监控系统，让用户对系统能够做到洞若观火，进而掌控一切。

**可控制性（Controllability）**是地；

坤卦，地势坤，君子以厚德载物；Pigsty 提供 Database as Code 的能力：使用表现力丰富的声明式接口描述数据库集群的状态，让用户拥有精细定制的能力的同时又无需操心实现细节，让数据库操作与管理的门槛从专家级降低到新手级。

**可伸缩性（Scalability）**是水；

坎卦，水洊至习坎，君子以常德行；Pigsty 可以针对环境自动优化参数，确保 PostgreSQL 的性能可以在现代硬件条件下充分发挥：单机可达数万并发连接/百万级单点查询 QPS/几十万级点写入 TPS。

**可维护性（Maintainability）**是火；离卦，明两作离，·大人以继明照于四方；Pigsty 允许在线摘除添加实例以扩缩容，Switchover/滚动升级进行升降配，提供基于逻辑复制的不停机蓝绿部署迁移方案，将系统对维护窗口的需求压缩至亚秒级。

**安全性（Security）**是雷；震卦，洊雷震，君子以恐惧修省；Pigsty 提供了一套遵循最小权限原则的访问控制模型，并带有各种安全特性开关：流复制同步提交防丢失，数据目录校验和防腐败，网络流量 SSL 加密防监听，远程备份 AES-256 防泄漏。让用户不再操心数据库安全性的问题。

**简单性（Simplicity）**是风；巽卦，随风巽，君子以申命行事；使用 Pigsty 的难度不会超过任何云数据库，它旨在以最小的复杂度成本交付完整的 RDS 功能，模块化设计允许用户自行组合选用所需的功能。Vagrant 与 Terraform 一键安装部署，完整复刻环境。

**可靠性（Reliability）**是山；艮卦，兼山艮，君子以思不出其位；Pigsty 提供了故障自愈的高可用架构应对硬件问题，也提供开箱即用的 PITR 时间点恢复为人为删库与软件缺陷兜底，并通过长时间、大规模的生产环境运行与高可用演练验证其可靠性。

**可扩展性（Extensibility）**是泽：兑卦，丽泽兑，君子以朋友讲习；Pigsty 深度整合 PostgreSQL 生态三大核心扩展 PostGIS、TimescaleDB、Citus、以及大量扩展插件；还有完整的 Prometheus / Grafana 全家桶，以及 MINIO，ETCD，Redis、Greenplum 等组件的监控与高可用部署，来与 PostgreSQL 配合使用；

Freestyle 了这么久，也请让窝喘口气，抽取六个亮点特性来加深记忆

Pigsty v2 正式发布：更好的 RDS PG 开源替代

（念稿时间）

Pigsty —— 让天下没有难用的数据库。

整合 PG 生态，海量软件一键拉起，开箱即用，让用户用得上！

无可比拟的可观测性，数据库看得见摸得着，让用户用的爽！

一键安装部署扩缩容，傻瓜式操作/量产 DBA，让用户用着省心！

自动驾驶的高可用架构，故障自愈，删库兜底，让用户用着放心！

最重要的是，好用又开源，实打实省钱，降维打击云数据库！

用云服务器的牛，耕云数据库的田，立省一半开销！

若是自建机房部署，砍掉八成都打不住！

我们出售订阅，提供服务，

但真正想做的是，颠覆云数据库！

One is enough to change the game!

云吃开源，谁来吃云？还看 Cloud Native！️

这是从云厂商 夺回软件自由的 伟大运动，

而其图景还缺少最后一块拼图！

我们将抢占这一空白生态位，从 PG 开始，补全这块拼图。

发布版本：微信公众号

43 - Pigsty v2.0：开源RDS PG替代

原文发布于 VONNG。

GitHub Release | 发布注记

Pigsty v2.0：开源 RDS PG 替代

2023/02/28，Pigsty v2.0.0 正式发布，带来了一系列重大的功能更新。

现在 PIGSTY 是 “PostgreSQL In Great STYle"的首字母缩写，即”全盛状态的 PostgreSQL"。而 Pigsty 的定位也不再是 “开箱即用的 PostgreSQL 数据库发行版”，变成了 “Me Better 开源 RDS PG 替代”。

明人不说暗话，这是一个很有野心的目标：推翻云数据库垄断，砸烂 RDS 的饭碗！详见：《云数据库是不是智商税？》

intro

2.0 新特性

Pigsty 是一个 更好的、本地优先 的，开源 RDS for PostgreSQL 替代。

features

强力的发行版

彻底释放世界上最先进的关系型数据库的力量!

PostgreSQL 是一个足够完美的数据库内核，但它需要更多工具与系统的配合，才能成为一个足够好的数据库服务（RDS），而 Pigsty 帮助 PostgreSQL 完成这一步飞跃。

Pigsty 深度整合了 PostgreSQL 生态的三大核心扩展插件 PostGIS，TimescaleDB，Citus，并确保它们可以协同工作，提供分布式的时序地理空间数据库能力。Pigsty 还提供了运行企业级 RDS 服务的所需软件，打包所有依赖为离线软件包，所有组件均可在无需互联网访问的情况下一键完成安装部署，进入生产可用状态。

在 Pigsty 中功能组件被抽象 模块，可以自由组合以应对多变的需求场景。INFRA 模块带有完整的现代监控技术栈，而 NODE 模块则将节点调谐至指定状态并纳入监控。在多个节点上安装 PGSQL 模块会自动组建出一个基于主从复制的高可用数据库集群，而同样的 ETCD 模块则为数据库高可用提供共识与元数据存储。可选的 MINIO 模块可以用作图像视频等大文件存储并可选用为数据库备份仓库。与 PG 有着极佳相性的 REDIS 亦为 Pigsty 所支持，更多的模块（如 GPSQL, MYSQL, KAFKA）将会在后续加入，你也可以开发自己的模块并自行扩展 Pigsty 的能力。

modules

惊艳的观测能力

使用现代开源可观测性技术栈，提供无与伦比的监控最佳实践！

Pigsty 提供了基于开源的 Grafana / Prometheus 可观测性技术栈做监控的最佳实践：Prometheus 用于收集监控指标，Grafana 负责可视化呈现，Loki 用于日志收集与查询，Alertmanager 用于告警通知。PushGateway 用于批处理任务监控，Blackbox Exporter 负责检查服务可用性。整套系统同样被设计为一键拉起，开箱即用的 INFRA 模块。

Pigsty 所管理的任何组件都会被自动纳入监控之中，包括主机节点，负载均衡 HAProxy，数据库 Postgres，连接池 Pgbouncer，元数据库 ETCD，KV 缓存 Redis，对象存储 MinIO，……，以及整套监控基础设施本身。大量的 Grafana 监控面板与预置告警规则会让你的系统观测能力有质的提升，当然，这套系统也可以被复用于您的应用监控基础设施，或者监控已有的数据库实例或 RDS。

无论是故障分析还是慢查询优化、无论是水位评估还是资源规划，Pigsty 为您提供全面的数据支撑，真正做到数据驱动。在 Pigsty 中，超过三千类监控指标被用于描述整个系统的方方面面，并被进一步加工、聚合、处理、分析、提炼并以符合直觉的可视化模式呈现在您的面前。从全局大盘总揽，到某个数据库实例中单个对象（表，索引，函数）的增删改查详情都能一览无余。您可以随意上卷下钻横向跳转，浏览系统现状与历史趋势，并预测未来的演变。详见公开演示：http://demo.pigsty.cc。

observability

久经考验的可靠性

开箱即用的高可用与时间点恢复能力，确保你的数据库坚如磐石！

对于软件缺陷或人为误操作造成的删表删库，Pigsty 提供了开箱即用的 PITR 时间点恢复能力，无需额外配置即默认启用。只要存储空间管够，基于 pgBackRest 的基础备份与 WAL 归档让您拥有快速回到过去任意时间点的能力。您可以使用本地目录/磁盘，亦或专用的 MinIO 集群或 S3 对象存储服务保留更长的回溯期限，丰俭由人。

更重要的是，Pigsty 让高可用与故障自愈成为 PostgreSQL 集群的标配，基于 patroni, etcd, 与 haproxy 打造的故障自愈架构，让您在面对硬件故障时游刃有余：主库故障自动切换的 RTO < 30s，一致性优先模式下确保数据零损失 RPO = 0。只要集群中有任意实例存活，集群就可以对外提供完整的服务，而客户端只要连接至集群中的任意节点，即可获得完整的服务。

Pigsty 内置了 HAProxy 负载均衡器用于自动流量切换，提供 DNS/VIP/LVS 等多种接入方式供客户端选用。故障切换与主动切换对业务侧除零星闪断外几乎无感知，应用不需要修改连接串重启。极小的维护窗口需求带来了极大的灵活便利：您完全可以在无需应用配合的情况下滚动维护升级整个集群。硬件故障可以等到第二天再抽空善后处置的特性，让研发，运维与 DBA 都能安心睡个好觉。许多大型组织与核心机构已经在生产环境中长时间使用 Pigsty，最大的部署有 25K CPU 核心与 200+ PostgreSQL 实例，在这一部署案例中，Pigsty 在三年内经历了数十次硬件故障与各类事故，但依然可以保持 99.999% 以上的整体可用性。

reliability

简单易用可维护

Infra as Code，数据库即代码，声明式的 API 将数据库管理的复杂度来封装。

Pigsty 使用声明式的接口对外提供服务，将系统的可控制性拔高到一个全新水平：用户通过配置清单告诉 Pigsty “我想要什么样的数据库集群”，而不用去操心到底需要怎样去做。从效果上讲，这类似于 K8S 中的 CRD 与 Operator，但 Pigsty 可用于任何节点上的数据库与基础设施：不论是容器，虚拟机，还是物理机。

无论是创建/销毁集群，添加/移除从库，还是新增数据库/用户/服务/扩展/黑白名单规则，您只需要修改配置清单并运行 Pigsty 提供的幂等剧本，而 Pigsty 负责将系统调整到您期望的状态。用户无需操心配置的细节，Pigsty 将自动根据机器的硬件配置进行调优，您只需要关心诸如集群叫什么名字，有几个实例放在哪几台机器上，使用什么配置模版：事务/分析/核心/微型，这些基础信息，研发也可以自助服务。但如果您愿意跳入兔子洞中，Pigsty 也提供了丰富且精细的控制参数，满足最龟毛 DBA 的苛刻定制需求。

除此之外，Pigsty 本身的安装部署也是一键傻瓜式的，所有依赖被预先打包，在安装时可以无需互联网访问。而安装所需的机器资源，也可以通过 Vagrant 或 Terraform 模板自动获取，让您在十几分钟内就可以从零在本地笔记本或云端虚拟机上拉起一套完整的 Pigsty 部署。本地沙箱环境可以跑在 1 核 2G 的微型虚拟机中，提供与生产环境完全一致的功能模拟，可以用于开发、测试、演示与学习。

maintainability

扎实的安全性

加密备份一应俱全，只要硬件与密钥安全，您无需操心数据库的安全性。

每套 Pigsty 部署都会创建一套自签名的 CA 用于证书签发，所有的网络通信都可以使用 SSL 加密。数据库密码使用合规的 scram-sha-256 算法加密存储，远端备份会使用 AES-256 算法加密。此外还针对 PGSQL 提供了一套开箱即用的的访问控制体系，足以应对绝大多数应用场景下的安全需求。

Pigsty 针对 PostgreSQL 提供了一套开箱即用，简单易用，精炼灵活的，便于扩展的访问控制体系，包括职能分离的四类默认角色：读(DQL) / 写(DML) / 管理(DDL) / 离线(ETL)，与四个默认用户：dbsu / replicator / monitor / admin。所有数据库模板都针对这些角色与用户配置有合理的默认权限，而任何新建的数据库对象也会自动遵循这套权限体系，而客户端的访问则受到一套基于最小权限原则的设计的 HBA 规则组限制，任何敏感操作都会记入日志审计。

任何网络通信都可以使用 SSL 加密，需要保护的敏感管理页面与 API 端点都受到多重保护：使用用户名与密码进行认证，限制从管理节点/基础设施节点 IP 地址/网段访问，要求使用 HTTPS 加密网络流量。Patroni API 与 Pgbouncer 因为性能因素默认不启用 SSL，但亦提供安全开关便于您在需要时开启。合理配置的系统通过等保三级毫无问题，只要您遵循安全性最佳实践，内网部署并合理配置安全组与防火墙，数据库安全性将不再是您的痛点。

security

广泛的应用场景

使用预置的 Docker 模板，一键拉起使用 PostgreSQL 的海量软件！

在各类数据密集型应用中，数据库往往是最为棘手的部分。例如 Gitlab 企业版与社区版的核心区别就是底层 PostgreSQL 数据库的监控与高可用，如果您已经有了足够好的本地 PG RDS，又为什么要为软件自带的土法手造数据库掏钱？

Pigsty 提供了 Docker 模块与大量开箱即用的 Compose 模板。您可以使用 Pigsty 管理的高可用 PostgreSQL （以及 Redis 与 MinIO ）作为后端存储，以无状态的模式一键拉起这些软件：Gitlab、Gitea、Wiki.js、Odoo、Jira、Confluence、Habour、Mastodon、Discourse、KeyCloak 等等。如果您的应用需要一个靠谱的 PostgreSQL 数据库，Pigsty 也许是最简单的获取方案。

Pigsty 也提供了与 PostgreSQL 紧密联系的应用开发工具集：PGAdmin4、PGWeb、ByteBase、PostgREST、Kong、以及 EdgeDB、FerretDB、Supabase 这些使用 PostgreSQL 作为存储的"上层数据库"。更奇妙的是，您完全可以基于 Pigsty 内置了的 Grafana 与 Postgres，以低代码的方式快速搭建起一个交互式的数据应用来，甚至还可以使用 Pigsty 内置的 ECharts 面板创造更有表现力的交互可视化作品。

applications

开源免费的自由软件

Pigsty 是基于 AGPLv3 开源的自由软件，由热爱 PostgreSQL 的社区成员用热情浇灌

Pigsty 是完全开源免费的自由软件，它允许您在缺乏数据库专家的情况下，用几乎接近纯硬件的成本来运行企业级的 PostgreSQL 数据库服务。作为对比，公有云厂商提供的 RDS 会收取底层硬件资源几倍到十几倍不等的溢价作为 “服务费”。

（ 参考阅读：为什么说云数据库是杀猪盘 ）

很多用户选择上云，正是因为自己搞不定数据库；很多用户使用 RDS，是因为别无他选。我们将打破云厂商的垄断，为用户提供一个云中立的，更好的 RDS 开源替代：Pigsty 紧跟 PostgreSQL 上游主干，不会有供应商锁定，不会有恼人的 “授权费”，不会有节点数量限制，不会收集您的任何数据。您的所有的核心资产 —— 数据，都能"自主可控"，掌握在自己手中。

Pigsty 本身旨在用数据库自动驾驶软件，替代大量无趣的人肉数据库运维工作，但再好的软件也没法解决所有的问题。总会有一些的冷门低频疑难杂症需要专家介入处理。这也是为什么我们也提供专业的订阅服务，来为有需要的企业级用户使用 PostgreSQL 提供兜底。几万块的订阅咨询费不到顶尖 DBA 每年工资的几十分之一，让您彻底免除后顾之忧，把成本真正花在刀刃上。当然对于社区用户，我们亦用爱发电，提供免费的支持与日常答疑。

opensource

2.0 快速上手

Pigsty 2.0 的安装依然是一条命令搞定所有：

curl -fsSL http://download.pigsty.cc/get | bash
install

如果互联网访问受限，您可以提前从 Github 或 CDN 下载对应操作系统的离线软件包进行离线安装。监控系统部分提供公开的 Demo：http://demo.pigsty.cc。

demo

v2.0.0

相关文章：

Pigsty v2.0.0 正式发布！

从 v2.0.0 开始，PIGSTY 现在是 “PostgreSQL In Great STYle"的首字母缩写，即"全盛状态的 PostgreSQL”。

curl -fsSL http://download.pigsty.cc/get | bash
Download directly from GitHub Release 
bash -c "$(curl -fsSL https://raw.githubusercontent.com/Vonng/pigsty/master/bin/get)"

# or download tarball directly with curl (EL9)
curl -L https://github.com/Vonng/pigsty/releases/download/v2.0.0/pigsty-v2.0.0.tgz -o ~/pigsty.tgz
curl -L https://github.com/Vonng/pigsty/releases/download/v2.0.0/pigsty-pkg-v2.0.0.el9.x86_64.tgz  -o /tmp/pkg.tgz
# EL7: https://github.com/Vonng/pigsty/releases/download/v2.0.0/pigsty-pkg-v2.0.0.el7.x86_64.tgz
# EL8: https://github.com/Vonng/pigsty/releases/download/v2.0.0/pigsty-pkg-v2.0.0.el8.x86_64.tgz

亮点

  • 完美整合 PostgreSQL 15，PostGIS 3.3，Citus 11.2，TimescaleDB 2.10，分布式地理时序超融合数据库。
  • OS 兼容性大幅增强：支持 EL7，8，9，以及 RHEL，CentOS，Rocky，OracleLinux，AlmaLinux 等兼容发行版。
  • 安全性改进：自签名 CA，全局网络流量 SSL 加密，密码 scram-sha-256 认证，备份采用 AES 加密，重制的 HBA 规则系统。
  • Patroni 升级至 3.0，提供原生的高可用 Citus 分布式集群支持，默认启用 FailSafe 模式，无惧 DCS 故障致全局主库瘫痪。
  • 提供基于 pgBackRest 的开箱即用的时间点恢复 PITR 支持，默认支持本地文件系统与专用 MinIO/S3 集群备份。
  • 新模块 ETCD，可独立部署，简易扩缩容，自带监控高可用，彻底取代 Consul 作为高可用 PG 的 DCS。
  • 新模块 MINIO，可独立部署，支持多盘多节点部署，用作 S3 本地替代，亦用于集中式 PostgreSQL 备份仓库。
  • 大幅精简配置文件参数，无需默认值即可使用；模板自动根据机器规格调整主机与 PG 参数，HBA/服务的定义更简洁泛用。
  • 受 Grafana 与 MinIO 影响，软件协议由 Apache License 2.0 变更为 AGPL 3.0

兼容性

  • 支持 EL7，EL8，EL9 三个大版本，并提供三个版本对应的离线软件包，默认开发测试环境由 EL7 升级至 EL9。
  • 支持更多 EL 兼容 Linux 发行版：RHEL，CentOS，RockyLinux，AlmaLinux，OracleLinux 等…
  • 源码包与离线软件包的命名规则发生改变，现在版本号，操作系统版本号，架构都会体现在包名中。
  • PGSQL: PostgreSQL 15.2，PostGIS 3.3，Citus 11.2，TimescaleDB 2.10 现可同时使用，协同工作。
  • PGSQL: Patroni 升级至 3.0 版本，作为 PGSQL 的高可用组件。
    • 默认使用 ETCD 作为 DCS，取代 Consul，减少一个 Consul Agent 失效点。
    • 因为 vip-manager 升级至 2.1 并使用 ETCDv3 API，彻底弃用 ETCDv2 API，Patroni 同理
    • 提供原生的高可用 Citus 分布式集群支持。使用完全开源所有功能的 Citus 11.2。
    • 默认启用 FailSafe 模式，无惧 DCS 故障致全局主库瘫痪。
  • PGSQL: 引入 pgBackrest v2.44 提供开箱即用的 PostgreSQL 时间点恢复 PITR 功能
    • 默认使用主库上的备份目录创建备份仓库，滚动保留两天的恢复窗口。
    • 默认备选备份仓库为专用 MinIO/S3 集群，滚动保留两周的恢复窗口，本地使用需要启用 MinIO 模块。
  • ETCD 现在作为一个独立部署的模块，带有完整的扩容/缩容方案与监控。
  • MINIO 现在成为一个独立部署的模块，支持多盘多节点部署，用作 S3 本地替代，亦可用作集中式备份仓库。
  • NODE 模块现在包含 haproxy, docker, node_exporter, promtail 功能组件
    • chronyd 现在取代 ntpd 成为所有节点默认的 NTP 服务。
    • HAPROXY 现从属于 NODE 的一部分，而不再是 PGSQL 专属，可以 NodePort 的方式对外暴露服务。
    • 现在 PGSQL 模块可以使用专用的集中式 HAPROXY 集群统一对外提供服务。
  • INFRA 模块现在包含 dnsmasq, nginx, prometheus, grafana, loki 等组件
    • Infra 模块中的 DNSMASQ 服务器默认启用，并添加为所有节点的默认 DNS 服务器之一。
    • 添加了 blackbox_exporter 用于主机 PING 探测，pushgateway 用于批处理任务指标。
    • loki 与 promtail 现在使用 Grafana 默认的软件包，使用官方的 Grafana Echarts 面板插件
    • 提供针对 PostgreSQL 15 的新增可观测性位点的监控支持，添加 Patroni 监控
  • 软件版本升级
    • PostgreSQL 15.2 / PostGIS 3.3 / TimescaleDB 2.10 / Citus 11.2
    • Patroni 3.0 / Pgbouncer 1.18 / pgBackRest 2.44 / vip-manager 2.1
    • HAProxy 2.7 / Etcd 3.5 / MinIO 20230131022419 / mcli 20230128202938
    • Prometheus 2.42 / Grafana 9.3 / Loki & Promtail 2.7 / Node Exporter 1.5

安全性

  • 启用了一个完整的本地自签名 CA：pigsty-ca，用于签发内网组件所使用的证书。
  • 创建用户/修改密码的操作将不再会在日志文件中留下痕迹。
  • Nginx 默认启用 SSL 支持（如需 HTTPS，您需要在系统中信任 pigsty-ca，或使用 Chrome thisisunsafe）
  • ETCD 全面启用 SSL 加密客户端与服务端对等通信
  • PostgreSQL 添加并默认启用了 SSL 支持，管理链接默认都使用 SSL 访问。
  • Pgbouncer 添加了 SSL 支持，出于性能考虑默认不启用。
  • Patroni 添加了 SSL 支持，并默认限制了管理 API 只能从本机与管理节点使用密码认证方可访问。
  • PostgreSQL 的默认密码认证方式由 md5 改为 scram-sha-256。
  • Pgbouncer 添加了认证查询支持，可以动态管理连接池用户。
  • pgBackRest 使用远端集中备份存储仓库时，默认使用 AES-256-CBC 加密备份数据。
  • 提供高安全等级配置模板：强制使用全局 SSL，并要求使用管理员证书登陆。
  • 所有默认 HBA 规则现在全部在配置文件中显式定义。

可维护性

  • 现有的配置模板可根据机器规格（CPU/内存/存储）自动调整优化。
  • 现在可以动态配置 Postgres/Pgbouncer/Patroni/pgBackRest 的日志目录：默认为：/pg/log/<type>/
  • 原有的 IP 地址占位符 10.10.10.10 被替换为一个专用变量：${admin_ip}，可在多处引用，便于切换备用管理节点。
  • 您可以指定 region 来使用不同地区的上游镜像源，以加快软件包的下载速度。
  • 现在允许用户定义更细粒度的上游源地址，您可以根据不同的 EL 版本、架构，以及地区，使用不同的上游源。
  • 提供了阿里云与 AWS 中国地区的 Terraform 模板，可用于一键拉起所需的 EC2 虚拟机。
  • 提供了多种不同规格的 Vagrant 沙箱模板：meta, full, el7/8/9, minio, build, citus
  • 添加了新的专用剧本：pgsql-monitor.yml 用于监控现有的 Postgres 实例或 RDS。
  • 添加了新的专用剧本：pgsql-migration.yml，使用逻辑复制无缝迁移现有实例至 Pigsty 管理的集群。
  • 添加了一系列专用 Shell 实用命令，封装常见运维操作，方便用户使用。
  • 优化了所有 Ansible Role 的实现，使其更加简洁、易读、易维护，无需默认参数即可使用。
  • 允许在业务数据库/用户的层次上定义额外的 Pgbouncer 参数。

API 变更

Pigsty v2.0 进行了大量变更，新增 64 个参数，移除 13 个参数，重命名 17 个参数。

新增的参数

  • INFRA.META.admin_ip : 主元节点 IP 地址
  • INFRA.META.region : 上游镜像区域：default|china|europe
  • INFRA.META.os_version : 企业版 Linux 发行版本：7,8,9
  • INFRA.CA.ca_cn : CA 通用名称，默认为 pigsty-ca
  • INFRA.CA.cert_validity : 证书有效期，默认为 20 年
  • INFRA.REPO.repo_enabled : 在 infra 节点上构建本地 yum 仓库吗？
  • INFRA.REPO.repo_upstream : 上游 yum 仓库定义列表
  • INFRA.REPO.repo_home : 本地 yum 仓库的主目录，通常与 nginx_home ‘/www’ 相同
  • INFRA.NGINX.nginx_ssl_port : https 监听端口
  • INFRA.NGINX.nginx_ssl_enabled : 启用 nginx https 吗？
  • INFRA.PROMTETHEUS.alertmanager_endpoint : altermanager 端点（ip|domain）：端口格式
  • NODE.NODE_TUNE.node_hugepage_ratio : 内存 hugepage 比率，默认禁用，值为 0
  • NODE.HAPROXY.haproxy_service : 要公开的 haproxy 服务列表
  • PGSQL.PG_ID.pg_mode : pgsql 集群模式：pgsql,citus,gpsql
  • PGSQL.PG_BUSINESS.pg_dbsu_password : dbsu 密码，默认为空字符串表示没有 dbsu 密码
  • PGSQL.PG_INSTALL.pg_log_dir : postgres 日志目录，默认为 /pg/data/log
  • PGSQL.PG_BOOTSTRAP.pg_storage_type : SSD|HDD，默认为 SSD
  • PGSQL.PG_BOOTSTRAP.patroni_log_dir : patroni 日志目录，默认为 /pg/log
  • PGSQL.PG_BOOTSTRAP.patroni_ssl_enabled : 使用 SSL 保护 patroni RestAPI 通信？
  • PGSQL.PG_BOOTSTRAP.patroni_username : patroni rest api 用户名
  • PGSQL.PG_BOOTSTRAP.patroni_password : patroni rest api 密码（重要：请更改此密码）
  • PGSQL.PG_BOOTSTRAP.patroni_citus_db : 由 patroni 管理的 citus 数据库，默认为 postgres
  • PGSQL.PG_BOOTSTRAP.pg_max_conn : postgres 最大连接数，auto 将使用推荐值
  • PGSQL.PG_BOOTSTRAP.pg_shmem_ratio : postgres 共享内存比率，默认为 0.25，范围 0.1~0.4
  • PGSQL.PG_BOOTSTRAP.pg_rto : 恢复时间目标，故障转移的 ttl，默认为 30s
  • PGSQL.PG_BOOTSTRAP.pg_rpo : 恢复点目标，默认最多丢失 1MB 数据
  • PGSQL.PG_BOOTSTRAP.pg_pwd_enc : 密码加密算法：md5|scram-sha-256
  • PGSQL.PG_BOOTSTRAP.pgbouncer_log_dir : pgbouncer 日志目录，默认为 /var/log/pgbouncer
  • PGSQL.PG_BOOTSTRAP.pgbouncer_auth_query : 如果启用，查询 pg_authid 表以检索 biz 用户，而不是填充用户列表
  • PGSQL.PG_BOOTSTRAP.pgbouncer_sslmode : pgbouncer 客户端的 SSL：disable|allow|prefer|require|verify-ca|verify-full
  • PGSQL.PG_BOOTSTRAP.pg_service_provider : 专用的 haproxy 节点组名称，或者默认为本地节点的空字符串
  • PGSQL.PG_BOOTSTRAP.pg_default_service_dest : 如果 svc.dest=‘default’，则为默认服务目标
  • PGSQL.PG_BACKUP.pgbackrest_enabled : 启用 pgbackrest 吗？
  • PGSQL.PG_BACKUP.pgbackrest_clean : 初始化期间删除 pgbackrest 数据吗？
  • PGSQL.PG_BACKUP.pgbackrest_log_dir : pgbackrest 日志目录，默认为 /pg/log
  • PGSQL.PG_BACKUP.pgbackrest_method : pgbackrest 备份仓库方法，local 或 minio
  • PGSQL.PG_BACKUP.pgbackrest_repo : pgbackrest 备份仓库配置
  • PGSQL.PG_DNS.pg_dns_suffix : pgsql dns 后缀，默认为空字符串
  • PGSQL.PG_DNS.pg_dns_target : auto，primary，vip，none 或 ad hoc ip
  • ETCD.etcd_seq : etcd 实例标识符，必需
  • ETCD.etcd_cluster : etcd 集群和组名称，默认为 etcd
  • ETCD.etcd_safeguard : 防止清除正在运行的 etcd 实例吗？
  • ETCD.etcd_clean : 在初始化期间清除现有的 etcd 吗？
  • ETCD.etcd_data : etcd 数据目录，默认为 /data/etcd
  • ETCD.etcd_port : etcd 客户端端口，默认为 2379
  • ETCD.etcd_peer_port : etcd 对等端口，默认为 2380
  • ETCD.etcd_init : etcd 初始集群状态，新建或已存在
  • ETCD.etcd_election_timeout : etcd 选举超时，默认为 1000ms
  • ETCD.etcd_heartbeat_interval : etcd 心跳间隔，默认为 100ms
  • MINIO.minio_seq : minio 实例标识符，必须参数
  • MINIO.minio_cluster : minio 集群名称，默认为 minio
  • MINIO.minio_clean : 初始化时清理 minio 吗？默认为 false
  • MINIO.minio_user : minio 操作系统用户，默认为 minio
  • MINIO.minio_node : minio 节点名模式
  • MINIO.minio_data : minio 数据目录，使用 {x…y} 来指定多个驱动器
  • MINIO.minio_domain : minio 外部域名，默认为 sss.pigsty
  • MINIO.minio_port : minio 服务端口，默认为 9000
  • MINIO.minio_admin_port : minio 控制台端口，默认为 9001
  • MINIO.minio_access_key : 根访问密钥，默认为 minioadmin
  • MINIO.minio_secret_key : 根秘密密钥，默认为 minioadmin
  • MINIO.minio_extra_vars : minio 服务器的额外环境变量
  • MINIO.minio_alias : 本地 minio 部署的别名
  • MINIO.minio_buckets : 待创建的 minio 存储桶列表
  • MINIO.minio_users : 待创建的 minio 用户列表

移除的参数

  • INFRA.CA.ca_homedir : CA 主目录，现在固定为 /etc/pki/
  • INFRA.CA.ca_cert : CA 证书文件名，现在固定为 ca.key
  • INFRA.CA.ca_key : CA 密钥文件名，现在固定为 ca.key
  • INFRA.REPO.repo_upstreams : 已被 repo_upstream 替代
  • PGSQL.PG_INSTALL.pgdg_repo : 现在由节点 playbooks 负责
  • PGSQL.PG_INSTALL.pg_add_repo : 现在由节点 playbooks 负责
  • PGSQL.PG_IDENTITY.pg_backup : 未使用且与部分名称冲突
  • PGSQL.PG_IDENTITY.pg_preflight_skip : 不再使用，由 pg_id 替代
  • DCS.dcs_name : 由于使用 etcd 而被移除
  • DCS.dcs_servers : 被 ad hoc 组 etcd 替代
  • DCS.dcs_registry : 由于使用 etcd 而被移除
  • DCS.dcs_safeguard : 被 etcd_safeguard 替代
  • DCS.dcs_clean : 被 etcd_clean 替代

重命名的参数

  • nginx_upstream -> infra_portal
  • repo_address -> repo_endpoint
  • pg_hostname -> node_id_from_pg
  • pg_sindex -> pg_group
  • pg_services -> pg_default_services
  • pg_services_extra -> pg_services
  • pg_hba_rules_extra -> pg_hba_rules
  • pg_hba_rules -> pg_default_hba_rules
  • pgbouncer_hba_rules_extra -> pgb_hba_rules
  • pgbouncer_hba_rules -> pgb_default_hba_rules
  • vip_mode -> pg_vip_enabled
  • vip_address -> pg_vip_address
  • vip_interface -> pg_vip_interface
  • node_packages_default -> node_default_packages
  • node_packages_meta -> infra_packages
  • node_packages_meta_pip -> infra_packages_pip
  • node_data_dir -> node_data

Checksums 

MD5 (pigsty-pkg-v2.0.0-rc1.el7.x86_64.tgz) = af4b5db9dc38c860de609956a8f1f0d3
MD5 (pigsty-pkg-v2.0.0-rc1.el8.x86_64.tgz) = 5b7152e142df3e3cbc06de30bd70e433
MD5 (pigsty-pkg-v2.0.0-rc1.el9.x86_64.tgz) = 1362e2a5680fc1a3a014cc4f304100bd

特别感谢意大利用户 @alemacci 在 SSL 加密，备份，多操作系统发行版适配与自适应参数模版上的贡献！

v2.0.1

https://github.com/Vonng/pigsty/releases/tag/v2.0.1

安全性改进，与对 v2.0.0 的 BUG 修复。

改进

  • 更换猪头 logo 以符合 PostgreSQL 商标政策。
  • 将 grafana 版本升级至 v9.4，界面更佳且修复了 bug。
  • 将 patroni 版本升级至 v3.0.1，其中包含了一些 bug 修复。
  • 修改：将 grafana systemd 服务文件回滚到 rpm 默认的版本。
  • 使用缓慢的 copy 代替 rsync 来复制 grafana 仪表板，更加可靠。
  • 增强：bootstrap 执行后会添加回默认 repo 文件。
  • 添加 asciinema 视频，用于各种管理任务。
  • 安全增强模式：限制监控用户权限。
  • 新的配置模板：dual.yml，用于双节点部署。
  • 在 crit.yml 模板中启用 log_connections 和 log_disconnections。
  • 在 crit.yml 模板中的 pg_libs 中启用 $lib/passwordcheck。
  • 明确授予 pg_monitor 角色监视视图权限。
  • 从 dbuser_monitor 中移除默认的 dbrole_readonly 以限制监控用户的权限
  • 现在 patroni 监听在 {{ inventory_hostname }} 而不是 0.0.0.0
  • 现在你可以使用 pg_listen 控制 postgres/pgbouncer 监听的地址
  • 现在你可以在 pg_listen 中使用 ${ip}, ${lo}, ${vip} 占位符
  • 将 Aliyun terraform 镜像从 centos 7.9 提升到 rocky Linux 9
  • 将 bytebase 版本升级到 v1.14.0

BUG 修复

  • 为 alertmanager 添加缺失的 advertise 地址。
  • 解决使用 bin/pgsql-user 创建数据库用户时，pg_mode 变量缺失问题。
  • 在 redis.yml 中为 Redis 集群加入任务添加 -a password 选项。
  • 在 infra-rm.yml.remove infra data 任务中补充缺失的默认值。
  • 修复 prometheus 监控对象定义文件的属主为 prometheus 用户。
  • 使用 管理员用户 而不是 root 去删除 DCS 中的元数据。
  • 修复了由 grafana 9.4 bug 导致的问题：Meta 数据源缺失。

注意事项

EL8 pgdg 上游官方源处于依赖破损状态，请小心使用。涉及到的软件包： postgis33_15, pgloader, postgresql_anonymizer_15*, postgresql_faker_15

如何升级？

cd ~/pigsty; tar -zcf /tmp/files.tgz files; rm -rf ~/pigsty    # backup files dir and remove
cd ~; bash -c "$(curl -fsSL https://get.pigsty.cc/latest)"      # get latest pigsty source
cd ~/pigsty; rm -rf files; tar -xf /tmp/files.tgz -C ~/pigsty  # restore files dir

Checksums 

MD5 (pigsty-pkg-v2.0.1.el7.x86_64.tgz) = 5cfbe98fd9706b9e0f15c1065971b3f6
MD5 (pigsty-pkg-v2.0.1.el8.x86_64.tgz) = c34aa460925ae7548866bf51b8b8759c
MD5 (pigsty-pkg-v2.0.1.el9.x86_64.tgz) = 055057cebd93c473a67fb63bcde22d33

特别感谢 @cocoonkid 提供的反馈。

v2.0.2

https://github.com/Vonng/pigsty/releases/tag/v2.0.2

亮点

使用开箱即用的 pgvector 存储 AI Embedding、索引、检索向量。

变更

  • 新扩展插件 pgvector 用于存储 AI 嵌入，并执行向量相似度搜索。
  • 修复 MinIO CVE-2023-28432，使用 20230324 新提供的 policy API.
  • 为 DNSMASQ systemd 服务添加动态重载命令
  • 更新 PEV 版本至 v1.8
  • 更新 grafana 版本至 v9.4.7
  • 更新 MinIO 与 MCLI 版本至 20230324
  • 更新 bytebase 版本至 v1.15.0
  • 更新监控面板并修复死链接
  • 更新了阿里云 Terraform 模板，默认使用 RockyLinux 9
  • 使用 Grafana v9.4 的 Provisioning API
  • 为众多管理任务添加了 asciinema 视频
  • 修复了 EL8 PostgreSQL 的破损依赖：移除 anonymizer_15 faker_15 pgloader
MD5 (pigsty-pkg-v2.0.2.el7.x86_64.tgz) = d46440a115d741386d29d6de646acfe2
MD5 (pigsty-pkg-v2.0.2.el8.x86_64.tgz) = 5fa268b5545ac96b40c444210157e1e1
MD5 (pigsty-pkg-v2.0.2.el9.x86_64.tgz) = c8b113d57c769ee86a22579fc98e8345

发布版本：微信公众号

44 - Pigsty 2.0 展望

原文发布于 VONNG。

最近 PostgreSQL 15 发布了，Pigsty 也开始了紧锣密鼓地跟进，筹划第二个大版本：v2。

Pigsty 2.0 版本将引入一系列重大增强与改进。包括安全性，兼容性，易用性的大幅改进，并添加了开箱即用的 PITR 时间点恢复支持。此版本后，Pigsty 中 PostgreSQL 的架构状态将趋于完美，Pigsty 的缩写也相应修改为 “PostgreSQL in Great STYle”，即 “全盛状态的 PostgreSQL”。

Pigsty v2.0 旨在为用户提供一个开源的，更好的云数据库 RDS for PostgreSQL 上位替代。Pigsty v2.0 目前处于 ALPHA 状态，预计在 PG 15.1，以及 TimescaleDB 支持 PG15 后正式发布。

图片

亮点

  • 升级至 PG 15，PostGIS 3.3，Citus 11，TimescaleDB 2.8

  • 支持 EL 7，8，9 及兼容发行版（RHEL，CentOS，Rocky，Oracle，Alma）

  • 开箱即用的原地时间点恢复支持 （pgbackrest）

  • 自适配的节点与数据库配置模板，根据机型规格自动调优

  • 自签名 CA，全局 SSL 加密网络流量，更完善的安全机制

  • 独立管理的 etcd 集群、部署剧本、监控面板

  • 新的 MINIO 对象存储服务，部署、监控支持，允许作为备份中心。

  • 开源协议由 Apache License 2.0 变更为 AGPLv3

  • 配置文件大幅精简，用户只需提供身份参数（ID，IP）即可使用。

META

Pigsty v2 现在添加了新的 meta_ip 参数，在配置过程中配置为当前节点的首要 IP 地址，可以在其他变量中引用。例如，当您想使用 备份 Infra 节点时，可以直接通过修改此参数，一次性修改 DNS，NTP，Grafana，Loki 中的引用。

v2 在配置时自动检测环境并配置 region （也可以手工制定），Pigsty 会根据区域自动设置一些地理相关的变量，例如上游仓库的镜像地址，NTP 服务子区域等。这一功能主要用于在大陆地区避免 GFW 干扰，加快下载速度。

CA

在 v2 中会默认创建一个自签名的 CA，为 etcd，PostgreSQL，以及其他所有需要 SSL 的服务签发证书。该 CA 会在所有节点被加入信任 CA 名单，以支持 SSL 流量加密。

REPO

Repo 定义现在兼容不同的 EL 版本，将自动根据 EL 版本选择对应的 Repo。现在您可以通过 region 指定使用特定区域的上游仓库，例如 china, europe，加速下载并绕开 GFW。

Repo 将使用 TimescaleDB 与 Citus 官方的仓库下载插件。

对于 EL8，EL9，将直接使用 AppStream 仓库中的 Redis，与 PGDG 仓库中的 HAProxy。

将从 Minio 官方下载 minio 与 mcli 软件包。

DCS

在 DCS 上，etcd，consul 服务将默认启用 SSL，只有管理节点才可以使用命令行访问 DCS。该特性可以确保 DCS 网络流量不受窃听影响，且将集群状态修改的权限收拢至管理节点上。

ETCD 将取代 Consul 成为 Pigsty 默认使用的 DCS 服务。因为它提供了轻量的实现，少了 Agent 这个额外失效点。且因为 Kubernetes 的存在变得更为流行，沉淀有更多运维经验。

V2 将提供专用的剧本 etcd.yml 以部署 ETCD 集群。并提供了专门的 ETCD 监控面板。

Node

新增的 node_id 角色，将统一收集节点信息，并配置节点的身份参数。

所有 nodes 名称 现在统一收敛至 node 单数形式。

Chrony 将成为默认的 NTP 服务，替代 NTPD。

Tuned 模板中，将自动以 HugePage 的形式分配 26% 的内存专供 PostgreSQL 使用，提高性能。

一个专用的 node_remove 角色现在负责处理从 Pigsty 移除节点的工作。

主机节点默认使用的模板从 tiny 修改为 oltp。

PostgreSQL

在 PostgreSQL 上，v2 将默认启用 SSL 支持，允许使用加密连接访问 PostgreSQL 服务，以加密数据库通信避免窃听。/pg/cert 目录用于盛放服务端证书，用于加密数据库与连接池的流量，访问 ETCD 服务。

修改用户密码的操作记录现在将从 PG 日志中移除，以避免意外泄漏。

新的 scram-sha-256 将取代 md5，成为 Pigsty 中 PG 默认的密码认证方式，以提高安全性。

新增的 monitor.pgbouncer_auth 函数用于连接池的 Auth Query，仅超级用户可本地访问。

默认模板中创建了file_fdw，并添加了一个名为 fs 的foreign server，基于此提供了几张外部表用于展示 Patroni 集群信息与配置，以及 Pgbackrest 备份信息，仅监控用户可以访问。

现在，/pg/conf 将收拢 Postgres，Patroni，Pgbouncer，pgbackrest，Haproxy，VipManager 的配置文件，创建快捷软链，便于集中访问与调整。

现在，/pg/log 将收拢 Postgres，Patroni，Pgbouncer，pgbackrest 的日志，便于集中访问与调整。

PostGIS，TimescaleDB，Citus 的软件包从 pg_packages 移动到 pg_extensions，这样当某个操作系统发行版（例如 EL9）缺少相关插件时，用户只需要修改 pg_extensions 变量即可。

Patroni

Patroni 现在可以通过 pg_rpo 与 pg_rto 参数，控制 Failover 触发的条件，让用户有机会精确权衡可用性与一致性的具体阈值。当然，crit.yml 模板仍然会强制使用 pg_rpo = 0 确保数据 0 丢失。

Patroni 所有不安全的 API （例如重启集群，Failover）现在都限制了访问 IP 来源，您只能从管理节点执行此操作。但常规的信息查询，健康检查 API 仍然不受影响。此外，Patroni 现在拥有一组独立的管理用户名与密码参数，您必须使用 HTTP BASIC AUTH 指明用户名密码才可以调用不安全的 API。

Patroni 现在可以对 REST API 启用 SSL，默认不启用，因为健康检查是一个很频繁的操作。

现在，一个专用的 pg_id 角色将用于收集数据库节点的基本信息（CPU，内存，磁盘等），Patroni 标签中添加了机器配置规格的信息，可直观浏览集群规格。

现在 Patroni 的配置模板收敛至 oltp , olap, crit, tiny 四种，每一种根据经验调优规则，自动适配从 1 核到几百核几百 GB 内存的机型。

Pgbouncer

在 Pgbouncer 连接池上，SSL 也得到了支持。

v2 允许用户通过 auth_query 的方式，对于 Pgbouncer 配置中不存在的用户，自动从 PostgreSQL 数据库中查询并进行认证。

提供了新的快捷命令 pgb-route，用于在故障或迁移时快速切换 Pgbouncer 的目标流量。

Pgbouncer 现在默认使用 session pooling 模式，以提高应用兼容性。

Pgbackrest

v2 新增了 PGBACKREST 支持，默认在集群主节点本地创建一个备份仓库，用于存储归档与冷备份。

默认情况下，PGBACKREST 将在集群的所有实例上初始化一个仓库，但仅使用主库上的仓库用于 WAL 归档与基础备份。您可以通过 pgbackrest_repo 参数，使用专用的备份服务器或 S3 兼容服务作为集中的冷备份存储仓库。

Pigsty 添加了一系列开箱即用的配置与快捷命令，能让您自动回复到过去一段时间的任意时间点。

Promtail

现在您可以指定 Postgres，Pgbouncer，Pgbackrest，Patroni 的日志位置，默认值收拢至 /pg/log/<p*>。Promtail 与其他日志相关的命令和快捷方式会自动适配这些日志位置。

Makefile

添加了自动构建相关的快捷方式。

添加了写入心跳记录，健康检查的快捷方式，用于测试 PITR。

添加了 Vagrant 模板管理的快捷方式

Deploy

添加了 AWS 的 Terraform 4 节点部署模板。

添加了几种新的 Vagrant 模板，可以测试 EL7，8，9 的部署，并自动构建对应平台的离线软件包。

添加了新的 bootstrap 脚本，替代原有的 download 与 configure 的部分功能。该脚本负责下载软件包，配置本地 Repo，并最终确保本机 Ansible 可用。现有 configure 脚本现在只负责监测当前环境，生成对应的 pigsty.yml 配置文件。

Packages

现在 Pigsty 的源码包与离线软件包将带有版本号，离线软件包还将带有操作系统平台标识（el7.x86_64，el8.x86_64，el9.x86_64）。以便在未来兼容其他架构（arm）与操作系统发型版（ubuntu）。

  • PostgreSQL 14.5 / PostgreSQL 15.0

  • Patroni 2.1.4

  • Pgbouncer 1.17

  • HAProxy 2.6.6

  • PostGIS 3.3

  • Citus 11.1：彻底开源，带有完整的分片调整功能。

  • TimescaleDB 2.8

  • Prometheus 2.39

  • Loki & Promtail 2.6.1

  • Grafana 9.2.3

  • Node Exporter 1.4

  • Consul v13.3

  • ETCD 3.5.5

Misc

现在 Pigsty 将使用带有官方签名的 Echarts Grafana 面板，支持最新的 Echarts 5 与 Echarts GL。

如果您有任何想法，需求，功能建议，欢迎在 Github 提 https://github.com/Vonng/pigsty/issues 或加入 Pigsty 交流群讨论。

发布版本：微信公众号

45 - 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

46 - 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 的使用门槛压到地板，我们要把软件自由交还用户：让天下没有难用的数据库，谢谢！

图片图片

发布版本：微信公众号

47 - 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 群组！

图片

发布版本：微信公众号

48 - 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

发布版本：微信公众号

49 - 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”。

发布版本：微信公众号

50 - 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 时的样式问题

51 - 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 剧本将生成一系列脚本，帮助实现近乎零停机时间的集群迁移。

52 - 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

发布版本：微信公众号

53 - 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 以减少开销

54 - 开箱即用的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

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

发布版本：微信公众号

55 - 开箱即用的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的生态更加繁荣，更加多彩。

56 - 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

57 - 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

58 - 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 文件。

59 - 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 覆盖

60 - 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

图片

发布版本：微信公众号

61 - 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。

梦想还是要有的，万一🔥了呢对不对？

发布版本：微信公众号

62 - 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中。

63 - 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

64 - 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

65 - 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 的时长

    • 响应时间的均值，标准差，最小值，最大值（自从上一次统计周期以来）

    • 查询最近一天的调用次数，返回行数，总耗时。以及自重置以来的总调用次数。

  • 下方是指定时间段的查询指标图表，是概览指标的细化。

图片

发布版本：微信公众号