嘗鮮須謹慎：PG新存儲引擎故障案例

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

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

Hypercore 是什么

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

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

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

然而……

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

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

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

具體案例

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

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

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

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

經(jīng)驗與教訓

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

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

上新的節(jié)奏

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

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

所以，不少朋友都問我現(xiàn)在 PG 18 出來了你的 Pigsty 啥時候支持，其實半年前beta出來的時候就支持了，如果你沒有用到那些還沒適配 18 的擴展插件，現(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