第六章：實戰案例 — 資料庫在野外

1. 簡介

理論是完美的，但現實是殘酷的。本章不再討論新的資料結構，而是透過三個真實的「戰情室 (War Room)」案例，展示當資料庫底層機制（交易 ID、索引膨脹、鎖定競爭）在極端負載下失效時會發生什麼。

2. 案例一：Sentry 的交易 ID 耗盡災難 (2015)

目標：Sentry (錯誤追蹤平台)。 核心機制：PostgreSQL 的 Transaction ID (XID) Wraparound。

故障現象： 突然之間，Sentry 的主資料庫拒絕所有寫入操作，系統進入唯讀模式，導致服務全線中斷。

底層原因：

1. 32 位元限制：PostgreSQL 使用 32 位元整數作為交易 ID（約 40 億個）。
2. 可見性機制：為了判斷數據版本，Postgres 必須保留舊 XID。當 XID 用完一圈 (Wraparound) 時，舊數據可能會變成「未來的」數據，從而變得不可見。
3. 強制停機：為了防止數據損修，Postgres 設有一個安全閾值。一旦未清理 (Vacuum) 的交易超過 20 億，資料庫就會強制停止寫入，直到管理員手動介入。
4. Autovacuum 失效：Sentry 的寫入量過大，導致背景的 Autovacuum 行程趕不上清理 XID 的速度。

修復與教訓： 必須密切監控 age(datfrozenxid) 指標。對於寫入極其頻繁的表，必須激進地調整 Autovacuum 參數，或者進行水平分片。

3. 案例二：Shopify 的「閃購」鎖定競爭

目標：Shopify (電商平台)。 核心機制：MySQL 的 Record Lock (行鎖) 與熱點更新。

故障現象： 在「黑五」大促期間，儘管資料庫 CPU 和 I/O 均未跑滿，但某些熱門店舖的下單介面回應時間飆升至數十秒。

底層原因：

1. 熱點行更新：成千上萬的用戶同時嘗試更新同一行記錄（例如減少某商品的庫存）。
2. 序列化執行：InnoDB 必須對該行加行鎖 (Record Lock)。這意味著成千上萬個並發請求被迫序列化執行。
3. 佇列積壓：資料庫內部的鎖定等待佇列 (Lock Wait Queue) 迅速爆滿，導致內核切換 (Context Switch) 開銷超過了實際執行 SQL 的開銷。

修復方案： Shopify 並沒有試圖「優化」資料庫鎖定（因為物理定律不可違背），而是透過 Redis 在應用層做庫存預扣減（Lua 腳本），只有成功的請求才會被非同步寫入資料庫。 教訓：不要試圖用關聯式資料庫解決「秒殺」問題。

4. 可視化：鎖定競爭導致的吞吐量崩塌

graph TD
    subgraph HappyPath [正常負載]
        A[請求 1] -->|加鎖| DB[(行記錄)]
        B[請求 2] -->|加鎖| DB
        Note1[並發處理良好]
    end

    subgraph Meltdown [高並發鎖定競爭]
        C[請求 1] -->|持有鎖| DB2[(熱門行)]
        D[請求 2] -.->|等待| C
        E[請求 3] -.->|等待| D
        F[請求 1000] -.->|等待| E
        
        Note2[吞吐量非線性下降<br/>CPU 浪費在內核切換]
    end

5. 案例三：GitLab 的數據恢復噩夢 (2017)

目標：GitLab.com。 核心機制：Replication Lag (複製延遲) 與 Backup Reliability。

故障現象： 一名運維工程師試圖修復從庫延遲問題，誤在主庫執行了 rm -rf 刪除了數據目錄。在嘗試恢復時，發現：

1. pg_dump 備份失敗，因為版本不相容。
2. 磁碟快照 (LVM Snapshot) 從未啟用。
3. 雲端備份機制失效（如備份腳本未正確配置或驗證）。

底層啟示： 這雖然是人為錯誤，但暴露了對資料庫物理複製 (Physical Replication) 與 邏輯備份 (Logical Backup) 區別的忽視。物理複製（如 WAL 日志傳輸）是即時的，但也會即時同步「刪除」操作。邏輯備份才是防止人為誤刪的最後一道防線。

6. 總結

掌握 B+Tree 和 LSM-Tree 的原理只是開始。真正的資料庫專家，是在凌晨 3 點系統崩潰、監控紅燈閃爍時，能夠透過現象看到底層 XID 耗盡 或 鎖定佇列溢出 的人。

保持敬畏，永遠不要停止對 EXPLAIN ANALYZE 的探索。

7. 參考資料

• Sentry: Transaction ID Wraparound in Postgres
• GitLab.com Database Incident Post-mortem
• Shopify Engineering: Surviving Flash Sales