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

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

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 。

三、MySQL復制

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

異步復制

MySQL—MHA架構圖