MHA
一：簡述MHA
1.1關于MHA
MHA（Master HA）是一款開源的MySQL的高可用程序，它為MySQL主從復制架構提供了automating master failover 功能。MHA在監控到master節點故障時，會提升其中擁有最新數據的slave節點成為新的master節點，在此期間，MHA會通過與其它從節點獲取額外信息來避免一致性方面的問題。MHA還提供了master節點的在線切換功能，即按需切換master/slave節點。
相較于其它HA軟件，MHA的目的在于維持MySQL Replication中Master庫的高可用性，其最大特點是可以修復多個Slave之間的差異日志，最終使所有Slave保持數據一致，然后從中選擇一個充當新的Master，并將其它Slave指向它。
————————————————————————————-
1.2 MHA角色部署
MHA 服務有兩種角色，MHA Manager（管理節點）和MHA Node（數據節點）：
MHA Manager：通常單獨部署在一臺獨立的機器上或者直接部署在其中一臺slave上（不建議后者），管理多個master/slave集群，每個master/slave集群稱作一個application；其作用有二：
（1）master自動切換及故障轉移命令運行
（2）其他的幫助腳本運行：手動切換master；master/slave狀態檢測
MHA node：運行在每臺MySQL服務器上（master/slave/manager），它通過監控具備解析和清理logs功能的腳本來加快故障轉移。其作用有：
（1）復制主節點的binlog數據
（2）對比從節點的中繼日志文件
（3）無需停止從節點的SQL線程，定時刪除中繼日志
————————————————————————————-
1.3 MySQL復制集群中的master故障時，MHA按如下步驟進行故障轉移：
從上圖可總結MHA工作步驟為：
-從宕機崩潰的master保存二進制日志事件(binlogevents)。
-識別含有最新更新的slave。
-應用差異的中繼日志(relay log)到其它slave。
-應用從master保存的二進制日志事件(binlogevents)。
-提升一個slave為新master。
-使其它的slave連接新的master進行復制。
————————————————————————————-
1.4 MHA組件：
(1)、 Manager工具:
– masterha_check_ssh : 檢查MHA的SSH配置。
– masterha_check_repl : 檢查MySQL復制。
– masterha_manager : 啟動MHA。
– masterha_check_status : 檢測當前MHA運行狀態。
– masterha_master_monitor : 監測master是否宕機。
– masterha_master_switch : 控制故障轉移(自動或手動)。
– masterha_conf_host : 添加或刪除配置的server信息。
(2)、 Node工具(這些工具通常由MHAManager的腳本觸發,無需人手操作)。
– save_binary_logs : 保存和復制master的二進制日志。
– apply_diff_relay_logs : 識別差異的中繼日志事件并應用于其它slave。
– filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用這個工具)。
– purge_relay_logs : 清除中繼日志(不會阻塞SQL線程)。
(3)、自定義擴展：
-secondary_check_script：通過多條網絡路由檢測master的可用性；
-master_ip_failover_script：更新application使用的masterip；
-shutdown_script：強制關閉master節點；
-report_script：發送報告；
-init_conf_load_script：加載初始配置參數；
-master_ip_online_change-script：更新master節點ip地址；
=================================================
二：準備 MySQL Replication 環境
由于主節點有可能會被切換成從節點，而每一個從節點也有可能會被切換成主節點，所以MHA對Mysql復制環境有特殊要求，例如：
（1）各節點都要開啟 二進制日志及中繼日志；
（2）各從節點必須顯示注明其為 read_only；
（3）關閉各從節點的 relay_log_purge 中繼日志自動清理功能
本實驗環境共有四個節點，其角色配置如下：
node1：MariaDB master
node2：MariaDB slave
node3：MariaDB slave
node25：MHA Manager
各節點的/etc/hosts 文件配置內容如下：
初始主節點 master 配置 ：
server-id = 1
relay-log = relay-log
log-bin = bin-log
innodb-file-per-table = ON
skip-name-resolve = ON
所有slave節點配置：
server-id = 2 #復制集群中的各節點server_ip必須唯一
relay-log = relay-log
log-bin = bin-log
innodb-file-per-table = ON
skip-name-resolve = ON
relay-log-purge = 0
read-only = 1
按上述要求分別配置好主從節點之后，按MySQL復制配置架構的配置方式將其配置完成，并啟動master節點和個slave節點，以及為各slave節點啟動其IO和SQL線程，確保主從復制無誤。
而后，在所有Mysql節點授權擁有管理權限的用戶可在本地網絡中有其他節點上遠程訪問。當然，此時僅需要且只能在master節點上運行類似如下SQL語句即可：
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO ‘mhauser’@’HOST’ IDENTIFIED BY ‘mhapasswd’
其他節點也可以手動輸入上邊的SQL語句，也可以在從服務器指定主服務器的時候，指定的bin-log文件的位置時，包含次語句：
而從節點相對應的運行SQL語句為：
CHANGE MASTER TO MASTER_HOST=’10.1.35.1′,MASTER_USER=’mhauser’,MASTER_PASSWORD=’mhapasswd’,MASTER_LOG_FILE=’master-log-000003′,MASTER_LOG_POS=420;
=================================================
三、安裝配置 MHA
3.1 準備基于ssh互信通信環境
MHA 與 ansible 類似 ，集群中的各節點彼此之間均需要基于ssh互信通信，以實現遠程控制及數據管理功能。
簡單起見，可在Manager節點生成密鑰對，并設置其可遠程連接本地主機后，將私鑰文件及authorized_keys 文件復制給余下的所有節點即可。
下面的操作可在manager節點操作：
[root@node25 .ssh]# ssh-keygen -t rsa -P ”
[root@node25 .ssh]# cat ./id_rsa.pub >> authorized_keys
[root@node25 .ssh]# chmod go= ./authorized_keys
然后再使用scp命令將id_rsa 和 authorized_keys 文件分發至各節點
—————————————————————————
3.2 安裝MHA
除了源碼包，MHA官方也提供了rpm格式的程序包。centos7 系統可以直接使用使用與e16的程序包。另外，MHA Manager 和 MHA Node 程序包的版本并不強制要求一致。
Manager節點（需要將Manager包和Node包一起安裝）：
~]# yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm
Node節點：
~]# yum install -y ./mha4mysql-node-0.56-0.el6.noarch.rpm
—————————————————————————
3.3 初始化 MHA
Manager 節點需要為每個監控 master/slave 集群提供一個專用的配置文件，而所有的master/slave 集群也可以共享全局。全局配置文件默認為 /etc/masterha_default.cnf ，其為可選配置。如果僅監控一組master/slave集群，也可以通過application的配置來提供各服務器的默認配置信息。而每個application的配置文件路徑為自定義。
例如，本示例中將使用 /etc/masterhs/app1.cnf，內容如下：
[server default]
user=mhaadmin #mha用于管理數據庫的賬號，盡量不要使用root賬號，權限過大，root可以用root授權其他用戶
password=mhapasswd
manager_workdir=/data/masterha/app1
manager_log=/data/masterha/app1/manager.log
remote_workdir=/data/masterha/app1
ssh_user=root
repl_user=mhauser #mysql主從復制的賬號
repl_password=mhapasswd
ping_interval=1 #檢測主服務器健康狀態的時間間隔，單位為秒
[server1]
hostname=10.1.35.1
#ssh_port=22022
candidate_master=1 #1表示主服務宕機的時候，該節點可以提升為主節點；如果不提升為主節點，則為no_master=1
[server2]
hostname=10.1.35.2
#ssh_port=22022
candidate_master=1
[server3]
hostname=10.1.35.3
#ssh_port=22022
candidate_master=1
———————————————————
由于還需要一個mysql賬號，用于給予mha管理mysql，所以，可以直接在主服務器上創建賬號，并授予其權限，由于已建立了主從復制關系，所以，無需在其它從節點上重復創建賬號：
———————————————————
檢測各節點間ssh互信通信配置時候OK：
~]# masterha_check_ssh–conf=/etc/master/app1.cnf
檢測成功，最后會提示 All SSH connection tests passed successfully.
———————————————————
檢查管理Mysql復制集群的連接配置參數是否OK（即repl_user與repl_assword是否正確）
檢測成功，最后會提示 Health is OK
但是會提示：
（1）沒有定義主服務器宕機的時候，VIP地址轉移的腳本，用于轉移master前先配置VIP，需要自行編寫，以可以結合keepalive來進行轉移；此時先使用真正的IP進行測試線
（2）沒有定義關閉主服務的腳本，但是rpm包自帶有一個/usr/bin/masterha_stop；
———————————————————
啟動MHA：
~]# masterha_manager –conf=/etc/master/app1.cnf > /data/masterha/app1/manager.log &>1 &
將MHA 輸出的日志信息重定向至指定的日志文件中
———————————————————
啟動成功后，可通過如下命令查看master節點的狀態：
~]# masterha_check_status –conf=/etc/master/app1.cnf
———————————————————
停止MHA ，運行命令：
~]# masterha_stop –conf=/etc/master/app1.cnf
———————————————————
3.4 測試故障轉移：
（1）在master節點關閉mariadb服務
killall -9 mysql mysqld_safe
（2）查看日志/data/masterha/app1/manager.log
由日志文件可看出，node2已經成為新的master，而node3復制的指向也改為node2了
在節點2上查看slave狀態，已經表明slave停止了，顯然成為了master
在節點3上查看slave狀態，master_server_id已經改為2了
注意：當故障轉移后，manager將會自動停止，此時使用masterha_check_status命令將會遇到錯誤提示，如下：
———————————————————
（3）提供新的從節點以及修復復制集群
原有的master節點故障后，需要重新準備一個新的MySQL節點?；趤碜杂趍aster節點的備份數據恢復后，將其配置為新的master的從節點即可。
注意，新加入的節點如果為新增節點，氣IP地址要配置為原來master節點的IP，否則，還需要修改app1.cnf中相應的IP地址。隨后再次啟動manager，并再次檢測其狀態。
在修復由于宕機而下來的服務器時，盡量不要使用腳本進行修復，檢查好數據的完整性后再上線。
=====================================================
四、進一步工作
前邊三個步驟已經配置了一個基本的MHA環境。不過，為了更多實際應用的要求，還需要進一步完成如下操作。
（1）提供額外的檢測機制，以免master的監控做出誤判
（2）可借助keepalive等高可用服務，在master節點上提供VIP地址對外提供服務，以免master節點轉換時，客戶端的請求無法送達；
（3）進行故障轉移時對原master節點執行stonith操作，以避免腦裂；可通過指定的shutdown_script實現；
（4）必要時，進行在線master節點轉換；
、
原創文章，作者：hunter，如若轉載，請注明出處：http://www.www58058.com/61111
