高可用mysql之MHA源碼剖析

標籤：

* MHA的整個故障（離線）切換過程

----------------------------------------------------------------------------------------------------
-檢測主庫的狀態，確認是否崩潰。
- 確認服務崩潰，儲存binlog，推送到主控機，並可以強制關閉主庫避免腦裂。
- 找出資料最新的從庫（也就是read_master_log_pos最大的），確定下新主庫。
- 從最新從庫上產生差異的relaylog，再加上未讀取的binlog，應用到新主庫，記下位移。
- （並發）的為其他從庫產生差異的relaylog和binlog，應用到各個從庫。
- 從庫指向新主庫的位移處，開始複製。

源碼部分關鍵邏輯

--------------------------------------------------------------------------------------------------------
**讀取配置
**檢查配置
-檢查apply_diff_relay_log的版本號碼
-串連所有伺服器並讀取狀態（得知老主庫）
-檢查參數傳進來的崩潰主庫是否與老主庫地址一致，否則終止切換
-檢查老主庫是否在離線主機列表中，不在的話就終止切換
-檢查是否真的串連不上mysql服務
-檢查所有線上從庫，是否都指向老主庫
-檢查是否有些不該忽略失敗的從庫已經離線
-檢查上次切換是否失敗
-檢查上次切換髮生時間與本次切換的時間間隔，太短則終止
-從所有從庫擷取“切換鎖”
-保證所有從庫的slave sql線程已經啟動
**如果支援gtid自動定位但未啟用，那麼應該強制apply_diff_relay_log禁用log_bin？？
**強制關閉
-（並發）強制停止所有從庫的slave io線程
-探測從主控機到崩潰主庫所在主機的ssh可達性
-執行master_ip_failover_script，保證崩潰主庫所在主機的ip失活防腦裂，否則終止切換
-只要有一個線上從庫的salve io線程停止失敗，那麼就終止切換

**探測出複寫延遲最小的從庫、複寫延遲最大的從庫
**根據最新從庫的slave io線程的讀頭，儲存老主庫的binlog。
-如果崩潰主庫所在主機不可達，那麼久丟失binlog（Read_Master_Log_Pos to the tail）
-如果可達，ssh串連上去，然後執行save_binary_logs --command=save，將儲存後的binlog拷貝到主控機，這步稱呼read_to_tail。
**根據最新、最老從庫的讀頭以及某些從庫的可忽略失敗，來決定哪個從庫作為relaylog、binlog補償的基準
-如果所有從庫的讀頭一致，跳過
-ssh逐一串連最新從庫，執行apply_diff_relay_logs --command=find，看是否realylog包含了最老從庫的讀頭。
-如果沒有用來補償的基準從庫，終止切換
**選擇新主庫（新主庫不一定是最新從庫，參照“線上切換”中的描述）
**恢複新主庫
-若果新主庫的讀頭落後於最新從庫，那麼ssh串連上最新從庫，執行apply_diff_relay_logs --command=generate_and_send，
從最新從庫的relaylog中提取新主庫讀頭直到最新從庫讀頭處的二進位日誌，這步稱呼為read_to_latest,
$latest_slave->{Master_Log_File}:$latest_slave->{Read_Master_Log_Pos}
-將主控機儲存好的最新從庫讀頭到主庫binlog尾部的日誌（read_to_tail），拷貝到新主庫
-如果不是最新從庫或者有儲存過read_to_tail，那麼就應用差異日誌。
--首先等待新主庫上已經有的relaylog都重放完畢，停止slave sql線程
--讀取最新複製狀態
--ssh執行save_binary_logs --command=save， 從自身relaylog中恢複exec_to_read
--ssh執行apply_diff_relay_logs --command=apply，將前面產生的3部分補償日誌全部匯入。
-執行主控機上的master_ip_failover --command=start指令碼，啟用新主庫的ip。
-關閉新主庫的唯讀，開啟可寫入模式。
**恢複所有從庫（類似單獨恢複主庫的過程）
-（並發）中繼補償，產生read_to_latest
-（並發）將早產生的read_to_tail部分，拷貝到各個從庫，應用差異日誌，指向新主庫，啟動複製
-新主庫執行reset slave

 

 

*MHA線上主庫切換過程

--------------------------------------------------------------------------------------------------------------------------------------
sudo /usr/bin/masterha_master_switch --master_state=alive --conf=/etc/masterha/app1.cnf --new_master_host=192.168.128.130 --new_master_port=3309 --orig_mast\
er_is_new_slave

**識別老主庫。
-讀取配置MHA設定檔；

-串連並讀取所有的資料庫服務狀態；
-（並發）串連所有從庫，看mysql服務是否在運行，如果機器都宕機了，那就終止本次切換。
-遍曆每台從庫，擷取所有能擷取的資訊，比如：msyql服務版本號碼、是否開啟了gtid、是否開啟了log-bin、
是否唯讀、複製相關係統變數和狀態變數。
-統計伺服器資訊：離線伺服器、線上服務器、線上從庫、失敗從庫等。
-比較所有從庫的mysql服務版本，找出最老和最新的版本。
-驗證當前真正的主庫是誰？
-統計線上服務器中的“非從庫”（not_slave）標記，只能為1，否則終止本次切換過程。
-根據從庫的指向來找出存在哪些主庫（支援3層複製結構（主-從-從的從））。
真正的主庫必須是在“線並且可寫”，如果沒有一台主庫可寫或者存在兩台可寫，那麼終止切換。
-判斷本次切換是否支援gtid。

-檢查所有線上從庫上是否有複製賬戶並有相應的REPLICATION SLAVE許可權；
-必要時在老主庫上進行flush tables操作；
-從老主庫擷取“監視鎖”；
-從所有從庫擷取“切換鎖”；
-檢查所有線上從庫的複製健康情況；
-讀取當前的複製狀態；
-判斷是否有問題（IO、SQL線程是否在運行，資料延遲多久）

**識別新主庫。
-識別資料最新的從庫；
-比較master_log_file:read_master_log_pos。
-選擇新主庫；
- 識別優先從庫，線上的並帶有candidate_master標記。
-識別應該忽略的從庫，帶有no_master標記、或者未開啟log_bin、或者mysql服務版本不是最老、與最新從庫相比資料延遲比較大。
-選擇優先順序依次為：優先列表、最新從庫列表、所有從庫列表，但一定要排除忽略列表。
-檢查新老主庫的複製過濾規則是否一致；
-Binlog_Do_DB、Binlog_Ignore_DB、Replicate_Do_Table等。

**拒絕更新，防止腦裂。
-調用master_ip_online_change指令碼，stop子命令。新主庫上，設定為唯讀；
老主庫上，禁止會話層級的log_bin、優雅等待所有sql線程退出、設定為唯讀、
-必要時，在老主庫，鎖住所有表，並檢查binlog是否已經停止前進。
binlog停止前進後，記下位移位置。

**重新讀取所有線上從庫的運行狀態。

**新主庫從老主庫應用完所有的事件記錄。
-新主庫上，執行master_pos_wait，然後記下新主庫binlog的file:pos。
-調用master_ip_online_change指令碼，start。新主庫上，設定為唯讀。

** （並發）從庫應用完老主庫所有的事件記錄並指向新主庫。
-master_pos_wait
-change_master_and_start_slave

高可用mysql之MHA源碼剖析