【MySQL】MMM和MHA高可用架構

• 用途

1. 對MySQL主從複製集羣的Master的健康監控。
2. 當Master宕機後把寫VIP遷移到新Master。
3. 從新配置集羣中的其餘Slave重新Master同步

 

• MMM架構

　　主服務器發生故障時，

　　　　1.主備服務器切換爲新的主服務器：

　　　　　　(1)主備服務器設置read_only=off。

　　　　　　(2)主備服務器遷移寫VIP到本身。

　　　　2.從服務器切換指向新的主服務器：

　　　　　　(1)完成原主服務器上已複製日誌的恢復。

　　　　　　(2)使用Change Master to命令鏈接指向新的主服務器。

 

• MMM架構優勢

1. 提供了讀寫VIP的配置，使得讀寫請求均可以作到高可用。

2. 工具包相對完善，不須要額外開發腳本。
3. 完成故障轉移後，能夠繼續對MySQL集羣進行高可用監控。

 

• MMM架構缺點

1. 故障切換簡單粗暴易丟事務。解決方案：使用MySQL5.7及以後的半同步複製。

2. 原生不支持GTID的複製方式。解決方案：自行修改perl腳本實現。
3. 社區不活躍，好久未更新版本了。
4. 須要的機器和IP地址資源較多。

 

• MHA架構

　　主服務器發生故障時，

　　　　1.選舉具備最新更新的Slave從節點。

　　　　2.嘗試從宕機的Master主節點保存bin_log。

　　　　3.應用差別的中繼relay_log到其餘Slave從節點。

　　　　4.應用從Master主節點保存的bin_log。

 　　　5.提高選舉出的Slave從節點爲新的Master主節點。

　　　　6.配置其餘Slave從節點重新的Master主節點主從同步。

 

• MHA架構優勢

1. 既支持日誌點的主從同步，也支持GTID的主從同步。

2. 可從多個Slave中選舉出最合適的新Master，無需單獨準備一個Master備機。
3. 嘗試從老Master儘量多的保存和獲取未同步日誌。

 

• MHA架構缺點

1. 未必能獲取到老Master未同步日誌。解決方案：使用MySQL5.7及以後的半同步複製。

2. 須要自行開發寫VIP轉移腳本。
3. 只保證了Master高可用，未保證Slave高可用。