MySQL遷移到Azure上後，由於雲的特性，在自建資料中心的MySQL的HA的方法在雲上很多都不能部署。
這主要是因為，目前Public Cloud不支援：1. 共享儲存；2. Multicast；3. VIP。
- 共享儲存，Azure File Service可以部分解決這個問題，但考慮到效能的問題，本方案沒有采用File Service；
- 需要組播的主要原因是叢集軟體需要組播進行同步；
- VIP在Cluster的解決方案中，可以解決前段應用連線字串的問題。Cloud不支援組播和廣播，所以ARP類似的協議都不支援，使得傳統的VIP模式都不能採用。
本方案中通過DRBD、Corosync、Pacemaker、Azure ILB幾個軟體解決了上面3個HA部署中的問題，實現MySQL在Azure上的HA部署。
- 具體設計方案
整體架構如上圖，
- Azure ILB：WEB前端可以通過MySQL客戶端訪問Azure ILB的固定IP地址10.1.1.200埠3306，ILB會把MySQL的請求轉發給相應的MySQL伺服器。不管MySQL的服務遷移到任何一臺伺服器上，前端不需要更改連線字串。用這種方式實現on-premise環境中VIP相同的效果。
- DRBD：DRBD相當於網路級別的RAID1，在DRBD主節點上寫入任何資料，都會通過網路馬上同步到副節點。通過DRBD的功能，可以實現兩邊資料的同步，實現類似共享儲存的功能。
- Corosync：Corosync和Pacemaker是Heartbeat的升級版。Corosync進行底層Message層，Pacemaker進行叢集的選舉和服務的編排。傳統的Corosync是採用Multicast實現多臺Cluster伺服器的message 通訊。但在新版本中支援Full Mesh的UDP Unicast，解決Azure不支援組播的問題。
-
Pacemaker：Pacemaker是整個叢集的大腦，它決定做什麼，以及何時做。這個叢集的服務通過一個叫CRM的軟體進行對Pacemaker的編排。在本方案中，Pacemaker需要做：
- 選擇DRBD的Master節點，
- 掛載DRBD的分割槽到指定目錄，
- 啟動MySQL的服務
- 保證DRBD、File、MySQL三個服務在同一臺Master伺服器上
- 保證DRBD、File、MySQL三個服務按順序啟動
正常情況下，Pacemaker把編排好的各種服務在Master上啟動後，在Master上MySQL進行任何的資料插入，都會通過DRBD更新到Slave伺服器的DRBD Secondary磁碟上。由於在Slave伺服器上的MySQL服務不啟動，其3306埠不對外提供服務。Azure ILB認為這臺伺服器是沒有提供服務的，負載均衡集中不包含這臺伺服器。因此Aure ILB只把MySQL的請求傳送到Master上。其結構如下：
當10.1.1.6伺服器出現故障或重啟的動作時，Corosync和Pacemaker會把Master遷移到10.1.1.7上。Pacemaker在10.1.1.7上啟動之前編排的各種服務。MySQL在10.1.1.7上啟動。由於10.1.1.7提供了3306埠的服務，Azure ILB會把10.1.1.7加入到負載均衡集中，前端MySQL的請求都會發到這臺伺服器上。具體如下：
10.1.1.6和10.1.1.7兩臺機器任意一臺機器出現故障，整個系統都不需要人工參與，系統會自動遷移到available的伺服器上，對外提供服務。
二、防止腦裂問題
由於Cluster中最需要避免的問題是腦裂問題，腦裂甚至比Out-of-service帶來的危害更大。因此，需要最大程度的防止腦裂的發生。
在前面提到的方案中，防止腦裂的方式只通過DRBD、Corosync和Pacemaker軟體自身實現的。
由於採用了Azure的ILB，可以採用對ILB進行配置的方式實現防止腦裂的方案。
當Pacemaker選擇一臺伺服器作為Master時，在Pacemaker服務的編排中，加入對Azure ILB的控制，把另外一臺伺服器從ILB中移除，把自己加入到ILB中。結構如下：
極端情況，兩臺伺服器都自認為是Master的情況，後一臺啟動Pacemaker的伺服器會把另外一臺伺服器從ILB中移除。從而在ILB中只有一臺VM，保證前端伺服器通過ILB只能訪問到一臺MySQL伺服器。