MySQL高可用架構之MHA

  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進行復制。

  1、部署環境

  大概部署環境以下：（說明：全部系統均爲centos7.3，其中server0三、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	讀

  2、配置hosts本地解析

  ①四臺機器配置相同的hosts解析。（也能夠在mysql配置文件裏配置忽略名字解析skip-name-resolve）

  

  3、配置四臺主機之間ssh免密登錄（都須要配置哦）。

  

  4、配置mysql服務。

  ①在master（server02）主機上配置mysql主配置文件

   

  ②在其它三個服務器上配置mysql主配置文件（注意：server-id不同，其它配置文件都同樣）。

  

  ③配置好主從節點以後，按MYSQL複製配置架構的配置方式將其配置完成並啓動master節點和各slave節點，以及爲各slave節點啓動其IO和SQL線程，確保主從複製運行無誤。操做以下：

  在master（server02）服務器上受權slave服務器能鏈接數據庫讀取二進制日誌事物。

    

  在其它機器上獲取master的權限，開啓複製功能。（三臺機器同樣）

  

  5、搭建MHA環境和配置服務。

  ①在master（server02）服務器上建立MHA管理複製的帳號。

    

  ②在全部服務器上安裝mha4mysql-node（我是下載好安裝包使用rpm安裝的）

  

  ③在監測主機（monitor host）上安裝mha4mysql-manager

    

  ④定義MHA管理配置文件。

  在manager（server01）配置：

  定義一個統一管理的用戶和目錄，方便之後管理。

  mkdir -p /etc/mha_master/app1

  修改MHA配置文件以下：

    

  ⑤在master（server02）和slave（server0三、04）建立工做目錄

  命令：mkdir /mydata/mha_master/app1

  ⑥檢測各節點之間ssh通信是否ok（server01執行）

   

  ⑦再次在master（server02）執行mysql受權sql語句。【爲了確保各slave服務器節點正常，隨時能夠成爲master服務器】

  

  ⑧masterha_check_repl工具檢查mysql主從複製是否成功 

   

  ⑨啓動MHA

  

  5、測試。

  ①中止master（server02）服務器，查看manager（server01）日誌。

  systemctl stop mariadb (sserver02)

  

  ②查看備用slave是否爲master了。

  

  ③恢復master（server02）。

  

  6、平常操做

  ①校驗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日誌的大小決定