MHA簡介：
MHA是由日本人yoshinorim（原就職於DeNA現就職於FaceBook）開發的比較成熟的MySQL高可用方案。MHA能夠在30秒內實現故障切換，並能在故障切換中，最大可能的保證數據一致性。
該軟件由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。MHA Manager可以單獨部署在一臺獨立的機器上管理多個master-slave集羣，也可以部署在一臺slave節點上。MHA Node運行在每臺mysql服務器上，MHA Manager會定時探測集羣中的master節點，當master出故障時，它可以自動將最新數據的slave提升爲新的master，然後將所有其它的slave重新指向新的master。整個故障轉移過程對應用程序完全透明。
MHA基本機構圖如下：
以上拓撲圖展示瞭如何通過MHA Manager管理多組主從複製。可以將MHA工作原理總結如下：
（1）從宕機崩潰的master服務器中保存二進制日誌事件（binlog events）
（2）識別含有最新更新的slave
（3）應用差異的中繼日誌（relay-log）到其它slave
（4）應用從master保存的二進制日誌事件（binlog events）
（5）提升一個新的slave爲master
（6）使其它的slave連接新的master進行復制。
一、部署環境
大概部署環境如下：（說明：所有系統均爲centos7.3，其中server03、server04爲server02的從）
| 角色 | ip | 主機名 | 類型 |
| 監測主機（monitor host） | 172.17.5.1 | server01 | 監控複製組 |
| 主服務器（master） | 172.17.5.2 | server02 | 寫入 |
| 備用主服務器（candicate master） | 172.17.5.3 | server03 | 讀 |
| 從服務器（slave） | 172.17.5.4 | server04 | 讀 |
二、配置hosts本地解析
①四臺機器配置相同的hosts解析。（也可以在mysql配置文件裏配置忽略名字解析skip-name-resolve）
三、配置四臺主機之間ssh免密登陸（都需要配置哦）。
四、配置mysql服務。
①在master（server02）主機上配置mysql主配置文件
②在其它三個服務器上配置mysql主配置文件（注意：server-id不一樣，其它配置文件都一樣）。
③配置好主從節點之後，按MYSQL複製配置架構的配置方式將其配置完成並啓動master節點和各slave節點，以及爲各slave節點啓動其IO和SQL線程，確保主從複製運行無誤。操作如下：
在master（server02）服務器上授權slave服務器能連接數據庫讀取二進制日誌事物。
在其它機器上獲取master的權限，開啓複製功能。（三臺機器一樣）
五、搭建MHA環境和配置服務。
①在master（server02）服務器上創建MHA管理複製的賬號。
②在所有服務器上安裝mha4mysql-node（我是下載好安裝包使用rpm安裝的）
③在監測主機（monitor host）上安裝mha4mysql-manager
④定義MHA管理配置文件。
在manager（server01）配置：
定義一個統一管理的用戶和目錄，方便以後管理。
mkdir -p /etc/mha_master/app1
修改MHA配置文件如下：
⑤在master（server02）和slave（server03、04）創建工作目錄
命令：mkdir /mydata/mha_master/app1
⑥檢測各節點之間ssh通訊是否ok（server01執行）
⑦再次在master（server02）執行mysql授權sql語句。【爲了確保各slave服務器節點正常，隨時可以成爲master服務器】
⑧masterha_check_repl工具檢查mysql主從複製是否成功
⑨啓動MHA
五、測試。
①停止master（server02）服務器，查看manager（server01）日誌。
systemctl stop mariadb (sserver02)
②查看備用slave是否爲master了。
③恢復master（server02）。
六、日常操作
①校驗ssh等效驗證
$ masterha_check_ssh --conf=/etc/masterha/app1.cnf
②校驗mysql複製
$ masterha_check_repl --conf=/etc/masterha/app1.cnf
③啓動mha監控，在master故障時開啓自動轉移
$ nohup masterha_manager --conf=/etc/masterha/app1.cnf > /tmp/mha_manager.log < /dev/null 2>&1 &
###當有slave節點宕掉的情況是啓動不了的，加上--ignore_fail_on_start即使有節點宕掉也能啓動mha
$ nohup masterha_manager --conf=/etc/masterha/app1.cnf --ignore_fail_on_start > /tmp/mha_manager.log < /dev/null 2>&1 &
④檢查啓動的狀態
$ masterha_check_status --conf=/etc/masterha/app1.cnf
⑤停止mha
$ masterha_stop --conf=/etc/masterha/app1.cnf
⑥多次failover
MHA在每次failover切換後會在管理目錄生成文件app1.failover.complete ，下次在切換的時候如果由於間隔時間太短導致切換不成功，應手動清理掉。
rm -rf /var/log/masterha/app1/app1.failover.complete或者通過加上參數--ignore_last_failover來忽略
⑦手工failover
手工failover場景，適用於在master死掉，而masterha_manager未開啓情形，如下，指定--master_state=dead
masterha_master_switch --conf=/etc/masterha/app1.cnf --dead_master_host=192.168.1.6 --master_state=dead --new_master_host=192.168.1.7 --ignore_last_failover
⑧手動在線切換,如下，指定--master_state=alive
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.1.6 --orig_master_is_new_slave
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.1.6 --orig_master_is_new_slave --running_updates_limit=10000 --orig_master_is_new_slave
表明在切換時原master變爲新master的slave節點
--running_updates_limit=10000
切換時候選master如果有延遲的話，mha切換不能成功，加上此參數表示延遲在此時間範圍內都可切換（單位爲s），但是切換的時間長短是由recover時relay日誌的大小決定