第4天 二篇、【MHA】故障切換

標籤：mha

MHA故障切換：

一、Master自動監控和容錯移轉

在預設8小時內連續出現故障，則不會切換，可以通過設定--last_failover_minute=(minutes)來縮短時間，但是如果設定了--ignore_last_failover參數，那麼該步驟省略。

        與《MHA高可用架構介紹》中恢複過程一樣，這裡會添加詳細操作：

       1） MHA啟動之後：

            自動檢測主庫的binlog檔案是否存在（通過Executing SSH check script: save_binary_logs）

            自動檢測網路連接（通過Executing secondary network check script: /usr/local/bin/masterha_secondary_check_3307） ---- 我自己的環境截取

       2） MHA宕機之後：

            第一步：配置檢查。存活從庫(192.168.143.242:3307) 

            第二步：通過SSH關閉死去的從庫（我這裡沒有配置shutdown script,所以無法將主機關閉）******************

            第三步：master恢複階段

   * 首先檢查最新的slave和最老的slave所接收的master上的binlog都是否為mysql-bin.000006:2462   * 然後儲存死去master 的binlog日誌(192.168.143.241:3307): save_binary_logs --command=save --start_file=mysql-bin.000006  --start_pos=2462 --binlog_dir=/data/mysql/mysql_3307/binlog --output_file=/var/log/masterha/app2/saved_master_binlog_from_VCrawlerDB-M_3307_20161129170047.binlog --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.56  scp儲存到本地（死去的master）   * 再提升一個新的master，檢查MHA的app2.cnf設定檔是否設定了candidate_master=1參數，如果設定了，提升為新的master；未設定，按IP順序提升   * 識別死去的master與新master資料差異，如果slave的資料比死去的master要老，那麼把這個檔案scp到slave上，通過Executing command: apply_diff_relay_logs 識別差異日誌並補充資料   * 產生 Statement should be: CHANGE MASTER TO MASTER_HOST=‘VCDB-S or 192.168.143.242‘, 產生新Master的change   * 將虛擬IP漂移到新master中Executing master IP activate script: /usr/local/bin/master_ip_failover_app2 --command=start，並關閉唯讀參數set global read_only=0    * 恢複最老的slave資料，如果最老的slave的sql_thread還未執行完，那麼要先等執行完成，然後檢查最老slave執行完成的relay log和position，與最新的master進行對比。   * 當最老的slave把最新master上的relay log補齊之後，MHA將死去master缺失的那部分binlog發送給最老的slave，通過apply_diff_relay_logs命令將資料補齊，之後再使用上面所產生的change master to與最新master進行同步複製關係。

                           

二、Master手工容錯移轉

           

    通過masterha_master_switch --conf=/etc/mha/app2.cnf --master_state=dead --ignore_last_failover --dead_master_host=Master --dead_master_ip=192.168.143.241 --dead_master_port=3307實現

三、線上平滑切換

    masterha_master_switch --conf=/etc/app1.cnf --master_state=alive --orig_master_is_new_slave --running_updates_limit=1

切換包括以下方面：

        第一步：

        1）配置檢查：當前存活的master與slave

        2）輸入yes,在原master上執行flush no_write_to_binlog tables，強制將開啟的表關閉，業務繁忙時，會耗費很長時間。

        3）輸入yes，確認把master切換到slave上

        4）拒絕更新，防止原主庫被寫入資料

            * 將原Master上的虛擬IP清除

            * 設定原master為唯讀模式，set global read_only=1

            * kill掉所有應用連結的線程

            * 執行flush tables with read lock全域鎖

            * 在原master上執行select master_post_wait(mysqld-bin.000023:234324),等待slave把relay log執行完，並產生新的change master to 語句。

        第二步：

1) 將VIP切換到slave1上

2) 設定slave1(新提升的master)為讀寫入模式set global read_only=0

3) 在slave2上執行change master to slave1

4) 在原master上解除鎖表unlock tables

5) 在原master上執行change master slave1

6) 在slave1（新提升的master）上執行reset slave all，清空之前的同步複製資訊

7) 整個切換流程結束

上面的過程，是我根據自己的線上測試日誌與書本結合寫的。大家實驗過程中，慢慢的去看測試日誌，就能瞭解到整個過程的。

本文出自 “崛起” 部落格，請務必保留此出處http://binbinwudi8688.blog.51cto.com/3023365/1878224

第4天 二篇、【MHA】故障切換