跳过正文
Background Image
  1. PostgreSQL大法师/

从PG“断供”看软件供应链中的信任问题

·3927 字·8 分钟· ·
冯若航
作者
冯若航
Pigsty 创始人, @Vonng
目录

这个月发生了一起沸沸扬扬的 “开源断供”事件—— KubeSphere 删除镜像跑路, 但其实还有另一件略隐蔽的 “卡脖子案例”,老冯在上个月提到过 —— 《卡脖子:PGDG切断镜像站同步通道》。 这次 “PostgreSQL 断供” 某种程度上扮演了试金石的角色,倒是很好的试出了各家数据库厂商和云厂商的成色。

老冯对此感到非常失望,停止将国内的云厂商和大学镜像站作为软件供应链上游,直接自建了 PGDG YUM/APT 仓库的国内最新同步镜像。

PGDG的“断供”
#

PostgreSQL 是数据库领域的祖师爷级开源项目,也是世界上最流行,最受喜爱,需求量最大的数据库。 绝大多数的用户都是通过 PGDG APT / YUM 仓库,来在 Linux 上安装 PostgreSQL 数据库的。 不幸的是,PGDG (全称:PostgreSQL 全球开发组)的 APT / YUM 软件制成品仓库在今年五月中旬对外关闭了 ftp 与 rsync 同步通道, 这导致了几乎全球的镜像站点都与上游仓库失去同步,存放的都是几个月前的旧版本软件包。

老冯在 7月7号的 《卡脖子:PGDG切断镜像站同步通道》一文中详细介绍过这个问题。 那时候老冯观察到德国的 XTOM 其实尝试手工按月手工更新的策略,其他基本上所有镜像站全军覆没,都停留在三四五月的状态。昨天我重新统计了一下,发现俄罗斯的 YANDEX 也手工跟进了 APT 仓库,其他的镜像站依然是老样子。

供应商区域同步时间戳URL
阿里云中国2025-03-31https://mirrors.aliyun.com/postgresql/sync_timestamp
腾讯云中国2025-03-31https://mirrors.cloud.tencent.com/postgresql/sync_timestamp
火山云中国2025-03-10https://mirrors.volces.com/postgresql/sync_timestamp
华为云中国2024-01-02https://repo.huaweicloud.com/postgresql/sync_timestamp
清华TUNA中国2025-03-31https://mirrors.tuna.tsinghua.edu.cn/postgresql/sync_timestamp
浙江大学中国2025-03-31http://mirrors.zju.edu.cn/postgresql/sync_timestamp
中科大中国直接下架https://servers.ustclug.org/2025/05/wine-postgresql-removal/
TrueNetwork俄罗斯2025-01-31http://mirror.truenetwork.ru/postgresql/sync_timestamp
JAIST日本2025-03-31https://ftp.jaist.ac.jp/pub/postgresql/sync_timestamp
DOTSRC丹麦2025-03-31https://mirrors.dotsrc.org/postgresql/sync_timestamp
MirrorService英国2025-03-31https://www.mirrorservice.org/sites/ftp.postgresql.org/sync_timestamp
普林斯顿大学美国2025-03-31https://mirror.math.princeton.edu/pub/postgresql/sync_timestamp
YANDEX俄罗斯2025-08-13https://mirror.yandex.ru/mirrors/postgresql/
XTOM德国2025-07-24https://mirrors.xtom.de/postgresql/
PIGSTY中国2025-08-14https://repo.pigsty.cc/

镜像站的“断更”
#

比如,17.5 等5月更新版本修复了 CVE-2025-4207 GB18030 相关漏洞, 而今天刚刚发布的 17.6 系列版本 更是修复了 3 个 CVE 和 55 个 BUG。如果你是镜像站的用户,那么就没法及时更新跟进打补丁了。更别提下个月即将发布的 PostgreSQL 18 新大版本了。现在还属于问题早期阶段,也就落后两个 PG 小版本,但很快再过一个月就会落后一个大版本。然后各种积累的漏洞补丁,安全修复国内用户全都用不上,产生的暴露风险会越来越大

从这个角度上来说,上游软件供应链停止对下游提供更新,本质上确实符合 “断供” 的定义。不过 PGDG “断供” 的理由也还算充分 —— 他们上 CDN 了嘛。

PGDG为何“断供”
#

PostgreSQL 邮件列表里,5月20日有韩国镜像站的维护者问过这个问题,之前用 rsync 同步 PGDG 官方仓库怎么突然断了?

Davaid Page 给出的解释是,ftp/rsync 从来就不是官方承诺提供的服务方式。PGDG YUM/APT 仓库也就两台物理机,每天却有 10TB 的访问流量,很多都是“非法流量”, 带宽要受不了啦!所以他们就把这个仓库给托管到了 Fastly CDN 上。

他们的想法也很显然 —— 我都用了 CDN 了,那专业 CDN 的节点和体验,不比零星的镜像站好多了?官方可以有能力绕过镜像站直接对全世界用户提供服务, 那还要啥镜像站?于是就把 FTP rsync 给关掉了,只能通过 HTTP 访问。看上去确实也没毛病,虽然断了镜像站同步,但也提供替代解决方案了 —— 直接用官方 CDN 就好了,也算是合情合理。

—— 你可以选择不用任何镜像站,直接使用 PGDG 官方仓库(他们刚搬到 Fastly CDN上)。

中国被卡脖子了?
#

镜像同步中断,对于世界上绝大多数地区的用户来说,其实影响还相对较小,因为他们总是可以去用 PGDG 新的 CDN 。但唯独对中国来说,这就等效于制成品断供了 —— 因为众所周知的原因,中国访问不了这些 CDN 节点!如果这些镜像站不更新,中国用户就没的用了!

当然,你要是自己翻墙用什么的还是可以用的。但是你显然不能指望人人都会这个,而且即使翻了速度也还是很慢的。所以国内的镜像站对于国内用户使用 PostgreSQL 来说依然是至关重要。 (也别说 Docker ,DockerHub 也被墙了,而且绝大多数 Docker Postgres 镜像也是从 APT 仓库里安装的…)

从这个角度来说, 中国用户这还真是被卡了一把脖子 —— 虽然本质上属于搬起石头砸自己的脚 —— 人家只是把增量的同步给关掉了,然后你用不了人家提供的替代解决方案而已。 但这个事情已经是这个样子,重要的是在这种背景下如何解决用户的问题。谁来解决这个问题呢?

中国用户想要 YUM/APT 安装 PostgreSQL 一般只能通过国内的镜像站来安装,最知名的应该是阿里云和清华大学的Tuna镜像站,当然还有浙大/中科大的源。不 幸的是,这些镜像站无一例外全都躺平了,并没有体现出担当来 —— 但你也没法怪他们,毕竟免费嘛。

供应链风险
#

开源专家 Tison在他的公众号文章《如何安心使用开源软件?》和 《开源软件有断供的风险吗?》深入解释过,开源软件(源代码)本身是没有所谓 “断供” 风险的 —— 开源协议授予的一系列基本权利是不可撤销的,在这个维度下**“开源断供”从未发生过**。对断供的担忧往往是对开源软件过度期待带来的误解。

但是用户对开源的依赖总是发生在具体的软件供应链上,保障开源依赖的供应链安全是有成本的 —— 开源制成品,也就是二进制软件包(RPM/DEB/镜像),以及开源制成品的交付渠道 —— 软件仓库(APT/YUM/Registry)是存在断供风险的。

原因也很简单,这都是有成本的,谁来支付这个成本是一个大问题。开源开发者愿意支付大头的研发成本,很多时候是因为这个事对他们来说是一种有趣的娱乐。 然而分发,打包,构建仓库,提供持续稳定的企业级服务与供给很大程度上是一种纯负担。比如国内一个GB流量卖你8毛钱,那你 PGDG 一天10个TB流量,一天就是几千块钱,对吧。所以你看能搞开源镜像站的基本上要么就是高校要么就是大型互联网厂商,第一自己也要用,第二加双筷子没啥流量成本。

反过来说,这些使用开源软件的用户像 PGDG 和开源软件镜像站付费了吗?嘿,没有,所以老实说,无论是从法律上,道义上,还真没法苛责什么,因为这就是开源的 STYLE —— 没有质保 —— 毕竟人家也没收钱,提供源代码是本分,但开源协议可没有规定说要提供开源软件二进制制成品,开发者和开源软件镜像站没有义务去做这种慈善。

如何解决供应链风险?
#

那么商业服务可以解决这个问题吗?毕竟,这么多国产数据库都是基于 PG 换皮,套壳,魔改弄出来的子孙后代,结果上游老祖宗被 Ban 了,确实有些滑稽,就没有人出来搞个中国的镜像站吗? 嘿,可能还真没有 —— 大部份情况下,这些数据库厂商都是直接白嫖镜像站(阿里云,清华)仓库的,或者说,交付方式甚至都不是软件仓库,而是丢给你一个 EL7 RPM 包,根本没有能力维护软件仓库。

老冯自己独立维护了一个 PostgreSQL 扩展仓库,里面包含了 9 种风味的 PG 内核,以及两百多款 PG 扩展(加上 PGDG 的总共 423 个可用扩展)。目前是 全世界 PG 生态收录最多可用扩展制品的仓库了。 不谦虚的说,说起 PostgreSQL 打包构建,我和 Devrim(YUM 仓库),Christoph(APT 仓库),Álvaro(OCI 仓库),David Wheeler(PGXN) 是这个赛道的顶级玩家与原始供应者。

但虽然我会打包构建,维护仓库,但是,在安装交付 PG 原生内核的时候,我还是会选择使用 “PG官方” 的 PGDG APT / YUM 仓库,PIGSTY 自己的仓库作为扩展补充仓库, 因为 Devrim 和 Christoph 已经干的足够好了!我会去做和他们工作有差异互补的事情。所以对于老冯的 PostgreSQL 发行版 Pigsty 来说,PGDG 仓库是 PIGSTY 的供应链上游, 国内区域因为有墙,阿里云镜像站是老冯的间接上游。现在的问题是这个间接上游,包括阿里云,清华,浙大,各种云在内的所有镜像站,全都趴窝断更没得用了,怎么办呢?

老冯在发现这个问题的时候,第一时间就给阿里云和清华TUNA的邮件列表上报了这个问题,也跟德哥聊过说过。不幸的是,几十天过去了,依然毫无波澜,没有丝毫动静。 就是没人有这个担当,能站出来解决这个问题。老冯对国内这些云厂商和数据库厂商和高校镜像站的维护团队真的非常失望。但你也没法说人家 —— 对吧,人家毕竟是免费给你用的,你能说什么呢?

我行我上
#

所以老冯也懒得再啰嗦,直接自己动手就上了。其实动手了我才知道,这才多大点屁事和工作量? —— 人家不给你开放 ftp rsync 同步,那你就用 apt-mirror 和 reposync 直接从 HTTP 通道去同步不就行了?老冯昨天用 Claude Code 花了两个小时,写了个同步流程,把 PGDG 的 YUM / APT 仓库给拉了下来, 丢到 Pigsty 的仓库里,然后测试了一遍,非常顺滑。我干完之后的感想就是 —— 就这?这么屁大点儿活,就给国内卡成这样?草台班子理论诚不欺我。

当然PG仓库总量大几百个 GB,如果全部弄下来就太大了,我就只要了 Linux x86 / aarch64 架构的包,同步了 Debian 11/12/13 ,Ubuntu 22/24 , EL 7/8/9/10 这几个主要 Linux 操作系统发行版大版本下的 PG 13 - 17 的包,然后只保留最新的版本,这样总大小就只有几十个GB 了。 拉了两个小时,同步回来,丢到国内 CDN 上,然后目前在 pig 0.6.1 和 pigsty 3.6.1 中,我已经把阿里云和清华源换掉了,会在这两天发布,彻底摆脱躺平摆烂的中间商依赖,实现真正的自主可控。

目前这个仓库和 Pigsty 本身一样,都是开源免费的。直接使用 Pigsty 肯定是自建 PostgreSQL 服务的更佳选择,但你确实也完全可以直接使用这里的 APT / YUM 镜像仓库。 直接对公众用户开放会有不少流量成本,不过老冯应该还是兜得住的 —— 虽然开源的本质就是无质保,但好在老冯向客户们承诺长期持续维护这个镜像仓库,所以免费用户也可以搭搭便车。如果有人想要赞助(服务器,CDN,打钱),老冯也非常欢迎。

curl https://repo.pigsty.io/pig | bash 
pig repo add pgdg  # 添加 PGDG 仓库

这让老冯回想起一些往事,两年前老冯想要把 PG 扩展搞进来,但是想要偷懒借力,我看到有个叫 Tembo 还有 pgxman 的公司尝试在做 PG 扩展包管理器, 我就等啊等啊等了几个月,等到最后发现他们纯粹是光吹牛不干活,老冯就不等直接自己上了,做了 pig 包管理器,pg 扩展目录和扩展仓库,现在成为了 PG 生态最大的扩展仓库。 就好比像 Omnigres 和 Autobase 这样的开源 PG 发行版/项目,也都使用 老冯维护的 Pigsty 扩展仓库,向他们的客户去交付。老冯的软件仓库也开始成为别人的供应链的上游了。

“开源” 确实并不要求你向用户提供可靠稳定的二进制制成品,但真正重要的不是开源,而是信任,开源只是构建信任一种形式,持续的投入,交付的承诺,专注的热情, 面对问题的担当。 想要成为值得信赖,受人尊敬的社区参与者,有许多东西比丢一份源代码到仓库要重要的多。

相关文章

卡脖子:PGDG切断镜像站同步通道
·1362 字·3 分钟
PGDG 切断 FTP rsync 同步通道,全球镜像站普遍断连,这次还真是卡了一把全球用户的脖子。
PostgreSQL 宏观查询优化之 pg_stat_statements
·9190 字·19 分钟
查询优化是 DBA 的核心工作内容之一,本文介绍了如何使用 pg_stat_statements 提供的指标,针对 PostgreSQL 进行宏观查询优化。
如何用 pg_filedump 抢救数据?
·5132 字·11 分钟
备份是DBA的生命线 —— 但如果你的 PostgreSQL 数据库已经爆炸了又没有备份,那么该怎么办呢?也许 pg_filedump 可以帮到你!
PG中的本地化排序规则
·5067 字·11 分钟
什么?不知道COLLATTION是什么,那记住一件事,用C COLLATE准没错!
PostgreSQL 逻辑复制详解
·13946 字·28 分钟
本文介绍PostgreSQL 13中逻辑复制的相关原理,以及最佳实践。
PG慢查询诊断方法论
·3264 字·7 分钟
慢查询是在线业务数据库的大敌,本文介绍了使用监控系统定位诊断慢查询的一般方法论。