随着人們對資料一緻性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式資料一緻性的問題，如mysql自身的優化、mysql叢集架構的優化、paxos、raft、2pc算法的引入等等，本文介紹mysql資料庫的幾種常見高可用方案。
<b>一、概述</b>
我們在考慮mysql資料庫的高可用的架構時，主要要考慮如下幾方面：
如果資料庫發生了當機或者意外中斷等故障，能盡快恢複資料庫的可用性，盡可能的減少停機時間，保證業務不會因為資料庫的故障而中斷。
用作備份、隻讀副本等功能的非主節點的資料應該和主節點的資料實時或者最終保持一緻。
當業務發生資料庫切換時，切換前後的資料庫内容應當一緻，不會因為資料缺失或者資料不一緻而影響業務。
關于對高可用的分級在這裡我們不做詳細的讨論，這裡隻讨論常用高可用方案的優缺點以及高可用方案的選型。
<b>二、高可用方案</b>
<b>1. 主從或主主半同步複制</b>
使用雙節點資料庫，搭建單向或者雙向的半同步複制。在5.7以後的版本中，由于lossless replication、logical多線程複制等一些列新特性的引入，使得mysql原生半同步複制更加可靠。
<b>常見架構如下：</b>
通常會和proxy、keepalived等第三方軟體同時使用，即可以用來監控資料庫的健康，又可以執行一系列管理指令。如果主庫發生故障，切換到備庫後仍然可以繼續使用資料庫。
<b>優點：</b>
架構比較簡單，使用原生半同步複制作為資料同步的依據;
雙節點，沒有主機當機後的選主問題，直接切換即可;
雙節點，需求資源少，部署簡單;
<b>缺點：</b>
完全依賴于半同步複制，如果半同步複制退化為異步複制，資料一緻性無法得到保證;
需要額外考慮haproxy、keepalived的高可用機制。
<b>2. 半同步複制優化</b>
半同步複制機制是可靠的。如果半同步複制一直是生效的，那麼便可以認為資料是一緻的。但是由于網絡波動等一些客觀原因，導緻半同步複制發生逾時而切換為異步複制，那麼這時便不能保證資料的一緻性。是以盡可能的保證半同步複制，便可提高資料的一緻性。
該方案同樣使用雙節點架構，但是在原有半同複制的基礎上做了功能上的優化，使半同步複制的機制變得更加可靠。
<b>可參考的優化方案如下：</b>
(1) 雙通道複制
半同步複制由于發生逾時後，複制斷開，當再次建立起複制時，同時建立兩條通道，其中一條半同步複制通道從目前位置開始複制，保證從機知道目前主機執行的進度。另外一條異步複制通道開始追補從機落後的資料。當異步複制通道追趕到半同步複制的起始位置時，恢複半同步複制。
(2) binlog檔案伺服器
搭建兩條半同步複制通道，其中連接配接檔案伺服器的半同步通道正常情況下不啟用，當主從的半同步複制發生網絡問題退化後，啟動與檔案伺服器的半同步複制通道。當主從半同步複制恢複後，關閉與檔案伺服器的半同步複制通道。
架構簡單，沒有選主的問題，直接切換即可;
相比于原生複制，優化後的半同步複制更能保證資料的一緻性。
需要修改核心源碼或者使用mysql通信協定。需要對源碼有一定的了解，并能做一定程度的二次開發。
依舊依賴于半同步複制，沒有從根本上解決資料一緻性問題。
<b>3. 高可用架構優化</b>
将雙節點資料庫擴充到多節點資料庫，或者多節點資料庫叢集。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的叢集。
由于半同步複制，存在接收到一個從機的成功應答即認為半同步複制成功的特性，是以多從半同步複制的可靠性要優于單從半同步複制的可靠性。并且多節點同時當機的幾率也要小于單節點當機的幾率，是以多節點架構在一定程度上可以認為高可用性是好于雙節點架構。
但是由于資料庫數量較多，是以需要資料庫管理軟體來保證資料庫的可維護性。可以選擇mmm、mha或者各個版本的proxy等等。
<b>常見方案如下：</b>
(1) mha+多節點叢集
mha manager會定時探測叢集中的master節點，當master出現故障時，它可以自動将最新資料的slave提升為新的master，然後将所有其他的slave重新指向新的master，整個故障轉移過程對應用程式完全透明。
mha node運作在每台mysql伺服器上，主要作用是切換時處理二進制日志，確定切換盡量少丢資料。
mha也可以擴充到如下的多節點叢集：
可以進行故障的自動檢測和轉移;
可擴充性較好，可以根據需要擴充mysql的節點數量和結構;
相比于雙節點的mysql複制，三節點/多節點的mysql發生不可用的機率更低
至少需要三節點，相對于雙節點需要更多的資源;
邏輯較為複雜，發生故障後排查問題，定位問題更加困難;
資料一緻性仍然靠原生半同步複制保證，仍然存在資料不一緻的風險;
可能因為網絡分區發生腦裂現象;
(2) zookeeper+proxy
zookeeper使用分布式算法保證叢集資料的一緻性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網絡分區現象的産生。
較好的保證了整個系統的高可用性，包括proxy、mysql;
擴充性較好，可以擴充為大規模叢集;
資料一緻性仍然依賴于原生的mysql半同步複制;
引入zk，整個系統的邏輯變得更加複雜;
<b>4. 共享存儲</b>
共享存儲實作了資料庫伺服器和儲存設備的解耦，不同資料庫之間的資料同步不再依賴于mysql的原生複制功能，而是通過磁盤資料同步的手段，來保證資料的一緻性。
(1) san共享儲存
san的概念是允許儲存設備和處理器(伺服器)之間建立直接的高速網絡(與lan相比)連接配接，通過這種連接配接實作資料的集中式存儲。
<b>常用架構如下：</b>
使用共享存儲時，mysql伺服器能夠正常挂載檔案系統并操作，如果主庫發生當機，備庫可以挂載相同的檔案系統，保證主庫和備庫使用相同的資料。
兩節點即可，部署簡單，切換邏輯簡單;
很好的保證資料的強一緻性;
不會因為mysql的邏輯錯誤發生資料不一緻的情況;
需要考慮共享存儲的高可用;
價格昂貴;
(2) drbd磁盤複制
drbd是一種基于軟體、基于網絡的塊複制存儲解決方案，主要用于對伺服器之間的磁盤、分區、邏輯卷等進行資料鏡像，當使用者将資料寫入本地磁盤時，還會将資料發送到網絡中另一台主機的磁盤上，這樣的本地主機(主節點)與遠端主機(備節點)的資料就可以保證明時同步。
當本地主機出現問題，遠端主機上還保留着一份相同的資料，可以繼續使用，保證了資料的安全。
drbd是linux核心子產品實作的快級别的同步複制技術，可以與san達到相同的共享存儲效果。
相比于san儲存網絡，價格低廉;
保證資料的強一緻性;
對io性能影響較大;
從庫不提供讀操作;
<b>5. 分布式協定</b>
分布式協定可以很好解決資料一緻性問題。比較常見的方案如下：
(1) mysql cluster
mysql cluster是官方叢集的部署方案，通過使用ndb存儲引擎實時備份備援資料，實作資料庫的高可用性和資料一緻性。
全部使用官方元件，不依賴于第三方軟體;
可以實作資料的強一緻性;
國内使用的較少;
配置較複雜，需要使用ndb儲存引擎，與mysql正常引擎存在一定差異;
至少三節點;
(2) galera
基于galera的mysql高可用叢集， 是多主資料同步的mysql叢集解決方案，使用簡單，沒有單點故障，可用性高。
多主寫入，無延遲複制，能保證資料強一緻性;
有成熟的社群，有網際網路公司在大規模的使用;
自動故障轉移，自動添加、剔除節點;
需要為原生mysql節點打wsrep更新檔
隻支援innodb儲存引擎
(3) poaxs
paxos 算法解決的問題是一個分布式系統如何就某個值(決議)達成一緻。這個算法被認為是同類算法中最有效的。paxos與mysql相結合可以實作在分布式的mysql資料的強一緻性。
有成熟理論基礎;
<b>三、總結</b>
随着人們對資料一緻性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式資料一緻性的問題，如mysql自身的優化、mysql叢集架構的優化、paxos、raft、2pc算法的引入等等。
而使用分布式算法用來解決mysql資料庫資料一緻性的問題的方法，也越來越被人們所接受，一系列成熟的産品如phxsql、mariadb galera cluster、percona xtradb cluster等越來越多的被大規模使用。
随着官方mysql group replication的ga，使用分布式協定來解決資料一緻性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，mysql高可用問題可以被更好的解決。
<b>轉載自51cto。</b>