MHA知識大集合

MHA介紹

MHA是一套用於高可用環境下自動故障切換和主從提高的軟件，在0~30秒之內就能夠完成故障的切換而且能最大限度的保證數據一致性。 github.com/yoshinorim/… 有以下好處： a、自動故障轉移快，秒級就能完成故障切換 b、能夠結合半同步複製，保證主從數據的一致 c、manager節點能夠管理多個MHA集羣系統 d、在運行過程當中，manager節點只是週期性的發送ICMP包，對性能的影響極低 e、只要mysql 複製技術支持的引擎，MHA就支持 宕機後處理： 一、在master出現故障以後，mha會嘗試到故障master節點上面保存未傳輸的binlog日誌 二、識別複製環境中最新的slave肯定下一個master是誰，固然也能夠經過配置文件中直接指定誰是備用主 三、應用差別的中繼日誌到其它slave。在環境中可能存在各個slave不一致的狀況，MHA須要等待全部slave應用完差別的relay log 四、應用在第一步中保存的binlog（這些binlog是還來不及傳輸到slave上的binlog) 五、提高最新的slave爲master 六、其它節點進行change master操做

配置複製環境

配置複製環境

略

配置半同步複製

a)確認plugin dir mysql> show variables like '%plu%'; [root@mysql1 plugin]# ls -l semisync_* -rwxr-xr-x 1 7161 31415 425987 9月 14 2017 semisync_master.so -rwxr-xr-x 1 7161 31415 249167 9月 14 2017 semisync_slave.so b)安裝插件 install plugin rpl_semi_sync_master SONAME 'semisync_master.so'; install plugin rpl_semi_sync_slave SONAME 'semisync_slave.so'; c)肯定插件已經正常安裝 mysql>show status like '%semi%'; mysql> show plugins; d)啓動半同步複製 set global rpl_semi_sync_master_enabled=1; set global rpl_semi_sync_master_timeout=3000; set global rpl_semi_sync_slave_enabled=1; 重啓slave生效 e)確認是否已經開啓 show status like ‘%semi%’; Rpl_semi_sync_master_clients：顯示當前處於半同步模式下slave的數量 Rpl_semi_sync_master_status：顯示master當前是否開啓了半同步模式 Rpl_semi_sync_master_no_tx：當前未成功發送到slave的事務數量 Rpl_semi_sync_master_yes_tx 當前已成功發送到slave的事務數量

安裝配置MHA

3.1 安裝依賴包

yum localinstall -y perl-Log-Dispatch-2.26-1.el6.rf.noarch.rpm perl-Config-Tiny-2.12-1.el6.rfx.noarch.rpm perl-Parallel-ForkManager-0.7.5-2.2.el6.rf.noarch.rpm --此步驟中的包，在系統自帶的yum中是沒有的 yum localinstall perl-Log-Dispatch-2.26-1.el6.rf.noarch.rpm

yum install -y perl-DBD-MySQL perl-Time-HiRes perl-CPAN 可使用yum直接安裝 在0.56的MHA版本里面使用自帶的版本（DBI 1.609，DBD 4.013）便可，若是環境中有了其它版本的DBI、DBD可能會致使在按照MHA node的時候報沒法load DBD的錯誤

安裝MHA

在全部節點上安裝mha-node軟件（包括managed節點），在規劃的managed節點上面安裝managed軟件，安裝遵循三部曲 #源碼安裝三部曲
perl Makefile.PL 注意執行這部的時候會檢查須要的包，須要肯定全部依賴組件都能被load make make install

3.3 配置MHA

3.3.1 Ssh配置 a)修改/etc/hosts文件，加入全部節點的ip信息 b)使用腳本配置ssh信任

./ssh_setup -user root -hosts "node1 node2 node3 node4" -advanced -noPromptPassphrase 3.3.2 數據庫配置 a)配置從庫read_only參數 set global read_only=1 說明：若是不配置read_only參數，在啓動mha的時候會提示警告，可是不會出現error。 b)配置relay_log的清除方式 set global relay_log_purge=0 說明：在複製過程當中可能會出現不一樣步的狀況，好比slave1比slave2塊，那麼在切換的時候就須要把slave1上的relay log應用到slave2上，若是不設置relay_log_purge=0那麼可能會出現丟失relay log的狀況。在mha環境中，可使用MHA提供的腳本去清除relay log文件。 eg：可使用MHA提供的腳本進行刪除 purge_relay_logs --user=root --password=123456 --port=3306 -disable_relay_log_purge --workdir=/data/

3.4 部署relay log清理腳本

在MHA發生故障的切換過程當中，slave的恢復須要依賴於最新的relay log，若是設置爲relay log的自動清除，那麼relay log會在sql線程執行完畢後自動清理relay log，在發生故障切換的時候就可能會致使沒法作恢復，因此須要設置爲relay log爲手工清除，在MHA中可使用MHA提供的pure_relay_logs腳原本進行監控。

a)pure_relay_logs清理的原理：

一、爲relay log建立硬連接

二、set global relay_log_purge=1;flush logs; set global relay_log_purge=0;

三、刪除relay log

b)使用方式：

purge_relay_logs --user=admin --password=123 --host=172.1.1.103 --port=3306 -disable_relay_log_purge --workdir=/data/

c)部署自動清理腳本（全部節點部署，不要使用vip）

--編輯腳本

#!/bin/bash

host=172.1.1.103

user=admin

passwd=admin

port=3306

log_dir='/var/log/masterha/tpcc/'

work_dir='/data/mysql/data/'

purge='/usr/local/bin/purge_relay_logs'

if [ ! -d $log_dir ]

then

mkdir $log_dir -p

fi

user --password=host --port=work_dir >> $log_dir/purge_relay_logs.log 2>&1 --添加權限

chmod +x /root/script/purge_relay_log.sh

--配置crontab

略

###3.5 編寫mha配置文件 [root@node4 ~]# cat /etc/masterha/slave.conf [server default] manager_log=/var/log/masterha/tpcc/manager.log manager_workdir=/var/log/masterha/tpcc master_binlog_dir=/data/my3306/binlog master_ip_failover_script=/usr/local/bin/master_ip_failover master_ip_online_change_script=/usr/local/bin/master_ip_online_change password=123 ping_interval=3 remote_workdir=/data/tmp repl_password=123 repl_user=repl secondary_check_script=/usr/local/bin/masterha_secondary_check -s node2 -s node3 ssh_user=root user=admin [server1] candidate_master=1 hostname=172.1.1.101 port=3306 [server2] #candidate_master=1 hostname=172.1.1.102 port=3306 [server3] hostname=172.1.1.103 port=3306 --user GRANT ALL PRIVILEGES ON . TO 'mha_admin'@'172.1.1.%' 注意：secondary_check_script的做用是二次檢測master的網絡，若是沒有配置該參數，只要managed到master的網絡出了問題就會認爲master故障，可是多是managed自己的網絡出了問題。當發現master網絡不通的時候，managed節點會經過secondary_check_script設置的其它節點去檢查網絡，若是managed經過配置的其它節點去檢查master，master狀態也有問題那麼就認爲master真的是掛了，若是managed節點到secondary_check_script配置的任何一個節點都不通就會認爲是managed的網絡故障，不會發起failover。注意secondary_check_script配置節點也須要配置ssh等效性。 說明：manager_workdir是mha的工做目錄，在切換的時候會把master主機上面的binlog日誌保存到manager節點上的manager_workdir目錄中，因此必需要保證有足夠的空間，若是沒有則會自動建立一個。 master_binlog_dir ：指定masterbinlog的位置，若是指定位置錯誤會報錯Failed to save binary log: Binlog not found from /data/my3306/binlog master_ip_failover_script：MHA在檢測到故障後，只是會進行提高master和對其它slave作change master的操做，若是還須要執行什麼腳本，能夠經過這個參數去指定。通常用於keepalive切換VIP，同那個online切換腳本同樣，腳本中的VIP配置只是用於MHA日誌中輸出的VIP，決定真正VIP的仍是keepalive配置文件中的那個VIP user：MHA的管理用戶，mysql中的，默認狀況下是root，須要的權限較高。由於須要執行start/stop slave,change master ,reset slave等操做。 Ssh_user:使用ssh登陸的用戶，用於獲取binlog remote_workdir:在發生failover的時候，master須要保存本身的binlog，這個路徑就會放在remote_workdir指定的目錄中

3.6 檢查ssh和複製狀況（manager執行）

masterha_check_ssh --conf=/etc/masterha/slave.conf masterha_check_repl –conf=/etc/masterha/slave.conf 注意：在執行檢查的時候須要暫時註釋掉master_ip_failover_script，由於此時這個腳本還未有建立

3.7 啓動MHA

nohup masterha_manager --conf=/etc/masterha/slave.conf --remove_dead_master --ignore_last_failover >> /var/log/masterha/tpcc/manager.log 2>&1

注意：建議使用追加的方式，不然每次啓動都會覆蓋上次的日誌。

啓動MHA以前，配置複製參數
複製代碼

3.8 編寫MHA管理腳本

附件

3.9 檢查

略

4 安裝配置keepalived

4.1安裝配置keepalived

Yum install keepalived

全部節點都須要安裝

4.2 編輯keepalived配置文件

global_defs {

notification_email {

root@localhost
複製代碼

}

notification_email_from keepalived@localhost

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id mysql2

}

vrrp_instance VI_20 {

state BACKUP

nopreempt

interface eth0

virtual_router_id 20

priority 150

advert_int 5

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

172.1.1.100 label eth0:1

}

}

注意：一、雖然keepalive也能檢查mysql的狀態，可是爲了不keepalive和MHA切換不一樣步的問題，keepalive只用來掛載VIP

二、router_id必須同樣認證也須要同樣

三、都須要配置爲backup狀態，由於若是是master-backup模式，故障節點修復後，若是priority叫高就會搶佔vip，這時候MHA並無切換就會形成故障。

4.3 啓動keepalive和MHA

Service keepalived start

nohup masterha_manager --conf=/etc/masterha/slave.conf --remove_dead_master --ignore_last_failover >/var/log/masterha/tpcc/manager.log 2>&1

說明：--remove_dead_master,若是不加這個參數，那麼在發生故障切換的時候是不會從配置文件中清除dead master的信息，這個時候若是在dead master上的故障未修復，直接啓動MHA，那麼會報錯。

--ignore_last_failover，若是不加該參數，那麼在默認狀況下MHA在作完failover以後的6個小時以內是不會再次作failover的（目的是避免頻繁的切換），若是發生故障切換，會報錯「Current time is too early to do failover again」，加上這個參數以後就會忽略最近一次切換。

後期發現的問題：Keepalived若是在主從都啓動，在切換的時候可能會致使vip掛錯節點的問題。若是隻在master上面啓動keepalive，在slave上面關閉，就沒有這個問題

4.4 切換檢查

檢查MHA是否能正常切換

檢查VIP是否能跟隨MHA切換

5 MHA在線切換

5.1 切換前提

l 全部slave的io_thread和sql_thread都在運行中。

l 全部slave的Seconds_Behind_Master小於或等於running_updates_limit的值，該參數若是沒有顯示指定的話，則默認爲1s。

5.2 切換方式

a)中止MHA監控

masterha_stop --conf=/etc/masterha/slave.conf

b)切換

/usr/local/bin/masterha_master_switch --conf=/etc/masterha/slave.conf --master_state=alive --new_master_host=172.1.1.102 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=2

c)檢查主備的read_only參數

注意：

一、須要有master_ip_online_change這個腳本

二、master_state用於指定切換時master的狀態，若是master出現故障，可是自動failover出現故障，那麼這個時候就可使用master_state=dead的方式切換

三、orig_master_is_new_slave 用來控制orig master的狀態，若是不加這個參數，orig master在切換後就會脫離複製環境，加了該參數在切換以後，orig master會自動切換爲new master的從。

四、running_updates_limit，若是延遲在該參數的指定範圍內都會進行切換。

5.3 切換過程

一、分析配置

--分析當前的配置環境

--執行flush no_write_to_binlog tables

二、阻止對原master的寫入

--設置old master的read_only=1

--disabled old master vip

--kill全部的鏈接

--執行flush tables with read lock;

三、提高new master

--等待new master執行完成全部的relay log

--獲取新master上面的binlog信息

--在new master上面啓動vip

--取消old master上面的read lock

--執行change master的操做

四、清理new master上面的slave信息

5.5 注意事項

全部的slave都必須處於活動狀態MHA才能進行切換。

MHA啓動以後就只會監控master的狀態，對slave的重啓、增長、移除等都不會影響MHA，若是增長了slave，須要更新MHA的配置文件。

若是MHA最近一次切換距離如今太近，將不會進行故障切換。

6.MHA常見的坑

6.1 原主庫failover以後不能加入複製拓撲

對於gtid_purge來講，若是當前數據庫的角色是主庫，那麼gtid_purge表示這些gtid已經不在當前binlog中了;若是當前數據庫是備庫，那麼表示已經執行過的gtid。那麼在主庫作了failover以後，那麼原來主庫中的gtid purge值確定須要修改，若是直接使用change master加入複製一定會報錯。 方法：reset master; set @@global.gtid_purge=xxx; change master to xxx; start 具體的gtid_purge信息能夠在mha的切換日誌中保留

6.2 failover以後，加入複製拓撲以前保留binlog

由於在原主庫加入複製以前須要作reset master操做，這個過程會清理當前環境中全部的binlog，若是在清理了以後發生數據庫損壞須要使用binlog作恢復的時候，那麼就會由於沒有binlog致使沒法作數據恢復。

6.3 MHA+keepalived時候VIP的坑

在MHA+keepalived環境中，vip必須和master綁定在一塊兒的。若是全部節點都啓動了keepalive，而且全部節點的優先級都配置爲同樣，那麼在發生failover的時候就能致使master和vip不在一個節點上面（畢竟mha不能控制keepalived）若是備庫恰好又沒有配置read_only那麼就可能致使腦裂的問題。 解決方法有兩個：

• 只在master上面啓動keepalived，由於在作failover的時候切換腳本會作service keepalived start、stop的操做，這樣就能夠保證master上面必定會運行keepalived
• 若是必定要啓動keepalived，那麼在mha配置文件中指定備用master，同時調整該備用master上面keepalived的優先級。

常見問題處理

一、Sat Dec 14 21:56:45 2019 - [error][/usr/local/share/perl5/MHA/ServerManager.pm, ln492] Server 172.1.1.22(172.1.1.22:3306) is dead, but must be alive! Check server settings 緣由：要啓動mha，必需要mha配置文件中的全部節點都正常啓動

二、Sat Dec 14 22:02:43 2019 - [error][/usr/local/share/perl5/MHA/ServerManager.pm, ln653] There are 2 non-slave servers! MHA manages at most one non-slave server. Check configurations. 緣由：在mha配置的節點中發現了兩個master，通常狀況下是由於作了failover以後，啓動了原主庫，在原主庫尚未加入新複製拓撲的狀況下就啓動mha，這個時候就會報錯