昨天接到一個咨詢的活兒，有位 Pigsty 的用戶反饋數(shù)據(jù)庫故障，出現(xiàn) XID Wraparound 了。這個 PG 中最臭名昭著的故障在近些年已經(jīng)比較少見了，不過這次的故障原因確實(shí)比較有趣，是因?yàn)槭褂昧?TimescaleDB Hypercore 導(dǎo)致的 —— 這是一個實(shí)驗(yàn)性的新存儲引擎，并且已經(jīng)在最近的版本中棄用與移除。

如果你正在使用這個新的存儲引擎，最好立刻檢查并退回經(jīng)典的 TimescaleDB 引擎與 PostgreSQL 原生表，以免數(shù)據(jù)庫爆炸。

Hypercore 是什么

TimescaleDB 是一個老牌 PostgreSQL 擴(kuò)展插件，是 PG 生態(tài)復(fù)雜度最大的幾個擴(kuò)展之一（約20萬行代碼）。提供了時序數(shù)據(jù)處理分析，列式存儲，流式聚集，歸檔壓縮，定時任務(wù)等實(shí)用特性。

在今年年初，TimescaleDB 推出了一個新的混合行列式存儲引擎 Hypercore。它的設(shè)計(jì)目標(biāo)是服務(wù)實(shí)時分析場景，能夠在行存和列存兩種存儲格式之間自動切換，以同時滿足高吞吐寫入和快速分析查詢的需求。具體來說，Hypercore 以行存形式接收最新數(shù)據(jù)，保證寫入和更新的低延遲；隨著數(shù)據(jù)“冷卻”不再頻繁更新，系統(tǒng)會自動將其轉(zhuǎn)換為列存進(jìn)行壓縮存儲，以加速聚合查詢并節(jié)省存儲空間。

TimescaleDB 的經(jīng)典引擎提出了 Hypertable 和 Chunk 的概念，這些表看上去都是 PostgreSQL 原生堆表，需要通過一系列函數(shù) API 進(jìn)行管理。而 Hypercore 則利用了 PostgreSQL 12 新引入的 TAM （表訪問方法）接口，將其實(shí)現(xiàn)為一種新的存儲引擎，而且支持為壓縮數(shù)據(jù)使用 Btree 二級索引加速訪問。整體在使用上更加絲滑便利，省掉了行/列存轉(zhuǎn)化，壓縮/解壓縮的管理負(fù)擔(dān)。

然而……

當(dāng)然，并不是所有的事情都像文檔上描述的那么美好。Hypercore 在 2025-01-23 的 2.18.0 被第一次提出，然而僅僅在 2.21.0 就被標(biāo)記為棄用，隨即在 2.22.0 版本中被直接移除，整個生命周期也就半年多。

超核訪問方法的棄用[1] 我們決定在 2.21.0 版本中棄用超核訪問方法 (TAM)。這是一個實(shí)驗(yàn)特性，它沒有顯示出我們希望的信號，并將在計(jì)劃于 2025 年 9 月發(fā)布的 TimescaleDB 2.22.0 中棄用。如果您仍在使用 TAM，則無法升級到 2.22.0 及更高版本。自從2.18.0[2]推出 TAM 以來，我們了解到 btree 并不是合適的架構(gòu)。列存儲的最新進(jìn)展 - 例如性能更高的回填、SkipScan、添加檢查約束和更快的點(diǎn)查詢 - 使列存儲[3]接近或與 TAM 相當(dāng)，而無需來自附加索引的存儲。對于此操作可能造成的不便，我們深表歉意，并在此為您提供遷移過程中的幫助。

當(dāng)然，棄用公告里并沒有詳細(xì)解釋廢棄移除這個存儲引擎的具體原因，不過真實(shí)用戶踩雷倒是讓我知道了 WHY。這個存儲引擎沒有處理好垃圾回收，會導(dǎo)致 PostgreSQL 數(shù)據(jù)庫因?yàn)?XID Wraparound 直接宕掉。

具體案例

大體過程是這樣的，用戶遇到了 XID 回卷故障，PostgreSQL 提示還有 300萬個 XID 就回卷了，進(jìn)入保護(hù)模式拒絕寫入。只讀負(fù)載還可以工作，業(yè)務(wù)降級為只讀模式。

這個案例運(yùn)氣比較好，數(shù)據(jù)庫還活著，可以執(zhí)行只讀 SQL，所以先趕緊抽取了一個邏輯備份。然后一看，年齡花了幾個月增長到20億（一看就是不看告警…），再看是幾個 TimescaleDB Chunk 表年齡把整個集群的年齡撐高的。再一看，這幾張表竟然用的是 hypercore 存儲引擎，Vacuum 直接報(bào)錯。

當(dāng)然要解決這個問題，其實(shí)把這個表 DROP 了，或者硬改系統(tǒng)元數(shù)據(jù)其實(shí)就好了。但尷尬的是 PostgreSQL 進(jìn)入保護(hù)模式，不允許寫入操作，最多允許你跑 VACUUM FREEZE，這就死循環(huán)了。所以最快恢復(fù)的辦法就直接用 Pigsty 拉起了一個新集群，把 hypercore 表 DDL 修改成 timescale 的經(jīng)典表，然后 pg_dump | psql 數(shù)據(jù)拉過去。業(yè)務(wù)切換到新集群，解決了這個問題。

順帶一提，如果你的 PG 要炸了，老馮可以提供遠(yuǎn)程咨詢問診哦。

經(jīng)驗(yàn)與教訓(xùn)

總的來說，老馮覺得這個案例再次告訴我們新特性上生產(chǎn)要謹(jǐn)慎。hypercore 這種實(shí)驗(yàn)性的存儲引擎雖然在性能和易用性上帶來一些亮眼的改進(jìn)，但是在質(zhì)量/安全性上的關(guān)鍵缺陷讓前者失去意義。

對于存儲引擎這種關(guān)鍵，核心，高復(fù)雜度的組件模塊，老馮認(rèn)為再小心也不為過，因?yàn)樗鼈冞€沒有長時間，大規(guī)模運(yùn)行的社區(qū)可靠性認(rèn)證記錄，很多問題kennel只有在復(fù)雜的真實(shí)場景中才會出現(xiàn)。更重要的是，存儲引擎缺陷通常更有可能傷害到數(shù)據(jù)完整性，殺傷力與風(fēng)險(xiǎn)通常比普通特性的缺陷要大的多。（類似需要注意的擴(kuò)展包括：，PG TDE 擴(kuò)展）。

上新的節(jié)奏

因此，很多人問我，應(yīng)該用什么 PostgreSQL 大版本合適，因?yàn)?PG 每年都會發(fā)布一個新的大版本嘛。老馮的建議是，如果你是在生產(chǎn)環(huán)境使用，普通的用戶可以使用上一個大版本 ： 比如 PG18 剛發(fā)布，那么當(dāng)下最合適的 PG 大版本會是 PG 17。有實(shí)力/愿意嘗鮮的客戶，老馮的建議是在 第二，第三個小版本（18.1，18.2）開始使用會比較合適，因?yàn)檫@個時候主要的擴(kuò)展支持都已經(jīng)到位，三到六個月的使用也基本能讓 BUG 充分暴露 —— 但是也有例外（比如 PG 14.3 才發(fā)現(xiàn)的索引損壞顯著 BUG ）。

當(dāng)然，如果你很有實(shí)力，有信心應(yīng)對各種問題，也可以始終使用最新版本與各種新特性。比如去哪兒網(wǎng)的李海龍帥龍同志，就會在 PG 每個大小版本剛出，就立刻把生產(chǎn)PG全部升級到最新。老馮會稍微保守（懶）一些，基本上會等一兩個小版本出來，再升級大版本。目前 Pigsty 的策略也基本上是等到出來半年，等 TimescaleDB，Citus 這些重磅三方擴(kuò)展都適配了，再提升默認(rèn)的大版本

所以，不少朋友都問我現(xiàn)在 PG 18 出來了你的 Pigsty 啥時候支持，其實(shí)半年前beta出來的時候就支持了，如果你沒有用到那些還沒適配 18 的擴(kuò)展插件，現(xiàn)在就可以用了。但真的要上生產(chǎn)，老馮覺得還是最好再等半年，畢竟，有時候吃螃蟹真的會拉肚子。

References

[1] 超核訪問方法的棄用: https://github.com/timescale/timescaledb/releases?page=1
[2] 2.18.0: https://github.com/timescale/timescaledb/releases/tag/2.18.0
[3] 列存儲: https://www.timescale.com/blog/hypercore-a-hybrid-row-storage-engine-for-real-time-analytics