題干與適用場景
你維護一個高寫入 PostgreSQL 叢集，autovacuum 追不上膨脹，團隊希望在生產前測試 PostgreSQL 19 Beta。官方說明該版本仍可能調整，且新增 autovacuummaxparallel_workers 與新的 vacuum 優先級機制。請設計不影響現網交易的 Beta 評估方案。
面試官考察點
面試官考察你是否把 Beta 當作實驗而非免費升級，能否區分清理吞吐、I/O、鎖等待、查詢延遲和複製落後。高品質回答會限制實驗邊界、建立基線、處理失敗回滾，並說明何時不應進入生產。
回答前需要釐清的問題
- 膨脹主要來自哪些表、索引還是長交易？
- 當前 autovacuum worker、I/O、WAL 和複製延遲基線是多少？
- Beta 測試目標是縮短 vacuum backlog，還是驗證新優先級策略？
- 是否有可重建的唯讀副本和完整恢復演練？
30 秒回答
「我會先把 PostgreSQL 19 Beta 放在可丟棄副本或影子環境，記錄表膨脹、dead tuples、vacuum 時延、I/O、鎖等待、WAL 和複製延遲基線。平行 worker 先設小上限，只針對可控表做灰度，對照相同寫入回放。任何查詢 p99、複製延遲或 I/O 護欄超閾值就停止實驗並恢復舊版本；在 Beta 變為正式版本前不把結果當作生產承諾。」
分步驟深入解答
1. 明確 Beta 邊界
記錄版本、提交雜湊、編譯選項和設定；把新參數視為可能變化的實驗介面。生產叢集只保留可逆的副本或影子路徑，禁止直接把 Beta 當作正式升級通道。
2. 建立表級基線
按表記錄 dead tuples、膨脹、autovacuum 觸發間隔、單次耗時、索引清理比例、I/O、WAL、鎖等待和查詢延遲。識別長交易、頻繁更新表和大索引，避免用全庫平均值掩蓋熱點。
3. 選擇平行實驗單元
在隔離副本回放代表性寫入，先對一小組表啟用低平行度。比較單 worker 與平行設定下的清理吞吐、I/O 佇列、CPU、快取命中、WAL 和複製追趕時間。平行度不能超過儲存和實例預算。
4. 驗證優先級變化
記錄新評分或優先級機制選擇了哪些表，確認它沒有長期餓死低寫入但高膨脹的表。對長交易、分區表和大索引單獨觀察，因為它們的清理瓶頸不同。
5. 設定發布護欄
把查詢 p95/p99、交易錯誤、鎖等待、複製延遲、I/O 飽和、WAL 增長和 vacuum backlog 設為門檻。實驗期間保留舊版本可啟動映像、設定快照和恢復時間目標；護欄觸發後停止新表進入，不繼續提高平行度。
6. 回滾與結論
回滾先停止 Beta 寫入，等待或切換副本，保留診斷資料，再恢復舊版本和舊設定。比較完整實驗窗口的表膨脹、延遲、成本和故障次數。只有 Beta 迭代穩定、升級路徑明確且正式版本確認能力後，才制定生產計畫。
高品質示範回答
我會把 PostgreSQL 19 Beta 當成可丟棄實驗。先在影子副本回放真實寫入，按表建立 dead tuples、膨脹、vacuum 時延、I/O、WAL、鎖等待和複製延遲基線。平行 worker 從低上限開始，只覆蓋代表性熱點表，同時驗證新優先級是否造成飢餓。查詢 p99、複製延遲或 I/O 觸發護欄就停止實驗並恢復舊版本。Beta 期間不承諾生產相容；只有正式版本和恢復演練通過後，才進入分階段升級。
常見錯誤
- 把 Beta 直接部署生產 → API 和行為仍可能變化 → 使用影子環境並記錄版本。
- 只看 vacuum 吞吐 → 查詢和複製受到傷害 → 同時看延遲、I/O、WAL 和複製。
- 全庫同時提高平行度 → I/O 峰值和鎖競爭擴大 → 按表、按副本灰度。
- 忽略長交易 → dead tuples 仍無法清理 → 把交易年齡納入基線。
- 沒有退出路徑 → 失敗後只能停機 → 預留舊映像、設定和恢復演練。
追問及應對
為什麼不能只在測試資料上驗證？
測試資料無法重現真實更新比例、索引規模和長交易。至少要在隔離副本回放去識別後的生產寫入分布。
平行 worker 越多越好嗎？
不是。清理吞吐可能提高，但 I/O、CPU、WAL 和複製壓力也會增加。平行度必須受實例預算和延遲護欄約束。
如何發現優先級策略餓死某些表？
記錄每張表被觸發、開始和完成的時間，按寫入量與膨脹量分層比較；持續未被選中的表應觸發告警和人工檢查。
什麼時候停止 Beta 試驗？
當主要目標沒有改善、護欄反覆觸發、回滾不可重複，或正式版本時間表不確定時停止擴大範圍，保留資料等待後續版本。