聊聊分散式資料庫中單節點故障的影響

分散式資料庫中單節點故障的影響?

分散式資料庫中，當存在節點異常時(物理故障異常當機、系統資源導致HANG)，在故障恢復過程中，是否對應用有感知，如果應用有感知，影響時間大概多長時間，大家可以針對一些主流的分散式資料庫產品聊下。

問題來自社群會員@leiou0410 某銀行DBA，以下內容來自社群會員探討

@zhanxuechao 數字研究院 諮詢專家：

分散式資料庫部署的時候一般採用叢集、多副本的方式，理論上單節點故障對應用是無感知的，最多隻會丟一個包，自動連線即正常。

@anikikong 中國民生銀行 資料庫運維工程師：

這個屬於分散式資料庫的強項，單節點異常的恢復通常能做到分鐘級甚至秒級。對於應用完全無感知是不可能的，至少當前的事務會失敗。這個我覺得在各種分散式資料庫間差距不是很明顯，屬於分散式的強項之一。

@wangzk0206 scrcu 資料庫管理員：

分散式資料庫的高可用一般都是採用多數派協議實現的，單節點故障(少於多少派的情況下)都會自動切主，對業務感知是透明的。估計會有個別當時執行的事務出現回滾等現象，體現在tps上也就是突然掉下去一點，但隨後立馬恢復。

但是針對系統資源導致HANG這個故障場景，可能一般資料庫感知都可能存在問題吧，一般很難感知到。我所瞭解的OB在這方面具有租戶級別的資源隔離，當一臺伺服器資源使用過高的時候，可以透過OCP白屏(或者命令列黑屏)手工切主，將部分租戶的主切到另外資源使用率低的伺服器上，這樣原有的伺服器的資源利用率就會降低。

@huhu097 雲南紅塔銀行 DBA：

以下為本人親自測試結果，僅供參考：

@EastBrother 技術支援：

一般在做分散式資料庫規劃設計中，都會考慮分散式資料庫的高可用架構以及應急處置策略等。最基本的原則肯定是要具備單點故障無維護的能力，還有所選分散式資料庫叢集軟體的安全穩定效能力，一定要全面測試驗證，要避免分散式資料庫叢集軟體自身缺陷導致的爭搶資源或頻繁異常當機的情況。

在做分散式資料庫高可用架構規劃時，可能會考慮以下幾種方式：

1)單機房多副本，副本存放在不同節點中。該方案可以應對單節點故障，而且事務提交操作沒有跨機房日誌同步操作，對事務響應時間影響最小。在單節點故障情況下，資料不丟失，原故障節點對外提供的服務可能會有幾秒或幾十秒的影響，需要應用程式重新建立資料庫的連線。

2)同城三機房，每個機房一個資料副本。該方案可以應對單機房故障，事務提交操作需要在同城機房間進行日誌同步，對事務響應時間有較小影響。

3)兩地三機房，可以使用3個副本或者5個副本。該方案在應對單機房故障的基礎上，如果存放單機房的城市發生故障，資料也不會丟失;事務提交操作大機率在同城機房間進行日誌同步，對事務響應時間有較小影響;但一旦同城的兩個機房中一個機房發生故障，事務提交就需要跨城日誌同步，對事務響應時間有較大影響。

4)三地三機房，多使用5個副本。可以應對城市級故障。事務提交操作需要跨城進行日誌同步，對事務響應時間有較大影響。

分散式資料庫架構可以有多種組合方式，以上4種方案也不是絕對的。不過在分散式架構下要重點關注網路的架構規劃和時延情況，還要考慮業務系統的部署方案，比如對於可用性要求特別高的系統，可採用三地三機房方案將分散式資料庫系統部署到三地三機房中，業務系統也需要部署到將相應的三個機房裡，避免跨城資料庫訪問造成的效能損失;同時每一次事務提交需要跨城事務日誌同步，對響應時間有一定的影響，這種情況下一定要提前測試驗證好各種場景下網路延時或網路抖動對應用系統和對分散式資料庫的影響情況。