基于MHA插件的MySQL高可用切換架構

一、環境：

1.背景：

除了galera cluster(Mariadb Cluster,GroupReplication,PXC)和KeepAlived之外，業界廣泛使用的MySQL高可用就是MHA架構了。

MHA作者在離開DeNA加入FACEBOOK後就極少更新了這個工具了。

2.安裝：

RPM包安裝的方式最簡單，但是作者在27天前增加了對從庫上啟用了super-read-only參數的優化，簡而言之就是：當開啟這個參數後，有可能會發生配置檔案中的使用者無法對差異事務進行應用的問題。于是增加了判斷super-read-only參數是否開啟的邏輯判斷，若開啟，則先關閉此參數，然後進行應用差異事務然後重新開啟。

是以這裡我們采用編譯Github上最新的代碼的辦法進行安裝。位址為：

<a href="https://github.com/yoshinorim/mha4mysql-manager">https://github.com/yoshinorim/mha4mysql-manager</a>

<a href="https://github.com/yoshinorim/mha4mysql-node">https://github.com/yoshinorim/mha4mysql-node</a>

在node1和node2上：

配置檔案内容：

報警腳本修改：

增加定時清理relay log的腳本：

修改故障切換VIP腳本：

至此：安裝與配置已經完全結束，開始進入運作環節（請務必完成三台主機間的SSH信任）

運作：

檢查masterha_manager運作情況：

故障轉移：

我們将主庫關機，進行觀測整個故障轉移的過程

故障切換解析：

1.每秒檢查MySQL，連續4次無法連上MySQL服務後，進入SSH檢查階段，SSH也不通後，确認執行個體故障。由于故障執行個體為主庫，觸發切換主庫的操作。

2.再次讀取配置檔案資訊，擷取所有注冊的執行個體，及其切換偏好。關閉manager節點，啟用切換腳本進行切換操作。切換操作的邏輯與之前的《從masterha_master_switch工具簡單分析MHA的切換邏輯》文章中分析的相近。

3.切換主庫成功後，輸出切換報告，同時在/data/mha中生成 mainBusiness.failover.complete檔案。接着在新的主庫上進行虛拟IP的挂載，發送故障報告郵件。

附：

兩篇前言文章：

1.千萬要注意定時清理relay log。我在搭建完之後，直接進行了壓測資料的寫入，大量relay log用盡了所有的硬碟空間。這時從庫MySQL服務假死，MHA所有的腳本也都會因為得不到從庫的回應也同樣卡住。

2.另一種簡單的send_report的腳本：

郵件系統安裝腳本：

調用方式：

原文釋出時間為：2018-02-6

本文作者：張銳志