第 17 章 高可用設計之思路及方案
前言：
數據庫系統是一個應用系統的核心部分，要想系統整體可用性得到保證，數據庫系統就不能出現任何問題。對於一個企業級的系統來說，數據庫系統的可用性尤為重要。數據庫系統一旦出現問題無法提供服務，所有系統都可能無法繼續工作，而不像軟件中部分系統出現問題可能影響的僅僅只是某個功能無法繼續服務。所以，一個成功的數據庫架構在高可用設計方面也是需要充分考慮的。本章內容將針對如何構建一個高可用的 MySQL 數據庫系統來介紹各種解決方案以及方案之間的比較。
17.1 利用 Replication 來實現高可用架構
做維護的讀者朋友應該都清楚，任何設備（或服務），只要是單點，就存在著很大的安全隱患。因為一旦這台設備（或服務） crash 之後，在短時間內就很難有備用設備（或服務）來頂替其功能。所以稍微重要一些的服務器或者應用系統，都會存在至少一個備份以供出現異常的時候能夠很快的頂替上來提供服務。
對於數據庫來說，主備配置是非常常見的設計思路。而對於 MySQL 來說，可以說天生就具備了實現該功能的優勢，因為其 Replication 功能在實際應用中被廣泛的用來實現主備配置的功能。
我想，在大家所接觸的 MySQL 環境中大多數都存在通過 MySQL Replication 來實現兩台（或者多台）MySQL Server 之間的數據庫復制功能吧。可能有些是為了增強系統擴展性，滿足性能要求實現讀寫分離。亦或者就是用來作為主備機的設計，保證當主機 crash 之後在很短的時間內就可以將應用切換到備機上面來繼續運行。
通過 MySQL Replication 來實現數據庫的復制實際上在前面第13章中的內容中已經做過詳細的介紹了，也介紹了多種 Replication 架構的實現原理及實現方法。在之前，主要是從擴展性方面來介紹 Replication。在這裡，我將主要介紹的是從系統高可用方面如何和利用 Replication 的多種架構實現解決高可靠性的問題。
17.1.1 常規的 Master - Slave 解決基本的主備設計
在之前的章節中我提到過，普通的 Master - Slave 架構是目前很多系統中使用最為常見的一種架構方式。該架構設計不僅僅在很大程度上解決的系統的擴展性問題，帶來性能的提升，同時在系統可靠性方面也提供了一定的保證。
在普通的一個 Master 後面復制一個或者多個 Slave 的架構設計中，當我們的某一台Slave 出現故障不能提供服務之後，我們還有至少一台 MySQL 服務器（Master）可以提供服務，不至於所有和數據庫相關的業務都不能運行下去。如果 Slave 超過一台，那麼剩下的 Slave 也仍然能夠不受任何干擾的繼續提供服務。
當然，這裡有一點在設計的時候是需要注意的，那就是我們的 MySQL 數據庫集群整體的服務能力要至少能夠保證當其缺少一台 MySQL Server 之後還能夠支撐系統的負載，否則一切都是空談。不過，從系統設計角度來說，系統處理能力留有一定的剩余空間是一個比較基本的要求。所以正常來說，系統中短時間內少一台 MySQL Server 應該是仍然能夠支撐正常業務的。 
如上圖所示，當我們的 Slave 集群中的一台 Slave C 出現故障 crash 之後，整個系統的變化僅僅只是從 Master 至 Slave C 的復制中斷，客戶端應用的 Read 請求也不能再訪問 Slave C。當時其他所有的 MySQL Server 在不需要任何調整的情況下就能正常工作。客戶端的請求 Read 請求全部由 Slave A 和 Slave B 來承擔。
17.1.2 Master 單點問題的解決
上面的架構可以很容易的解決 Slave 出現故障的情況，而且不需要進行任何調整就能繼續提供服務。但是，當我們的 Master 出現問題後呢？當我們的 Master 出現問題之後所有客戶端的 Write 請求就都無法處理了。
這時候我們可以有如下兩種解決方案，一個是將 Slave 中的某一台切換成 Master 對外提供服務，同時將其他所有的 Slave 都以通過 CHANGE MASTER 命令來將通過新的Master 進行復制。另一個方案就是新增一台 Master，也就是 Dual Master 的解決方案。
我們先來看看第一種解決方案，將一台 Slave 切換成 Master 來解決問題，如圖： 
當 Master 出現故障 crash 之後，原客戶端對 Master 的所有 Write 請求都會無法再繼續進行下去了，所有原 Master 到 Slave 的復制也自然就斷掉了。這時候，我們選擇一台 Slave 將其切換成 Master。假設選擇的是 Slave A，則我們將其他 Slave B 和 Slave C都通過 CHANGE MASTER TO 命令更換其 Master，從新的 Master 也就是原Slave A 開始繼續進行復制。同時將應用端所有的寫入請求轉向到新的 Master。對於 Read 請求，我們可以去掉對新 Master 的 Read 請求，也可以繼續保留。
這種方案最大的一個弊端就是切換步驟比較多，實現比較復雜。而且，在 Master 出現故障 crash 的那個時刻，我們的所有 Slave 的復制進度並不一定完全一致，有可能有少量的差異。這時候，選擇哪一個 Slave 作為 Master也是一個比較頭疼的問題。所以這個方案的可控性並不是特別的高。
我們再來看看第二種解決方案，也就是通過 Dual Master 來解決 Master 的點問，為了簡單明了，這裡就僅畫出 Master 部分的圖，如下： 
我們通過兩台 MySQL Server 搭建成 Dual Master 環境，正常情況下，所有客戶端的Write 請求都寫往 Master A，然後通過 Replication 將 Master A 復制到 Master B。一旦 Master A 出現問題之後，所有的 Write 請求都轉向 Master B。而在正常情況下，當Master B 出現問題的時候，實際上不論是數據庫還是客戶端的請求，都不會受到實質性的影響。
這裡，可能有讀者朋友會想到，當我們的 Master A 出現問題的時候，應用如何做到自動將請求轉向到 Master B 呢？其實很簡單，我們只需要通過相應的硬件設備如F5或者Cluster 管理軟件如 Heartbeat 來設置一個 VIP，正常情況下該 VIP 指向 Master A，而一旦 Master A出現異常 crash 之後，則自動切換指向到 Master B，前端所的應用都通過這個 VIP 來訪問 Master。這樣，既解決了應用的 IP 切換問題，還保證了在任何時刻應用都只會見到一台 Master，避免了多點寫入出現數據紊亂的可能。
這個方案最大的特點就是在 Master 出現故障之後的處理比較簡單，可控性比較大。而弊端就是需要增加一台 MySQL 服務器，在成本方面投入更大。
17.1.3 Dual Master 與級聯復制結合解決異常故障下的高可用
通過前面的架構分析，我們分別得到了 Slave 出現故障後的解決方案，也解決了Master 的單點問題。現在我們再通過 Dual Master 與級聯復制結合的架構，來得到一個整體的解決方案，解決系統整體可靠性的問題。
這個架構方案的介紹在之前的章節中已經詳細的描述過了，這裡我們主要分析一下處於高可靠性方面考慮的完善和異常切換方法。 
如上圖所示，首先考慮 Slave 出現異常的情況。在這個架構中，Slave 出現異常後的處理情況和普通的 Master - Slave 架構的處理方式完全一樣，僅僅需要在應用訪問 Slave集群的訪問配置中去掉一個 Slave 節點即可解決，不論是通過應用程序自己判斷，還是通過硬件解決方案如 F5 都可以很容易的實現。
下面我們再看看當 Master A 出現故障 crash 之後的處理方案。如下圖：
當 Master A 出現故障 crash 之後，Master A 與 Master B 之間的復制將中斷，所有客戶端向 Master A 的 Write 請求都必須轉向 Master B。這個轉向動作的實現，可以通過上一節中所介紹的第二中方案中所介紹的通過 VIP 的方式實現。由於之前所有的 Slave 就都是從 Master B 來實現復制，所以 Slave 集群不會受到任何的影響，客戶端的所有 Read 請求也就不會受到任何的影響，整個過程可以完全自動進行，不需要任何的人為干預。不過
這裡有一個隱患就是當 Master A crash 的時候如果 Master B 作為 Slave 的 IO 線程如果還沒有讀取完 Master A 的二進制日志的話，就會出現數據丟失的問題。要完全解決這個問題，我們只能通過第三方 patch（google 開發）來鏡像 MySQL 的二進制日志到 Master B上面，才能完全避免不丟失任何數據。
那麼當 Master B 出現故障crash 之後的情況又如何呢？如下圖所示： 
如果出現故障的不是 Master B 而是 Master A 又會怎樣呢？首先可以確定的是我們的所有 Write 請求都不會受到任何影響，而且所有的 Read 請求也都還是能夠正常訪問。
但所有 Slave 的復制都會中斷，Slave 上面的數據會開始出現滯後的現象。這時候我們需要做的就是將所有的 Slave 進行 CHANGE MASTER TO 操作，改為從 Master A 進行復制。
由於所有 Slave 的復制都不可能超前最初的數據源，所以可以根據 Slave 上面的 Relay Log 中的時間戳信息與 Master A 中的時間戳信息進行對照來找到准確的復制起始點，不會造成任何的數據丟失。
17.1.4 Dual Master 與級聯復制結合解決在線 DDL 變更問題
當我們使用 Dual Master 加級聯復制的組合架構的時候，對於 MySQL 的一個致命傷也就是在線 DDL 變更來說，也可以得到一定的解決。如當我們需要給某個表 tab 增加一個字段，可以通過如下在上述架構中來實現：
1、在 Slave 集群中抽出一台暫時停止提供服務，然後對其進行變更，完成後再放回集群繼續提供服務；
2、重復第一步的操作完成所有 Slave 的變更；
3、暫停 Master B 的復制，同時關閉當前 session 記錄二進制日志的功能，對其進行變更，完成後再啟動復制；
4、通過 VIP 切換，將應用所有對 Master A 的請求切換至 Master B；
5、關閉 Master A 當前 session 記錄二進制日志的功能，然後進行變更；
6、最後再將 VIP 從 Master B 切換回 Master A，至此，所有變更完成。
變更過程中有幾點需要注意的：
1、整個 Slave 集群需要能夠承受在少一台 MySQL 的時候仍然能夠支撐所有業務；
2、Slave 集群中增加或者減少一台 MySQL 的操作簡單，可通過在線調整應用配置來實現；
3、Dual Master 之間的 VIP 切換簡單，且切換時間較短，因為這個切換過程會造成短時間段內應用無法訪問 Master 數據庫。
4、在變更 Master B 的時候，會出現短時間段內 Slave 集群數據的延時，所以如果單台主機的變更時間較長的話，需要在業務量較低的凌晨進行變更。如果有必要，甚至可能需要變更 Master B 之前將所有 Slave 切換為以 Master B 作為Master。
當然，即使是這樣，由於存在 Master A 與 Master B 之間的 VIP 切換，我們仍然會出現短時間段內應用無法進行寫入操作的情況。所以說，這種方案也僅僅能夠在一定程度上面解決 MySQL 在線 DDL 的問題。而且當集群數量較多，而且每個集群的節點也較多的情況下，整個操作過程將會非常的復雜也很漫長。對於 MySQL 在線 DDL 的問題，目前也確實還沒有一個非常完美的解決方案，只能期待 MySQL 能夠在後續版本中盡快解決這個問題了。
17.2 利用 MySQL Cluster 實現整體高可用
在上一章中已經詳細介紹過 MySQL Cluster 的相關特性，以及安裝配置維護方面的內容。這裡，主要是介紹一下如何利用 MySQL Cluster 的特性來提高我們系統的整體可用性。由於 MySQL Cluster 本身就是一個完整的分布式架構的系統，而且支持數據的多點冗余存放，數據實時同步等特性。所以可以說他天生就已經具備了實現高可靠性的條件了，是否能夠在實際應用中滿足要求，主要就是在系統搭建配置方面的合理設置了。
由於 MySQL Cluster 的架構主要由兩個層次兩組集群來組成，包括 SQL 節點（mysqld）和NDB 節點（數據節點），所有兩個層次都需要能夠保證高可靠性才能保證整體的可靠性。
下面我們從兩個方面分別來介紹 MySQL Cluster 的高可靠性。
17.2.1 SQL 節點的高可靠性保證
MySQL Cluster 中的 SQL 節點實際上就是一個多節點的 mysqld 服務，並不包含任何數據。所以，SQL 節點集群就像其他任何普通的應用服務器一樣，可替代性很高，只要安裝了支持 MySQL Cluster 的 MySQL Server 端即可。
當該集群中的一個 SQL 節點 crash 掉之後，由於只是單純的應用服務，所以並不會造成任何的數據丟失。只需要前端的應用數據源配置兼容了集群中某台主機 crash 之後自動將該主機從集群中去除就可以了。實際上，這一點對於應用服務器來說是非常容易做到的，無論是通過自行開發判斷功能的代理還是通過硬件級別的負載均衡設備，都可以非常容易做到。當然，前提自然也是剩下的 SQL 節點能夠承擔整體負載才行。 
如上圖，當 SQL 1 crash 之後，實際上僅僅只是訪問到數據的很多條途徑中的某一條中斷了，實際上仍然還有很多條途徑可以獲取到所需要的數據。而且，由於 SQL 的可替代性很高，所以更換也非常簡單，即使更換整台主機，也可以在短時間內完成。
17.2.2 NDB 節點的高可靠性保證
MySQL Cluster 的數據冗余是有一個前提條件的，首先必須要保證有足夠的節點，實際上是至少需要2個節點才能保證數據有冗余，因為，MySQL Cluster 在保存冗余數據的時候，是比需要確保同一份數據的冗余存儲在不同的節點之上。在保證了冗余的前提下，MySQL Cluster 才會將數據進行分區。
假設我們存在4個 NDB 節點，數據被分成4 個partition 存放，數據冗余存儲，每份數據存儲2份，也就是說 NDB 配置中的 NoOfReplicas 參數設置為 2，4個節點將被分成2個 NDB Group。
所有數據的分布類似於下圖所示：
在這樣的配置中，假設我們 NDB Group 0 這一組中的某一個 NDB 節點（假如是 NDB 1） 出現問題，其中的部分數據（假設是 part 1）壞了，由於每一份數據都存在一個冗余拷貝， 所以並不會對系統造成任何的影響，甚至完全不需要人為的操作，MySQL 就可以繼續正常的提供服務。
假如我們兩個節點上面都出現部分數據損壞的情況，結果會怎樣？如下圖：
如果像上圖所示，如果兩個損壞部分數據的節點屬於同一個 NDB Group，只要損壞部分並沒有包含完全相同的數據，整個 MySQL Cluster 仍然可以正常提供服務。但是，如果損壞數據中存在相同的數據，即使只有很少的部分，都會造成 MySQL Cluster出現問題，不能完全正常的提供服務。此外，如果損壞數據的節點處於兩個不同的 NDB Group，那麼非常幸運，不管損壞的是哪一部分數據，都不會影響 MySQL Cluster 的正常服務。
可能有讀者朋友會說，那假如我們的硬件出現故障，整個 NDB 都crash 了呢？是的，確實很可能存在這樣的問題，不過我們同樣不用擔心，如圖所示：
假設我們整個 NDB 節點由於硬件（或者軟件）故障而 crash 之後，由於 MySQL Cluster 保證了每份數據的拷貝都不在同一台主機上，所以即使整太主機都 crash 了之後，MySQL Cluster 仍然能夠正常提供服務，就像上圖所示的那樣，即使整個 NDB 1 節點都 crash 了，每一份數據都還可以通過 NDB 2 節點找回。
那如果是同時 crash 兩個節點會是什麼結果？首先可以肯定的是假如我們 crash 的兩個節點處於同一個 NDB Group 中的話，那 MySQL Cluster 也沒有辦法了，因為兩份冗余的數據都丟失了。但是只要 crash 的兩個節點不在同一個 NDB Group 中，MySQL Cluster 就不會受到任何影響，還是能夠繼續提供正常服務。如下圖所示的情況：
從上面所列舉的情況我們可以知道，MySQL Cluster 確實可以達到非常高的可靠性，畢竟同一時刻存放相同數據的兩個 NDB 節點都出現大故障的概率實在是太小了，要是這也能夠被遇上，那只能自然倒霉了。
當然，由於 MySQL Cluster 之前的老版本需要將所有的數據全部 Load 到內存中才能正常運行，所有由於受到內存空間大小的限制，使用的人非常少。現在的新版本雖然已經支持僅僅只需要所有的索引數據 Load 到內存中即可，但是由於實際的成功案例還並不是很多，而且發展時間也還不是太長，所以很多用戶朋友對於 MySQL Cluster 目前還是持謹慎態度，大部分還處於測試階段。
17.3 利用 DRBD 保證數據的高安全可靠
17.3.1 DRBD 介紹
對於很多多這朋友來說，DRBD 的使用可能還不是太熟悉，但多多少少可能有一些了解。 畢竟，在 MySQL 的官方文檔手冊的 High Availability and Scalability 這一章中將 DRBD 作為 MySQL 實現高可用性的一個非常重要的方式來介紹的。雖然這一內容是直到去年年中的時候才開始加入到 MySQL 的文檔手冊中，但是 DRBD 本身在這之前很久就已經成為很多應用場合實現高可靠性的解決方案，而且在不少的 MySQL 使用群體中也早就開始使用了。
簡單來說，DRBD 其實就是通過網絡來實現塊設備的數據鏡像同步的一款開源 Cluster軟件，也被俗稱為網絡 RAID1。官方英文介紹為：DRBD refers toblock devicesdesigned asa building block toform high availability (HA) clusters. This is done by mirroring a whole block device via an assigned network.It is shownas network raid-1- DRBD。下面是 DRBD 的一個概覽圖：
從圖中我們可以看出，DRBD 介於文件系統與磁盤介質之間，通過捕獲上層文件系統的所有IO操作，然後調用內核中的IO模塊來讀寫底層的磁盤介質。當 DRBD 捕獲到文件系統的寫操作之後，會在進行本地的磁盤寫操作的同時，以 TCP/IP 協議將，通過本地主機的網絡設備（NIC）將 IO 傳遞至遠程主機的網絡設備。當遠程主機的 DRBD 監聽到傳遞過來的 IO 信息之後，會立即將該數據寫入到該 DRBD 所維護的磁盤設備。至此，整個 IO 才做完成。
實際上 DRBD 在處理遠程數據寫入的時候有三種復制模式（或者稱為級別）可以選擇，不同的復制模式保證了遠程數據寫入的三種可靠性。三種級別的選擇可以通過 DRBD 的通用配置部分的 protocal。不同的復制模式，實際上是影響了一個 IO 完成所代表的實際含義。
因為當我們使用 DRBD 的時候，一個 IO 完成的標識（DRBD 返回 IO 完成）是本地寫入和遠程寫入這兩個並發進程都返回完成標識。下面我來詳細介紹一下這三種復制模式所代表的含義：
Protocol A：這種模式是可靠性最低的模式，而且是一個異步的模式。當我們使用這個模式來配置的時候，寫遠程數據的進程將數據通過 TCP/IP 協議發送進入本地主機的 TCP send buffer 中，即返回完成。
Protocol B：這種模式相對於 Protocol A 來說，可靠性要更高一些。因為寫入遠程的線程會等待網絡信息傳輸完成，也就是數據已經被遠程的 DRBD 接受到之後返回完成。
Protocol C：Protocol C 復制模式是真正完全的同步復制模式，只有當遠程的 DRBD 將數據完全寫入磁盤成功後，才會返回完成。
對比上面三種復制模式，C 模式可以保證不論出現任何異常，都能夠保證兩端數據的一1致性。而如果使用 B 模式，則可能當遠程主機突然斷電之後，將丟失部分還沒有完全寫入磁盤的信息，且本地與遠程的數據出現一定的不一致情況。當我們使用 A 復制模式的話，可能存在的風險就要更大了。只要本地網絡設備突然無法正常工作（包括主機斷電），就會丟失將寫入遠程主機的數據，造成數據不一致現象。
由於不同模式所要求的遠程寫入進程返回完成信息的時機不一樣，所以也直接決定了IO 寫入的性能。通過三個模式的描述，我們可以很清楚的知道，IO 寫入性能與可靠程度成反比。所以，各位讀者朋友在考慮設置這個參數的時候，需要仔細評估各方面的影響，盡可能得到一個既滿足實際場景的性能需求，又能滿足對可靠性的要求。
DRBD 的安裝部署以及相關的配置說明，在 MySQL 的官方文檔手冊以及我的個人網站博客（http://www.jianzhaoyang.com）中都有相關的描述，而且在 DRBD 的官方網站上面也可以找到最為全面的說明，所以這裡就不再介紹了。下面我主要介紹一下 DRBD 的一些特殊的特性以及限制，以供大家參考。
17.3.2 DRBD 特性與限制
DRBD 之所以能夠得到廣泛的采用，甚至被 MySQL 官方寫入文檔手冊作為官方推薦的高可用方案之一，主要是其各種高可靠特性以及穩定性的緣故。下面介紹一下 DRBD 所具備的一些比較重要的特性。
1、非常豐富的配置選項，可以適應我們的應用場景中的情況。無論是可靠性級別與性能的平衡，還是數據安全性方面，無論是本地磁盤，還是網絡存儲設備，無論是希望異常自動解決，還是希望手動控制等等，都可以通過簡單的配置文件就可以解決。
當然，豐富的配置在帶來極大的靈活性的同時，也要求使用者需要對他有足夠的了解才行，否則在那麼多配置參數中也很難決策該如何配置。幸好 DRBD 在默認情況下的各項參數實際上就已經滿足了大多數典型需求了，並不需要我們每一項參數都設置才能運行；
2、對於節點之間出現數據不一致現象，DRBD 可以通過一定的規則，進行重新同步。而且可以通過相關參數配置讓 DRBD 在固定時間點進行數據的校驗比對，來確定數據是否一致，並對不一致的數據進行標記。同時還可以選擇是 DRBD 自行解決不一致問題還是由我們手工決定如何同步；
3、在運行過程中如果出現異常導致一端 crash，並不會影響另一端的正常工作。出現異常之後的所有數據變更，都會被記錄到相關的日志文件中。當 crash 節點正常恢復之後，可以自動同步這段時間變更過的數據。為了不影響新數據的正常同步，還可以設定恢復過程中的速度，以確保網絡和其他設備不會出現性能問題；
4、多種文件系統類型的支持。DRBD 除了能夠支持各種常規的文件系統之外，還可以支持 GFS，OCFS2 等分布式文件系統。而且，在使用分布式文件系統的時候，還可以實現各結帶你同時提供所有 IO 操作。
5、提供對 LVM 的支持。DRBD 既可以使用由 LVM 提供的邏輯設備，也可以將自己對外提供的設備成為 LVM 的物理設備，這極大的方便的運維人員對存儲設備的管理。
6、所有 IO 操作，能夠絕對的保證 IO 順序。這也是對於數據庫來說非常重要的一個特性尤其是一些對數據一致性要求非常苛刻的數據庫軟件來說。
7、可以支持多種傳輸協議，從 DRBD 8.2.7 開始，DRBD 開始支持 Ipv4，IPv6以及SuperSockets來進行數據傳輸。
8、支持 Three-Way 復制。從 DRBD 8.3.0 開始，DRBD 可以支持三個節點之間的復制了，有點類似於級聯復制的特性。
當然，DRBD 在擁有大量讓人青睐的特性的同時，也存在一定的限制，下面就是 DRBD 目前存在的一些比較重要的限制：
1、對於使用常規文件系統（非分布式文件系統）的情況下，DRBD 只能支持單 Primary模式。在單 Primary 模式下，只有一個節點的數據是可以對外提供 IO 服務的。
只有當使用 GFS 或者 OCFS2 這樣的分布式文件系統的時候，才能支持 Dual Primary 模式。
2、Sblit Brain 的解決。因為某些特殊的原因，造成兩台主機之間的 DRBD 連接中斷之後雙方都以 Primary 角色來運行之後的處理還不是太穩定。雖然 DRBD 的配置文件中可以配置自動解決 Split Brain，但是從我之前的測試情況來看，並不是每次的解決都非常令人滿意，在有些情況下，可能出現某個節點完全失效的可能。
3、復制節點數目的限制，即使是目前最新的 DRBD 版本來說，也最多只支持三個節點之間的復制。
以上幾個限制是在目前看來可能對使用者造成較大影響的幾個限制。當然，DRBD 還存在很多其他方面的限制，大家在決定使用之前，還是需要經過足夠測試了解，以確保不會造成上線後的困擾。
17.4 其他高可用設計方案
除了上面幾種高可用方案之外，其實還有不少方案可以供大家選擇，如RaiDB，共享存儲解（SAN 或者 NAS） 等等。
對於 RaiDB，可能很多讀者朋友還比較陌生，其全稱為 Redundant Arrays of Inexpensive Databases。也就是通過 Raid 理念來管理數據庫的數據。所以 RaiDB 也存在數據庫 Sharding 的概念。和磁盤 Raid 一樣，RaiDB 也存在多種 Raid，如 RaiDB-0，RaiDB-1，RaiDB-2，RaiDB-0-1 和 RaiDB-1-0 等。商業 MySQL 數據庫解決方案提供商 Continuent 的數據庫解決方案中，就利用了 RaiDB 的概念。大家可以通過一下幾張圖片清晰的了解RaiDB 的各種 Raid 模式。
RaiDB-0: 
RaiDB-1:
RaiDB-2:
RaiDB-0-1:
RaiDB-1-0: 
從圖中的標識，大家應該就比較清楚 RaiDB 各種Raid 模式下的數據如何分布以及工作方式了吧。至於為什麼這樣作可以保證高可用性，就和磁盤通過 Raid 來保證數據高可靠性一樣。當然，要真正理解，前提還是大家已經具備了清晰的 Raid 概念。
而對於共享存儲的解決方案，則是一個相對來說比較昂貴的解決方案了。運行 MySQL Server 的主機上面並不存放數據，只不過通過共享協議（FC 或者 NFS）來將遠程存儲設備上面的磁盤空間 Mount 到本地，當作本地磁盤來使用。
為什麼共享存儲的解決方案可以滿足高可靠性要求呢？首先，數據不是存在 MySQL Server 本地主機上面，所以當本地 MySQL Server 主機出現任何故障，都不會造成數據的丟失，完全可以通過其他主機來找回存儲設備上面的數據。其次，無論是通過通過 SAN 還是 NAS 來作為共享存儲，存儲本身具備多種高可用解決方案，可以做到完全不丟失任何數據。甚至即使 MySQL Server 與共享存儲之間的連接通道，也有很多成熟的高可用解決方案，來保證連接的高可用性。由於共享存儲的解決方案本身違背了我個人提倡的通過 MySQL 構建廉價的企業級高性能高可靠性方案，又考慮到篇幅問題，所以這裡就不詳細深入介紹了。
如果讀者朋友對這方面比較感興趣，可以通過其他圖書再深入了解 SAN 存儲以及 NAS 存儲相關的知識。
17.5 各種高可用方案的利弊比較
從前面各種高可用設計方案的介紹中讀者們可能已經發現，不管是哪一種方案，都存在自己獨特的優勢，但也都或多或少的存在一些限制。其實這也是很正常的，畢竟任何事物都不可能是完美的，我們只能充分利用各自的優勢來解決自己的問題，而不是希望依賴某種方案一勞永逸的解決所有問題。這一節將針對上面的幾種主要方案做一個利弊分析，以供大家選擇過程中參考。
1、MySQL Replication
優勢：部署簡單，實施方便，維護也不復雜，是 MySQL 天生就支持的功能。且主備機之間切換方便，可以通過第三方軟件或者自行編寫簡單的腳本即可自動完成主備切換。
劣勢：如果 Master 主機硬件故障且無法恢復，則可能造成部分未傳送到 Slave 端的數據丟失；
2、MySQL Cluster
優勢：可用性非常高，性能非常好。每一分數據至少在不同主機上面存在一份拷貝，且冗余數據拷貝實時同步。
劣勢：維護較為復雜，產品還比較新，存在部分bug，目前還不一定適用於比較核心的線上系統。
3、DRBD 磁盤網絡鏡像方案
優勢：軟件功能強大，數據在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。IO 操作保持順序，可滿足數據庫對數據一致性的苛刻要求。
劣勢：非分布式文件系統環境無法支持鏡像數據同時可見，性能和可靠性兩者相互矛盾，無法適用於性能和可靠性要求都比較苛刻的環境。維護成本高於 MySQL Replication。
17.6 小結
本章重點針對 MySQL 自身具備的兩種高可用解決方案以及 MySQL 官方推薦的 DRBD 解決方案做了較為詳細的介紹，同時包括了各解決方案的利弊對比。希望這些信息能夠給各位讀者帶來一些幫助。不過，MySQL 的高可用解決方案遠遠不只上面介紹過的集中方案，還存在著大量的其他方案可供各位讀者朋友進行研究探索。開源的力量是巨大的，開源貢獻者的力量更是無窮的。
摘自：《MySQL性能調優與架構設計》簡朝陽
轉載請注明出處：
作者：JesseLZJ
出處：http://jesselzj.cnblogs.com
