MHA命令系統介紹--masterha_master_switch

介紹:

masterha_master_switch 不監控主庫,但是可以用於主庫宕機後failover,可以用於在線切換主庫

手動failover:

有時候需要手動執行failover機制,masterha_master_switch 命令可以用於 手動執行failover.

eg:

    masterha_master_switch --master_state=alive --conf=/etc/app.cnf  --dead_master_host=host1

常用參數介紹:

--master_state=dead

    強制的參數,參數值爲"dead" 或者 "alive" . 如果 設置爲 alive 模式,masterha_master_switch 開始在線主庫切換操作。


--dead_master_host=(hostname)

    強制參數,宕機的主庫所在的主機名稱。--dead_master_ip 和 --dead_master_port 是可選參數,如果這些參數沒有設置,--dead_master_ip 就是 --dead_master_host 解析的IP地址。--dead_master_port 爲 3306


--new_master_host=(hostname)

    新主機地址,可選參數,這個參數在你明確新的主庫的主機,非常有用。(這就意味着你不需要讓MHA來決定新的主庫)。如果不設置此參數,315直播,MHA 將會利用自動failover的規則來選擇新的主庫。如果設置--new_master_host,MHA選擇此主機爲新的主庫,如果不能成爲主庫,MHA將會退出


--interactive=(0|1)

    如果設置爲0,在masterha_master_switch,它自動執行故障轉移(非交互式)。這實際上是和masterha_manager的內部運行機制一樣,這種非交互式故障轉移是有用的,如果你已經證實了master死了,但你想盡快做故障轉移。非交互式故障轉移也是有用的,如果你使用其他現有的主監控軟件和要調用的非交互式故障轉移命令軟件。典型的例子是masterha_master_switch調用從集羣軟件像起搏器。


--ssh_reachable=(0|1|2)

    指定master 經過SSH是否可達。0:不可達、1:可達、2:未知(默認值)。 如果設置爲了2,此命令內部將會檢測通過SSH 是否可達master,並且跟新SSH 狀態。如果可達,且設置master_ip_failover_script 或者 shutdown_script .將會執行"--command=stopssh"。否則,執行 "--command=stop"。另外,如果宕機的master通過SSH可達,failover腳本試圖從宕機的master機器上拷貝沒有沒有發送的binlog。


--skip_change_master

    如果設置此參數,當發生failover的時候,MAH 在應用完不同的relay log退出,忽略CHANGE MASTER 和 START SLAVE 操作。所以 slaves 不會指向 新的master. 開啓此參數,有利於手動的二次檢查slave 恢復是否成功


--skip_disable_read_only

    設置此參數,MHA 將不會在新的主庫上執行 SET GLOBAL read_only =0 操作,有利於手動操作


--last_failover_minute=(minutes)

    參考master_manager 


--ignore_last_failover

    參考master_manager


--wait_on_failover_error=(seconds)

    類似於master_manager, 此參數只用於自動的/非交互式的failover。如果沒有設置--interval=0,wait_on_failover_error 將會被忽略,在發生錯誤的時候不會sleep。


--remove_dead_master_conf

    參考masterha_manager


--wait_until_gtid_in_sync(0|1)

    此參數從0.56版本開始可用,如果設置成1,當基於GITD的failover時,MHA 會等待所有的從庫追上新主庫的GITD


--skip_change_master

    此參數從0.56版本開始可用,如果開啓此選項,MHA 跳過 CHANGE MASTER 的操作


--skip_disable_read_only

    此參數從0.56版本開始可用,如果開啓此選項,MHA 將會在新的master 跳過 SET GLOBAL read_only = 0;


--ignore_binlog_server_error

    此參數從0.56版本開始可用,如果開啓此選項,當執行failover的時,MHA忽略binlog server上任何錯誤

非交互式Failover

如果在masterha_master_switch中設置"--interactive=0", 它自動執行故障轉移(非交互式)。這實際上是和masterha_manager的內部運行機制一樣,這種非交互式故障轉移是有用的,如果你已經證實了master死了,但你想盡快做故障轉移。非交互式故障轉移也是有用的,如果你使用其他現有的主監控軟件和要調用的非交互式故障轉移命令軟件。典型的例子是masterha_master_switch調用從集羣軟件像起搏器。

[在線] 切換主庫的開關 (Scheduled (Online) Master Switch)

    有時你可能想做預定的主切換,即使當前的master正在運行。典型的例子是取代部分損壞的硬件或升級主服務器。cctv5在線直播,你不能取代一個RAID控制器或增加內存沒有停止服務器。在這種情況下,您需要分配一個預定的維護時間,你必須遷移到不同的服務器的master。

masterha_master_switch命令可以用來運行計劃總開關。

$ masterha_master_switch --master_state=alive --conf=/etc/app1.cnf --new_master_host=host2

--master_state=alive必須設置。調度主開關的程序流與從主故障轉移有稍微的不同。例如,你不需要關閉主服務器,但你需要確保寫查詢不在主上執行。通過設置主ip網上變更腳本,您可以控制阻塞當前master不允許寫(即drop可寫的用戶,設置read_only = 1,等等)在執行FLUSH TABLES WITH READ LOCK,和如何讓寫在新master。

Online master switch開始只有當所有下列條件得到滿足。

 1. IO threads on all slaves are running   // 在所有slave上IO線程運行。

 2. SQL threads on all slaves are running  //SQL線程在所有的slave上正常運行。

 3. Seconds_Behind_Master on all slaves are less or equal than --running_updates_limit seconds  // 在所有的slaves上 Seconds_Behind_Master 要小於等於  running_updates_limit seconds

 4. On master, none of update queries take more than --running_updates_limit seconds in the show processlist output  // 在主上,沒有更新查詢操作多於running_updates_limit seconds 在show processlist輸出結果上。

這些限制的原因是出於安全原因,並儘快切換到新主庫。masterha_master_switch需要以下參數切換時主在線。


    --new_master_host=(hostname)

        新主機地址,可選參數,這個參數在你明確新的主庫的主機,非常有用。(這就意味着你不需要讓MHA來決定新的主庫)。如果不設置此參數,MHA 將會利用自動failover的規則來選擇新的主庫。如果設置--new_master_host,MHA選擇此主機爲新的主庫,如果不能成爲主庫,MHA將會退出


   --orig_master_is_new_slave

        當完成主庫切換後,原先的主庫將作爲現在主庫的slave運行。默認:不開啓(原先的主庫不會加入到新的複製環境中)。如果開啓此選項,需要在配置文件中設置repl_password參數,由於當期的Master並不知道新的Master的replication的密碼


  --remove_orig_master_conf 

        如果設置此參數,當成功failover後,MHA manager將會自動刪除配置文件中關於dead master的配置選項。


  --skip_lock_all_tables

        當在做主庫切換的時候,MHA會在原先的主庫上執行FLUSH TABLES WITH READ LOCK 操作,確保沒有跟新操作,但是FLUSH TABLES WITH READ LOCK 操作是非常耗費資源的,並且你可以在原先的主庫確定沒有跟新操作(通過master_ip_online_change_script 中kill all clients操作等)。可以利用此選項避免鎖表。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章