基於MHA的MySQL高可用

一、MHA工作原理以及實驗準備
1、MHA工作原理總結爲以下幾條：
（1）從宕機崩潰的master保存二進制日誌事件（binlog events）;
（2）識別含有最新更新的slave;
（3）應用差異的中繼日誌(relay log) 到其他slave;
（4）應用從master保存的二進制日誌事件(binlog events);
（5）提升一個slave爲新master;
（6）使用其他的slave連接新的master進行復制。
2、本實驗環境共需要四個節點，其角色分配如下：
node1：MariaDB master
node2：MariaDB slave
node3：MariaDB slave
node4：MHA manager
二、實現MySQL的主從
配置MySQL主服務器
1，配置master主服務器 （配置文件）
server-id=1 //配置server-id ，讓主服務器又唯一ID號
log-bin=zuozuo-bin //打開二進制日誌
relay-log =zuozuo-relay-log // 打開中繼日誌
log_slave_updates = 1
skip_name_resolve //關閉域名解析
2創建複製賬號
在登錄MySQL的前提下，在master的數據庫下創建一個備份賬戶，每個slave使用標準的MySQL用戶名和密碼連接master，進行復制操作的slave會授予replication slave權限
grant replication slave，replicationclient client on . to slave @'172.17.%.%' identified by '123456';
3、配置所有slave節點

server-id =2  /配置server-id  不可以與master重複
relay-log =zuozuo-relay-log   //開啓中繼日誌
log-bin = zuozuo-bin 
log_slave_updates = 1 //使得更新的日誌寫進二進制日誌中
read_only=ON   //設置制度權限，保證數據庫數據的一致性
relay_log_purge=0
skip_name_resolve //忽略域名解析

4、啓動從服務器父子線程
讓slave連接master，病開始重做master二進制日誌中的事件

change master to master_host='172.17.252.157',       //master的IP地址
maste_user='slave';
master_password='123456',
master_log_file='zuozuo-bin.000002', //主服務器的二進制日誌文件名
master_log_pos=278;  //讀取二進制文件的起點
執行start slave ；// 啓動複製線程

三、準備通信環境
MHA集羣中的各個節點之間均需要局域SSH互相通信，以實現遠程控制和數據管理功能，簡單起見，可在manager節點生成密鑰對，實現各節點尖實現基於key的免密碼登錄。

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa  
ssh-copy-id -i .ssh/id_rsa.pub  @各個MySQL數據庫ID

四 、安裝配置MHA
1、安裝MHA
Manager 節點： #yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
所有節點，包括Manager: #yum install mha4mysql-node-0.56-0.el6.norch.rpm
注：對於manager節點 要先安裝mha4mysql-node包然後安裝管理包，避免一些依賴包沒有安裝影響管理包的安裝。
在所有MySQL節點授權擁有管理權限的用戶可在本地網絡紫紅有其他節點上遠程訪問，當然，此時僅需要且只能在master節點上創建並且授權用戶；

mysql> GRANT ALL ON *.* TO 'mhaadmin'@'172.17.%.%' IDENTIFIED BY
'mhapass';

2、初始化MHA，進行配置
manager節點需要爲每個監控的master/slave集羣提供一個專用的配置文件，而所有的master/slave集羣也可共享全局配置。全局配置文件默認爲/etc/masterha_default.cnf ，其爲可選配置。如果僅監控一組master/slave集羣，也可直接通過application的配置來提供各服務器的默認配置信息。而每個application的配置文件路徑爲自定義。
3、定義MHA管理配置文件

mkdir /etc/mha_master
vim /etc/mha_master/app.cnf
[server default]
user=mhaadmin
password=123456
manager_workdir=/etc/mha_master/app1
manager_log=/etc/mha_master/manager.log
remote_workdir=/mydata/mha_master/app1
ssh_user=root
repl_user=slave
repl_user=slave
ping_interval=1
[server1]
hostname=172.17.253.21
ssh_port=22
candidate_master=1
[server2]
hostname=172.17.253.157
ssh_port=22
candidate_master=1
[server3]
hostname=172.17.253.59
ssh_port=22
candidate_master=1

4、檢測各節點間ssh互相通信配置是否OK
[root@node4 ~]# masterha_check_ssh -conf=/etc/mha_master/app1.cnf
輸出信息最後一行類似如下信息，表示其通過檢測。
[info]All SSH connection tests passed successfully.
[root@node4 ~]#masterha_check_repl -conf=/etc/mha_master/app1.cnf
如果測試時會報錯，可能是節點上沒有賬號，因爲這個架構，任何一個從節點，將有可能成爲主節點，所以也需要創建賬號
五、啓動MHA

[root@node4 ~]#nohup masterha_manager -conf=/etc/mha_master/app1.cnf
&> /etc/mha_master/manager.log &   //啓動之後後臺運行，負責將會佔住擋牆終端，不能進行之後的操作。

啓動成功之後，查看master節點的狀態
[root@node4 ~]#masterha_check_status -conf=/etc/mha_master/app1.cnf

如果要停止MHA，需要使用master_stop命令。
[root@node4 ~]#masterha_stop -conf=/etc/mha_master/app1.cnf

六、測試MHA故障轉移
(1)在master節點關閉mariadb服務,模擬主節點數據崩潰
systemctl stop mariadb
(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).

(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)、手動修復主節點提升爲從節點後，再次運行檢測命令

[root@node5 ~]# 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