MYSQL實現高可用MHA
MHA 對MYSQL 復制環境有特殊要求，例如各節點都要開啟二進制日誌及中繼日誌，各從節點必須顯示啟用其read-only 屬性，並關閉relay_log_purge 功能等，這裏對配置做事先說明。
本實驗環境共有四個節點，其角色分配如下：
centos7.3:MariaDB master
centos7.4: MariaDB slave
centos7.5：MariaDB slave
centos7.6: MHA Manager
1 、初始主節點centos7.3 配置：
[mysqld]
server-id = 1
log-bin = master-log
relay-log = relay-log
skip_name_resolve = ON
2 、所有centos7.5和7.4 節點依賴的配置：
[mysqld]
server-id = 2 # 復制集群中的各節點的id 均必須唯一；
relay-log = relay-log
log-bin = master-log
read_only = ON
relay_log_purge = 0 # 是否自動清空不再需要中繼日誌
skip_name_resolve = ON
3 、按上述要求分別配置好主從節點之後，按MYSQL 復制配置架構的配置方式將其配置完成並啟動master 節點和各slave 節點，以及為各slave 節點啟動其
master 節點上：
MariaDB [(none)]>grant replication slave on *.* to '[email protected].%.%' identified by 'magedu';
MariaDB [(none)]> flush privileges;
MariaDB [(none)]>show master status;
各slave 節點上：
[root@node3 ~]# mysql
MariaDB [(none)]>change master to master_host= ’
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;
三、 安裝配置MHA
1 、在所有MYSQL 節點授權擁有管理權限的用戶可在本地網絡中有其他節點上遠程訪問。當然，此時僅需要且只能在master 節點運行類似如下SQL 語句即可。
mysql> GRANT ALL ON *.* TO 'mhaadmin'@'172.17.%.%' IDENTIFIED BY'mhapass';
2 、準備基於SSH 互信通信環境：
MHA 集群中的各節點彼此之間均需要基於ssh 互信通信，以實現遠程控制及數據管理功能。簡單起見，可在Manager 節點生成密鑰對兒，並設置其可遠程連接本地主機後，將私鑰文件及authorized_keys 文件復制給余下的所有節點即可。
下面操作在node4 ：Manager 節點上操作：
[root@node4 ~]# ssh-keygen -t rsa
[root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@ip
註意：主從數據庫相互之間要實現無密碼登錄，MHA manager 要能登錄另外三臺就可以了。
3 、 進行MHA 安裝包安裝
Manager 節點： yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
所有節點，包括Manager: #yum install mha4mysql-node-0.56-0.el6.norch.rpm
4 、初始化MHA ，進行配置
Manager 節點需要為每個監控的master/slave 集群提供一個專用的配置文件，而所有的master/slave 集群也可共享全局配置。全局配置文件默認為/etc/masterha_default.cnf ，其為可選配置。如果僅監控一組master/slave 集群，也可直接通過application 的配置來提供各服務器的默認配置信息。而每個application 的配置文件路徑為自定義。
5 、 定義MHA 管理配置文件
為MHA 專門創建一個管理用戶，方便以後使用，在mysql 的主節點上，三個節點自動同步
mkdir /etc/mha_master
vim /etc/mha_master/app1.cnf
配置文件內容如下；
[server default] // 適用於server1,2,3 個server 的配置
user=mhaadmin //mha 管理用戶
password=mhapass //mha 管理密碼
manager_workdir=/etc/mha_master/app1 //mha_master 自己的工作路徑
manager_log=/etc/mha_master/manager.log // mha_master 自己的日誌文件
remote_workdir=/mydata/mha_master/app1 // 每個遠程主機的工作目錄在何處
ssh_user=root // 基於ssh 的密鑰認證
repl_user=slave// 數據庫用戶名
repl_password=magedu // 數據庫密碼
ping_interval=1 // ping 間隔時長
[server1] // 節點1
hostname=172.16.5.102 // 節點1 主機地址
ssh_port=22 // 節點1 的ssh 端口
candidate_master=1 // 將來可不可以成為master 候選節點/ 主節點
[server2]
hostname=172.16.5.173
ssh_port=22
candidate_master=1
[server3]
hostname=172.16.5.174
ssh_port=22
candidate_master=1
6 、 檢測各節點間ssh 互信通信配置是否Ok:
[root@node4 ~]# masterha_check_ssh -conf=/etc/mha_master/app1.cnf
輸出信息最後一行類似如下信息，表示其通過檢測。
[info]All SSH connection tests passed successfully.
檢查管理的MySQL 復制集群的連接配置參數是否OK ：
[root@node4 ~]#masterha_check_repl -conf=/etc/mha_master/app1.cnf
如果測試時會報錯 ，可能是從節點上沒有賬號，因為這個架構，任何一個從節點，將有可能成為主節點，所以也需要創建賬號。
因此，這裏只要在mater 節點上再次執行以下操作即可：
MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO '[email protected].%.%' IDENTIFIED BY 'magedu';
MariaDB [(none)]> FLUSH PRIVILEGES;
Manager 節點上再次運行，就顯示Ok 了。
四、啟動MHA
[root@node4 ~]#nohup masterha_manager -conf=/etc/mha_master/app1.cnf &> /etc/mha_master/manager.log &
# 啟動成功後，可用過如下命令來查看master 節點的狀態:
masterha_check_status -conf=/etc/mha_master/app1.cnf
app1 (pid:4978)is running(0:PING_OK),master:172.16.252.18
上面的信息中“app1 (pid:4978)is running(0:PING_OK)” 表示MHA 服務運行OK ，否則，則會顯示為類似“app1 is stopped(1:NOT_RUNNINg).”
如果要停止MHA ，需要使用master_stop 命令。
masterha_stop -conf=/etc/mha_master/app1.cnf
五、測試MHA 測試故障轉移
(1) 在master 節點關閉mariadb 服務, 模擬主節點數據崩潰
killall -9 mysqld mysqld_safe
rm -rf /var/lib/mysql/*
(2) 在manager 節點查看日誌：
/data/masterha/app1/manager.log 日誌文件中出現如下信息，表示manager 檢測到172.16.252.18 節點故障，而後自動執行故障轉移，將172.16.252.17 提升為主節點。註意，故障轉移完成後，manager 將會自動停止，此時使用masterha_check_status 命令檢測將會遇到錯誤提示，如下所示：
masterha_check_status –conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RINNING).
六、測試MHA 測試故障轉移
(3) 提供新的從節點以修復復制集群
原有 master 節點故障後，需要重新準備好一個新的 MySQL 節點。基於來自於master 節點的備份恢復數據後，將其配置為新的 master 的從節點即可。註意，新加入的節點如果為新 增節點，其IP地址要配置為原來 master 節點的 IP ，否則，還需要修改 app1.cnf 中相應的 ip 地址。隨後再次啟動 manager ，並再次檢測其狀態。
(4) 新節點提供後再次執行檢查操作
masterha_check_status -conf=/etc/mha_master/app1.cnf
masterha_check_repl -conf=/etc/mha_master/app1.cnf
檢查無誤，再次運行，這次要記錄日誌
masterha_manager -conf=/etc/mha_master/app1.cnf >/etc/mha_master/manager.log 2>&1
七、 新節點上線，故障轉換恢復註意事項
(1) 、在生產環境中，當你的主節點掛了後，一定要在從節點上做一個備份，拿著備份文件把主節點手動提升為從節點，並指明從哪一個日誌文件的位置開始復制。
(2) 、每一次自動完成轉換後，每一次的(replication health ) 檢測不ok 始終都是啟動不了必須手動修復主節點，除非你改配置文件
(3) 、手動修復主節點提升為從節點後，再次運行檢測命令
masterha_check_repl --conf=/etc/mha_master/app1.cnf
app1 (pid:3211) is running(0:PING_OK), master:172.16.5.103
(4) 、再次運行起來就恢復成功了
masterha_manager --conf=/etc/mha_master/app1.cnf
MYSQL實現高可用MHA