Date: 20 9 月, 2026
接地氣：錯過Percona Live Amsterdam讓我對HA有了哪些新的認識
坐在機場的地板上，眼睜睜地看著出發航班資訊牌因為關鍵系統故障而變成一片紅色的取消航班，而你這週的日程安排卻是全力以赴地維護數據庫的高可用性，這真是莫大的諷刺。
與其在 Percona Live 大會上一邊吃著焦糖華夫餅一邊討論同步複製與異步複製、災難恢復策略和連接路由等問題，我不如花幾個小時觀看英國空中交通管制基礎設施實時演示系統故障時會發生什麼。
當中央飛行處理系統發生故障時，飛機不會墜毀…人工操作員會手動降低處理能力以確保安全。這對於航空電子設備來說是良好的工程設計。但從操作和使用者角度來看，吞吐量會立即降至零。
在資料基礎設施領域，我們沒有條件對交易進行接地處理。
單點故障剖析
一個系統可以擁有分佈在三個可用區的冗餘硬體、雙電源以及昂貴的供應商合約。然而，如果所有流量都通過單一狀態協調器、集中式配置攝取管道或共享控制平面，那麼你擁有的就不是分散式系統，而是一個代價高昂的分散式單點故障（SPOF）。
當飛行處理流程因輸入格式錯誤或集中式狀態偏差而阻塞時，主節點和輔助節點通常會同時觸發安全模式鎖定。在我們的系統中，這相當於：
- 裂腦情景當兩個主資料庫節點鎖定表或退出仲裁以防止資料損壞時，就會發生這種情況。
- 健康檢查協調器將網路延遲誤判為完全故障，導致主連線頻繁切換，直到連線池耗盡。
- 一個備份集群，能夠在幾毫秒內忠實地複製損壞的元資料或毒丸交易。
冗餘只是指擁有兩份相同的東西。而彈性則是指知道備用件不會重蹈覆轍。
真正的HA需要什麼
如果你的系統在凌晨 2 點主路徑突然中斷後，無法在無人幹預的情況下繼續運行，那麼你並沒有實現高可用性，而只是擁有了一個連接在焦慮的工程師身上的警報系統。
- 基於法定人數的共識制應對脆弱的初選：依賴簡單主動/被動複製和手動 DNS 故障轉移的系統極易導致停機。現代集群（無論是使用 Galera、群組複製或 Raft/Paxos 等共識協議）都需要奇數個節點和法定人數，以確保自動、安全地選舉領導者，避免腦裂。
- 智慧交通脫鉤：應用程式絕不應直接指向資料庫節點的硬編碼 IP 位址。七層代理程式、智慧連線池（例如 ProxySQL）和虛擬 IP 將應用程式用戶端與底層基礎架構的頻繁變更隔離。如果節點 A 發生故障，節點 B 會接管寫入操作，應用程式只需不到一秒鐘即可完成重新連接，而不會完全中斷。
- 隔離故障域：真正的高可用性 (HA) 會隔離輸入。如果包含致命查詢或格式錯誤的設定封包進入系統，則必須將其隔離。如果主節點在執行過程中崩潰，故障轉移不應自動將完全相同的致命查詢重播到備用節點上，從而導致整個叢集宕機。
- 重在鑽探而非文檔：如果你還沒有在模擬網路分區和高負載條件下測試過自動故障轉移，那麼你的故障轉移計畫就只是一個假設。
總結
錯過阿姆斯特丹的走廊巡演和現場演示令人遺憾。但凝視著停滯不前的機場航站樓，卻讓我更加深刻地意識到：停機時間絕不是 Grafana 儀表板上的抽象指標。它會導致真實的人員滯留、營運中斷，並摧毀信任。
做好容錯設計。實現故障恢復自動化。測試集群。
作者Aaron West，SIOS 銷售工程師
經許可轉載SIOS