雲資料庫高可用解決方案技術解析

02-04

高可用，英文翻譯為」High Availability」.

從字面上理解就是要做到服務的full-time的持續可用，但老實說，要做到full-time是不現實的，因為能夠影響系統服務可用性的因素實在是太多了，除了軟體BUG、硬體故障外還包括系統所依賴的一些第三方服務（如運營商提供的帶寬），甚至還包括天災人禍等；因此我理解所謂的高可用意味著」更少的停服時間」，而工業界也有一套測量系統可用性的標準，即大家所熟知的SLA(Service Level Agrement)，也就是幾個9的可用性（如下表）：

在工業應用場景中，如當下做在線服務的各大互聯網公司，號稱7*24小時的不間斷服務，想想如果只是達到一個9的可用性將會是一種什麼樣的災難；而要做到5個9的可用性就意味著全年只有一次服務宕機，而且得在5分鐘左右就恢復，其中的難度也是不言而喻的，我想只是採用技術手段不足以做到，還需要通過一整套完備嚴謹的工程管理防範及配套工具、優秀工程運維人員等。

雲計算號稱互聯網公司的水和電，高可用猶如雲服務商的生命線，而雲資料庫作為該領域的一項重要服務更是接受著不同維度的考驗，因為雲端成千上萬個用戶資料庫實例所面臨的問題會更加五花八門。

下面將先介紹Mysql領域幾個典型的高可用解決方案，分析其中的關鍵技術及適用場景，並在此基礎上介紹和分享UDB的高可用方案。

1. 高可用資料庫關鍵技術點

資料庫服務和很多工業服務在高可用技術方案是相通的，為了實現高可用首先實現服務的」冗餘」，即服務的集群化，如果服務有冗餘備份，宕機後還有其它備份服務(熱備和冷備)可以頂上，所以實現資料庫服務的」冗餘」也是高可用資料庫的核心準則；而有了」冗餘」備份後還不夠，如果每次宕機都需要人工恢復切換至備份服務，恢復時間得不到保證，同時人為的故障恢復過程中可能會引入新的風險(人為事故)，從而降低了服務的可用性，因此必須還具備」自動故障轉移」功能。而資料庫服務相比於其它系統的高可用，在以上兩個關鍵技術點的實現上會更加的困難，因為傳統RDMS對數據和事務的持久性和穩定性是要求非高的，從也提高了對冗餘數據的一致性的要求和實現難度。

2. 高可用Mysql典型解決方案

下圖是Oracle官方對Mysql幾種典型高可用方案及可用性的總結，由於時間相對較早並且隨著近幾年分散式一致性協議在工業界的實踐和發展，Mysql高可用方案又有了全新的發展方向以及相對成熟的方案，下面將一併羅列和解析。

Mysql Replication 就是通過Mysql原生的複製技術來實現數據的冗餘，該方案也是最易實現和通用的方案，相關的原理介紹網上介紹很多，這裡不再詳細贅述，實現原理主要是通過2PC來實現本地BINLOG和本地數據的一致性，並再此基礎上通過兩個線程(IO線程和SQL線程)來實現遠端數據和本地數據的同步，根據數據一致性程度不同複製技術又可以分為非同步複製、半同步複製以及同步複製，另外在此冗餘技術之上，一般會搭配使用MysqlProxy、keepalived、MHA等第三方軟體來實現自動容災，此技術方案如果不做一定優化，可用性一般不到2個9。
Mysql Fabric 是Oracle官方提供的一種Mysql高可用方案，通過數據分片下的讀寫分離模式，該方案的可用性達到2個9。
DRBD磁碟複製,分散式塊設備複製(Distributed Relicated Block Deivce,DRBD)，是一種基於軟體、基於網路的塊複製存儲解決方案，主要用於對伺服器之間的磁碟、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁碟時，還會將數據發送到網路中另一台主機的磁碟上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就可以保證實時同步，當本地主機出現問題，遠程主機上還保留著一份相同的數據，可以繼續使用，保證了數據的安全，該方案缺點是IO性能影響嚴重，可用性不到3個9。
Solaris Clustering，該方案代表這另一種技術方向，即以共享存儲為基礎,實現資料庫伺服器和存儲設備的解耦，這樣資料庫伺服器之間的冗餘與數據無關，而數據的冗餘則通過SAN共享儲存或者分散式存儲系統來實現，當然Solaris Clustering除此之外還提供了操作系統、硬體等各個層面的監控機制，該方案的可用性達到接近4個9，但是實現代價大，價格昂貴。
Mysql Cluster是官方提供的一個開源方案，其將Mysql的集群分為SQL節點和數據節點，數據節點通過一種內存中的存儲引擎來實現自動sharding和複製，雖然該方案號稱接近5個9的可用性，但是缺點也是很多，如對內存消耗大，使用成本高，犧牲了過多的SQL語言特性，配置複雜等。
基於PAXOS分散式一致性協議的方案，Paxos 協議主要多數派投票的方式，來就分散式系統中某個值達成一致，該演算法被業界認為唯一的分散式一致性演算法，包括其在內衍生出來的分散式一致性演算法（如Raft等）也在很多肯多開源分散式系統得到應用。Paxos與MySQL相結合可以實現在分散式的MySQL資料庫最終一致性從而保證高可用，而使用分散式演算法用來解決MySQL資料庫數據一致性的問題的方法，也越來越被人們所接受，一系列產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被應用到生產環境，而最近Oracle官方所推出的MySQL Group Replication的GA，更使其在Mysql高可用領域成為了一種民用技術；因此使用分散式協議和多副本來解決資料庫一致性問題已經成為了主流的方向。但是此類方案還出於初級階段，不夠成熟，同時分散式一致性協議由於網路開銷的原因在性能上還有待提高和優化。

3. 高可用資料庫案例分享--UDB

為了實現雲資料庫服務的高可用，UDB基於半同步複製技術採用雙主的熱備架構，為了實現故障自動轉移，並在此基礎上實現了Proxy模塊，該模塊不僅負責數據業務的轉發，同時還監控後端DB的健康狀況，雙主數據一致性檢測，並在後端DB宕機情況下，在不影響數據一致性的情況下，完成數據業務切換，整個架構及容災過程如下圖：

也許從架構上看很簡單，一主一備的架構沒有什麼新意，但是深入到細節中會發現有很多問題和難點,或者說這些問題都圍繞這一個目標，如何保證數據一致性。

普通的非同步複製對資料庫性能影響小，但是主從數據一致性難以保證；強同步複製雖然保證了主從強一致，但是可用性很差；因此udb選擇了折中的方案即半同步複製，但只是簡單的使用半同步複製還是不夠，通過分析半同步複製的過程和原理，會發現半同步複製會存在以下一些缺陷，下面將分析缺陷的同時介紹下udb的解決方案和策略：

1、臨界事務問題？

什麼是臨界事務，臨界事務就是在宕機那個時間點主庫正在提交的事務，這個事務可能已經提交，可能已經fsync到磁碟，但是確沒有同步到從庫中去，半同步複製對於臨界事務是沒法保證的，如下圖是myql5.7無損複製一次事務commit流程（udb基於次複製技術做了優化）：

如上圖，我們對5.7版本中的無損複製模式（默認模式下）的半同步複製的主機commit做了細分，拆成7個可能crash的階段，考慮到雙機切換後可能會導致的數據丟失和數據一致性異常，我們對每個階段有如下分析：

在階段1,2,3發生了crash，由於主庫重啟後事務會回滾，binlog未發送到從庫，所以不會發生異常。
在階段4發生異常，由於主庫進入了commit階段，但是binlog尚未發送到從庫。在主庫重啟後仍然會將這個事務發送到從機。
在階段5,6,7發生異常，由於從庫已經收到了binlog，只要主庫重啟後即可達到主庫和備庫數據一致的效果。

通過以上分析，無損複製模式下只有在階段4發生宕機會導致恢復後雙主數據不一致，因為當在此階段發生宕機，該事務並沒有發送至從庫，但是主庫已提交至Binlog和Redolog，如果此時業務切至從庫，主庫恢復後會繼續將事務commit並同步到從庫，但是由於從庫上已經有了新事務，很可能會和此事務產生衝突（如主鍵衝突），從而導致雙主數據不一致；為了解決此宕機時臨界事務問題，我們通過內核層面在主庫重啟recovery階段作了如下調整：有選擇性的commit並複製到從庫部分事務，回滾掉沒有同步到原從庫的事務及Truncate掉binlog中相應的event，整個過程如下圖：

如上圖所示，主庫在恢復後，會向從庫或者proxy詢問從本庫同步過去的最後一條事務的Binlog位置，並以此為基礎回滾掉該Binlog位置之後的臨界事務。

2、半同步退化問題？

由於網路抖動以及從庫硬體故障等問題會導致半同步退化為非同步，如果在此情況下主庫發生宕機並發生切換，會導致數據丟失，對於很多數據敏感的業務（如金融）後果是非常嚴重的；因此當半同步複製退化，整個集群是不可以容災切換業務的；但是如果主機宕機無法ssh登陸，我們又如何確定主從是否退化，從庫數據是否和主庫一致呢。

為了解決此問題，防止錯誤的切換導致數據丟失，UDB通過在proxy和mysql之間以及主從之間增加鏈接通道，proxy和myql會用專門的線程通過此鏈接通道同步事務信息，如果主庫發生宕機，從庫可以在本地緩存和遠端proxy獲取同步事務信息，並使用該事務信息作為從機是否可以切換的依據，如下圖：

同時為了提高可用性，應對短時間網路抖動後造成雙主長時間數據不一致，udb在網路恢復後，會額外啟動一個複製鏈路來追補落後的數據，而原半同步複製鏈路繼續用於複製實時事務，這樣不僅可以加快複製數據效率，而且避免了由於從庫負載過高永遠恢復半同步的風險。

3、如何保證proxy的高可用

通過以上問題及UDB相應解決方案的分析，大家可以看出Proxy在整個架構中扮演著極其重要的角色，不僅負責數據轉發，同時為數據一致性和可用性提高保障；因此大家一定會問如果Proxy宕機怎麼辦，為了解決Proxy高可用問題，UDB這邊對Proxy模塊也採用了一主一備模式，如下圖：

當圖中左路主Proxy宕機後，ProxyMaster模塊會觸發容災處理過程，此時ProxyMaster會將虛擬IP重新綁定至Proxy（backup）並自動啟動，啟動後Proxy（backup）會重新鏈路至原MasterDB，以保證業務不間斷，而ProxyMaster模塊通過ZK服務分布在多個伺服器上，有效的保證了Proxy的可用性。

當然除了該雙主技術架構外，為了保障服務的高可用，UDB在運維監控等層面也做了很多工作，通過對從硬體、操作系統、資料庫以及網路等各個層面的不間斷監控，從而最大程度的及時捕獲和恢復資料庫服務；同時UDB通過自研的大型資料庫備份系統，能夠應對各種級別的宕機故障後的數據恢復，從而保障了用戶數據的安全可靠性，這裡不做過多贅述，有興趣的同學可以參考《從爐石傳說資料庫故障看雲數據備份策略》這篇文章。

——————

其他閱讀推薦：

五大常見的MySQL高可用方案

我如何使用 Django + Vue.js 快速構建項目

一起學 Node.js | 使用 Express + MongoDB 搭建多人博客

本文由『UCloud存儲研發團隊』提供。

作者介紹
孫研，UCloud雲資料庫UDB團隊核心成員、高級研發工程師，帶領團隊對UDB底層架構進行重構，在內核方面對UDB性能和數據一致性等方面做了大量深入的工作。數年來深耕在雲資料庫領域，熱衷於開源、分享。

———徵稿的分割線———

如果你也有一些技術實踐經驗想分享給大家，歡迎投稿給我們：）

UCloud機構號將提供 300雲服務代金券贊助+500元/篇的轉載費+全技術渠道推廣資源！

你的文章將被更多技術同學閱讀、點贊、感謝、分享！

徵稿範圍

題材不限，與「技術」及「雲」相關即可，但文章不得少於500字，圖文並茂為佳。可以是：

不同雲廠商產品使用體驗及數據評測；
項目部署到雲平台前後數據分析對比；
雲上遷移/部署過程遇到的問題及解決方案；
其他雲上部署經驗；

……

作品提交鏈接：http://cn.mikecrm.com/fj6KmCu

「UCloud機構號」將獨家分享雲計算領域的技術洞見、行業資訊以及一切你想知道的相關訊息。

歡迎提問&求關注 o(*////▽////*)q～

以上。