云數據庫高可用解決方案技術解析
高可用，英文翻譯為”High Availability”.
從字面上理解就是要做到服務的full-time的持續可用，但老實說，要做到full-time是不現實的，因為能夠影響系統服務可用性的因素實在是太多了，除了軟件BUG、硬件故障外還包括系統所依賴的一些第三方服務(如運營商提供的帶寬)，甚至還包括天災人禍等；因此我理解所謂的高可用意味著”更少的停服時間”，而工業界也有一套測量系統可用性的標準，即大家所熟知的SLA(Service Level Agrement)，也就是幾個9的可用性(如下表)：
在工業應用場景中，如當下做在線服務的各大互聯網公司，號稱7*24小時的不間斷服務，想想如果只是達到一個9的可用性將會是一種什么樣的災難；而要做到5個9的可用性就意味著全年只有一次服務宕機，而且得在5分鐘左右就恢復，其中的難度也是不言而喻的，我想只是采用技術手段不足以做到，還需要通過一整套完備嚴謹的工程管理防范及配套工具、優秀工程運維人員等。
云計算號稱互聯網公司的水和電，高可用猶如云服務商的生命線，而云數據庫作為該領域的一項重要服務更是接受著不同維度的考驗，因為云端成千上萬個用戶數據庫實例所面臨的問題會更加五花八門。
下面將先介紹MySQL領域幾個典型的高可用解決方案，分析其中的關鍵技術及適用場景，并在此基礎上介紹和分享UDB的高可用方案。
一、高可用數據庫關鍵技術點
數據庫服務和很多工業服務在高可用技術方案是相通的，為了實現高可用首先實現服務的”冗余”，即服務的集群化，如果服務有冗余備份，宕機后還有其它備份服務(熱備和冷備)可以頂上，所以實現數據庫服務的”冗余”也是高可用數據庫的核心準則;而有了”冗余”備份后還不夠，如果每次宕機都需要人工恢復切換至備份服務，恢復時間得不到保證，同時人為的故障恢復過程中可能會引入新的風險(人為事故)，從而降低了服務的可用性，因此必須還具備”自動故障轉移”功能。而數據庫服務相比于其它系統的高可用，在以上兩個關鍵技術點的實現上會更加的困難，因為傳統RDMS對數據和事務的持久性和穩定性是要求非高的，從也提高了對冗余數據的一致性的要求和實現難度。
二、高可用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高可用領域成為了一種民用技術;因此使用分布式協議和多副本來解決數據庫一致性問題已經成為了主流的方向。但是此類方案還出于初級階段，不夠成熟，同時分布式一致性協議由于網絡開銷的原因在性能上還有待提高和優化。
三、 高可用數據庫案例分享--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通過自研的大型數據庫備份系統，能夠應對各種級別的宕機故障后的數據恢復，從而保障了用戶數據的安全可靠性。
【本文是51CTO專欄機構作者“大U的技術課堂”的原創文章，轉載請通過微信公眾號(ucloud2012)聯系作者】
