MySQL MHA應用實踐（基礎知識）

1、MHA概述
MHA（Mater High Availability）是一套很是流行和實用的MySQL高可用解決方案軟件，保證MySQL主從複製集羣中主庫的高可用性，保證集羣業務不受影響。當master異常宕機後，MHA可以保證在1~30s的時間內實現故障轉移，選擇一個最優slave升爲最新master，同時保持數據一致性的狀態，以及將整個集羣的全部數據損失降到最低。所以MHA方案十分受歡迎。
2、MHA架構
MHA由Manager（管理節點）和Node（數據節點）組成。Manager服務能夠運行在一臺讀立服務器（虛擬機）上管理多個主從集羣，也能夠是某一個從節點或者應用服務器節點，而Node服務須要運行在每個MySQL服務器上。Manager會定時經過主庫上的Node服務監控主庫，確保主庫出現故障時可自動（或指定）將最優從庫升爲新主庫，讓全部從庫與最新master保持正常。
3、切換原理

3.1 MHA自動切換的原理：
MHA的全名叫作mysql-master-ha，配置後能夠在10-30秒內完成master自動切換，切換過程以下：
1. 檢測master的狀態，方法是一秒一次「 SELECT 1 As Value」，發現沒有響應後會重複3次檢查，若是尚未響應，shutdown並再重複一次SELECT 1 As Value確認master關閉
2. 確認SSH到master所在的機器是否可達
3. 給出消息：Connecting to a master server failed，並開始讀取配置文件masterha_default.conf和app1.conf
4. 確認複製切換模式: [info] GTID failover mode = 1
5. 報告整個架構中的機器存活狀況
6. 檢查存活的實例版本、GTID開啓狀況、是否開啓read_only以及複製過濾狀況
7. 接下來就是在GTID複製基礎上的切換過程
(1) 配置檢查階段，具體檢查以下
(2)完全關閉master鏈接的階段，避免master未關閉致使的腦裂，關閉完成後給出報告
(3)master恢復階段：
›1   確認relay log最新的slave實例
›2   肯定新的master
若是在配置文件中設置了候選master,會直接肯定預設機器實例爲master；若是沒有預設，會選擇含有最新的relay log的那個slave
›3   確認新的master後，會先設置sql_log_bin=0以阻塞master日誌寫入使其餘slave遇上覆制，應用該最新relay log，最終得到這個層次的數據一致性，以後再set sql_log_bin=1使恢復日誌寫入。能夠經過半同步複製來解決沒法ssh到master所在機器所形成的事務丟失問題
待所有數據一致後，經過show master status肯定新master的日誌位置並在其餘slave上執行change master語句建立新的主從鏈接
該階段成果後給出報告
Fri Jul  1 13:35:33 2016 - [info] ** Finished master recovery successfully.
Fri Jul  1 13:35:33 2016 - [info] * Phase 3: Master Recovery Phase completed.
(4)slaves恢復階段：
先中止IO線程，等待SQL線程執行完成後，stop slave，清除原slave信息，從新change master指向新的master，start slave ，over
(5)清除新選出的master上的slave信息
reset slave all;
至此，整個切換過程完成，最後給出切換報告

3.2 MHA在線切換的原理:
1. 檢查當前的配置信息及主從服務器的信息
包括讀取MHA的配置文件/etc/masterha/app1.cnf及檢查當前slave的健康狀態
2. 阻止對當前master的更新
主要經過以下步驟：
1> 等待1.5s（$time_until_kill_threads*100ms），等待當前鏈接斷開。
2> 執行 read_only=1，阻止新的DML操做
3> 等待0.5s，等待當前DML操做完成。
4> kill掉全部鏈接。
5> FLUSH NO_WRITE_TO_BINLOG TABLES
6> FLUSH TABLES WITH READ LOCK
3. 等待新master執行完全部的relay log
Waiting to execute all relay logs on 192.168.244.20(192.168.244.20:3306)..
4. 將新master的read_only設置爲off，並添加VIP
5. slave切換到新master上。
1> 等待slave（192.168.244.30）應用完原主從複製產生的relay log，而後執行change master操做切換到新master上。
2> 釋放原master上加的鎖。
3> 因masterha_master_switch命令行中帶有--orig_master_is_new_slave參數，故原master也切換爲新master的從。
6. 清理新master的相關信息。
主要是執行了reset slave all操做，清除以前的複製信息。

註釋：應用訪數據集羣時能夠採用keepalived 。

3、MySQL複製

異步複製（Asynchronous replication）
     MySQL默認的複製便是異步的，主庫在執行完客戶端提交的事務後會當即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主若是crash掉了，此時主上已經提交的事務可能並無傳到從上，若是此時，強行將從提高爲主，可能致使新主上的數據不完整。
全同步複製（Fully synchronousreplication）
    指當主庫執行完一個事務，全部的從庫都執行了該事務才返回給客戶端。由於須要等待全部從庫執行完該事務才能返回，因此全同步複製的性能必然會收到嚴重的影響。
半同步複製（Semisynchronous replication）
    介於異步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是馬上返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製，半同步複製提升了數據的安全性，同時它也形成了必定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。因此，半同步複製最好在低延時的網絡中使用。

異步複製

MySQL—MHA架構圖