數據庫作為IT系統中最關鍵的服務之一，其可用性一直是系統設計中的重點考慮因素。同時，由于數據庫有數據有狀態的天性，數據庫高可用有其天然的復雜性和難點，云原生架構下尤其如此，是一個值得深入探討的課題。本系列文章將基于網易杭州研究院的研究與實踐，解析數據庫高可用技術要點，梳理主流數據庫方案，為數據庫技術建設規劃提供參考。

本文由作者授權網易云發布，未經許可，請勿轉載！

作者：倪山三，網易杭州研究院運維工程師

Catalog0. Prologue

1. 數據庫高可用技術要點1.1. 冗余設計 — 數據冗余方案

1.2. 冗余設計 — 冗余數據間的一致性

1.3. 冗余設計 — 實例冗余

1.4. 故障切換 — 服務角色

1.5. 故障切換 — 故障感知與應對

1.6. 故障切換 — 業務連接切換

2. 主流數據庫方案概覽2.1. 主流數據庫高可用功能概覽

2.2. MySQL數據庫高可用功能概覽

接上文：

1.4. 故障切換 — — 服務角色

1.1~1.3章節屬于高可用技術兩個核心點中的第一個議題, 實例和數據如何冗余的范疇, 也是一般意義上高可用方案的表皮, 大家都很關注的內容, 其技術實現相信大家多少有所了解. 而從1.4開始的3個技術要點屬于極容易被大家忽視的另一個核心議題, 假設服務和數據都有了冗余, 故障的時候要如何切換. 好比最開始的例子, 飛機有三條油路, 還得有自動切換功能, 不但如此, 萬一自動切換功能不能用了, 還得提供機長手動切換功能.

那么先來看第一個要點, 冗余實例間是否需要區分在集群中的角色.

1.4.1. 有集群角色

多個數據庫節點互相關聯組成一個集群, 集群對外提供內部高可用冗余和一定的性能擴展能力, 對內需要協調治理每個節點的功能分工, 也就是形成角色. 角色大致有幾類:主庫角色, 數據主題, 允許讀寫.

從庫角色, 從當前主庫同步數據, 通常最多允許只讀, 不允許寫入, 避免數據一致性風險.

根據整體架構差異, 部分數據庫會有沒有數據但是作為中間人監督參與其他節點角色選舉的角色, 例如MongoDB的arbiter, 在其高可用架構中也是非常重要的角色.

當然最常見的還是主從角色. 而且對于大部分數據庫來說, 就是一個集群允許有一個主, 然后多個從. Oracle (dataguard), redis (sentinel或cluster), MongoDB... 基本上所有shard nothing的架構都會對一個集群中的不同實例來區分主從, 主要是來定義當前哪個實例允許數據寫入. 而Oracle RAC, TiDB, HBase等shard data的方案中由于數據要么允許多實例共同讀寫, 要么數據被分片了避免了寫沖突, 因此通常不需要區分角色.

對于運用最普遍的shard nothing架構中, 數據庫高可用場景下, 數據一致性風險主要來自于故障或切換過程中, 業務對多個節點的同時修改數據造成的數據沖突和丟失. 角色正是起到了防止這一風險的目的, 集群應當只有主角色可寫.圖28, shard nothing典型的主從角色分工, 一份寫, 從不可寫只允許讀, 這樣數據一致性才有保證.

角色相當重要, 有角色就意味著集群內部有治理機制, 會做選舉. 這是避免數據庫集群腦裂的重要前提條件之一, 設置為不可寫角色(從)相當于實現了IO fencing, 這部分在1.5章節中會繼續展開.圖29, 上面是Oracle v$database數據字典中記載的角色, 下面是MongoDB replicaset元數據輸出, 這個分工是經過集群協商, 有共識的. 有角色意味著節點間有通信, 能夠區分讀寫分工, 這是集群高可用可靠性的重要保障之一. 如果沒有角色, 那么選舉, 防腦裂, IO fencing就都要外部工序來保證, 根本談不上集群.

那作為線上運用最廣泛的MySQL的情況? 這里的角色指的是集群通過內部節點間協商得到的合理的主從身份分配. 而傳統意義上的MySQL就是真的沒有這個機制. 雖然大家都知道MySQL有主有從, 但是傳統MySQL是沒有集群概念的, 主從是一個松散的配置概念, 是運維人員外部賦予的, 并非集群屬性. 除了日志傳輸外MySQL主從間幾乎沒有其他任何關聯, 對數據一致性缺乏保障. 你可以對MySQL復制鏈路的任何節點開啟寫, 并修改數據, 直到數據冗余因為沖突徹底癱瘓. 傳統MySQL不組集群, 不通信, 不選舉, 不區分角色, 一切都交給外部框架或中間件完成, 這方面來看, 其功能設計對高可用和數據一致性需求的支持可以說非常簡陋.

但是現狀也在改變, MySQL在5.7以及8.0中引入的MGR(mysql group replication)架構, 實現了集群內部通信, 協調選舉, 區分角色的功能, MGR可以說是對MySQL高可用機制可靠性上的一次重要飛躍.圖30, MGR示意圖, 多個MySQL實例間終于形成了通信和數據一致性保障機制. 這個圖一會兒可能還會出現.

MGR實際上也允許不區分角色做multi master多活, 利用樂觀鎖和沖突檢測防止事務沖突, 但是真正有價值的我認為還是single master模式, 從角色強制不可寫. 現在的主要問題是, MGR推廣進度不算快, 作為線上存儲數據最多, 功能最重要的數據庫MySQL, 我認為MGR技術推廣落地是非常重要的, 是接下來需要重點推動的關鍵工作.

1.4.2. 無集群角色

除了shard data架構的那批不需要區分可寫節點的服務外, 還有什么主流數據庫是沒有角色的? 傳統MySQL和postgreSQL是這樣的, 只能通過引入外部中間件, MHA, clustercontrol等, 來松散定義集群, 集群內的節點并不嚴格區分角色, 稍有不慎就出現主從數據不一致, 高可用切換后服務腦裂等問題, 是非常不健康的架構.

未完待續

推薦閱讀：

總結

以上是生活随笔為你收集整理的数据库mysql工序_网易杭研总结：数据库高可用技术之道（4）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。