Mysql之運用MHA的功能實現服務高可用

MHA介紹 (Master High Availability)

MHA（Master HA）是一款開源的 MySQL 的高可用程序，它爲 MySQL 主從複製架構提供 了 automating master failover 功能。MHA 在監控到 master 節點故障時，會提升其中擁有最新數據的 slave 節點成爲新的 master 節點，在此期間，MHA 會通過於其它從節點獲取額外信息來避免一致性方面的問題。MHA 還提供了 master 節點的在線切換功能，即按需切換 master/slave 節點。

MHA是由日本人yoshinorim（原就職於DeNA現就職於FaceBook）開發的比較成熟的MySQL高可用方案。MHA能夠在30秒內實現故障切換，並能在故障切換中，最大可能的保證數據一致性。目前淘寶也正在開發相似產品TMHA，目前已支持一主一從。

MHA服務架構角色定義

MHA 服務有兩種角色，MHA Manager(管理節點)和 MHA Node(數據節點)： 
MHA Manager： 
通常單獨部署在一臺獨立機器上管理多個 master/slave 集羣(組)，每個 
master/slave 集羣稱作一個 application，用來管理統籌整個集羣。 
MHA node： 
運行在每臺 MySQL 服務器上(master/slave/manager)，它通過監控具備解析和清理 logs 功能的腳本來加快故障轉移。 
主要是接收管理節點所發出指令的代理，代理需要運行在每一個mysql節點上。 
簡單講：node就是用來收集從節點服務器上所生成的bin-log。對比打算提升爲新的主節點之上的從節點的是否擁有並完成操作，如果沒有發給新主節點在本地應用後提升爲主節點。

如何實現寫均衡；ID分或者根據用戶名（把用戶名hash的結果去對服務器取模）

Architecture of MHA

MySQL 複製集羣中的 master 故障時，MHA 將按如下步驟進行故障轉移。

1、Slave等待我們的sql線程把本地所複製過來的所有事件，都在本地完成重放 
2、mha_node需要在slave(i)上把latest slave所沒有的灰色部分bin-log讀取出來傳給latest slave，由latest slave在本地補上灰色部分，然後它就成爲了主節點，且這個過程是自動進行的，背後實現過程是通過各種程序組件來完成。

故障轉移原理 
當master出現故障時，通過對比slave之間I/O線程讀取master binlog的位置，選取最接近的slave做爲latestslave。 其它slave通過與latest slave對比生成差異中繼日誌。在latest slave上應用從master保存的binlog，同時將latest slave提升爲master。最後在其它slave上應用相應的差異中繼日誌並開始從新的master複製信息。

在MHA實現Master故障切換過程中，MHA Node會試圖訪問故障的master（通過SSH），如果可以訪問（不是硬件故障，比如InnoDB數據文件損壞等），會保存二進制文件，以最大程度保 證數據不丟失。MHA和半同步複製一起使用會大大降低數據丟失的危險。

MHA 組件詳情

MHA 會提供諸多工具程序，其常見的如下所示。

Manager 節點:

• masterha_check_ssh：MHA 依賴的 SSH 環境檢測工具，各節點要互信；

• masterha_check_repl：檢查MYSQL複製環境是否正常；

• masterha_manager：MHA 服務器主程序；

• masterha_check_status：檢查MHA 集羣工作是否正常；

• masterha_master_monitor：檢查監控MySQL master 主節點是否正常；

• masterha_master_switch：完成master 節點和slave節點切換的工具；

• masterha_conf_host：添加或刪除配置的節點工具；

• masterha_stop：關閉 （停）MHA 服務的工具；

Node 節點:

• save_binary_logs：保存和複製 mysql的master 二進制日誌：

• apply_diff_relay_logs：識別差異的中繼日誌事件並應用於其它 slave：

• filter_mysqlbinlog：去除不必要的 ROLLBACK 事件(MHA 已不再使用這個工具)：

• purge_relay_logs：清除中繼日誌(不會阻塞 SQL 線程)：

自定義擴展(輔助類工具)：

• 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環境

依據虛擬機搭建四臺主機

Master主節點；node2，地址：172.16.5.102 
Slave從節點A；node3，地址：172.16.5.103 
Slave從節點B；node4，地址：172.16.5.104 
MHA管理節點；node5，地址：172.16.5.105

MySQL Replication要求

MHA 對 MySQL 複製環境有特殊要求，各節點都要開啓二進制日誌及中繼日誌，各從節點必須顯式啓用其 read-only 屬性，並關閉 relay_log_purge（自動清理日誌） 功能等 
同步各個節點上的時間； 
基於主機名進行解析請求； 
各個節點都是基於SSH互信通信； 
各個節點上都要關閉selinux與iptables

請做以下步驟

[root@node5 ~]# ntpdate cn.ntp.org.cn 各個節點分別執行時間同步
[root@node5 ~]# vim /etc/hosts 修改hosts文件，對以下每主機名進行解析
[root@node5 ~]# setenforce 0 每個節點上都要做
[root@node5~]# iptables -F 每個節點上都要做
172.16.5.102 node2.glances.org node2
172.16.5.103 node3.glances.org node3
172.16.5.104 node4.glances.org node4
172.16.5.105 node5.glances.org node5
基於SSH的互信通信
在MHA管理節點上做如下操作
 [root@node5 ~]# ssh-keygen 
 [root@node5 ~]# scp -p /root/.ssh/id_rsa.pub /root/.ssh/id_rsa root@node2:/root/.ssh
 把以上在MHA管理節點上生成的私鑰文件分別複製到其它三個節點上，確保可無需驗證登錄
 可以在生成後的節點上自己做個測試執行；ssh 172.16.5.105 'date'（第一次需要密碼，以後都不需要）
 vim /etc/ssh/ssh_config 
 註釋去掉；把StrictHostKeyChecking ask 修改爲no，保存退出 （跳過rsa的key驗證yes or no）

主節點配置

主機名，node2；地址，172.16.5.102
安裝mariadb數據庫
yum install mariadb-server
修改配置文件,加入以下內容
vim /etc/my.cnf
    innodb_file_per_table=1 //每張表都獨立一個idb文件
    skip_name_resolve=1 //跳過反向解析
    server_id=1 服務器id
    relay-log=relay-log //中繼日誌
    log-bin=master-log //二進制日誌
保存退出
把配置文件拷貝到另一臺從節點，把server_id改成2
scp /etc/my.cnf root@node3:/etc/my.cnf

從節點配置

主機名，node3；地址，172.16.5.103
其它兩臺從節點配置文件相同，只要server的ID不一樣就行
安裝mariadb數據庫
yum install mariadb-server
修改配置文件,加入以下內容
vim /etc/my.cnf
    innodb_file_per_table=1
    skip_name_resolve=1
    server_id=2
    relay-log=relay-log
    log-bin=master-log
    relay-only=1
    relay-log-purge=0
保存退出
把配置文件拷貝到另一臺從節點，把server_id改成3
scp /etc/my.cnf root@node5:/etc/my.cnf

各節點授權和認證操作


主節點1操作； 
[root@node2 ~]# mysql //登錄到mysql，執行下面步驟 
msyql>grant replication slave, replication client on * . * to 'repuser'@'172.16.5.%' identified by 'repuser' 
授權主從節點允許登錄的IP地址和用戶 
mysql>show master status; 
查看節點狀態，把master-log日誌從哪個位置產生的，記錄下來 
mysql>show binlog events in 'master-log.000003'; 
查看下二進制日誌事件有沒有成功記錄，在以上做的授權被事件日誌準確記錄後，我們就不需要一個一個去登錄mariadb從節點做認證授權，等我們啓動從節點後會自動同步過去。 
從節點2操作； 
[root@node2 ~]# mysql //登錄到mysql，執行下面步驟 
mysql>change master to master_host='172.16.5.102',master_user='repuser',master_password='repuser',master_log_file='master-log.000003',master_log_pos=594; 
如果從節點在運行中執行 start top； 
msyql>start slave; 
mysql>show slave status\G 
mysql>select host user from mysql.user; 
節點2上面的操作一樣在節點3上執行一遍，這樣主從複製就成功搭建起來了。 
在主節點上執行創建數據庫，修改數據庫，看數據會不會自動同步到兩個從節點上。 


在各節點上安裝MHA

除 了 源 碼 包 ， MHA 官 方 也 提 供 了 rpm 格 式 的 程 序 包 ， 其 下 載 地 址 爲 https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。 
CentOS 7 適用於el6 程序包。另外MHA Manage 和 MHA Node 程序包的版本並不強制要求一致。 
安裝： 
管理節點：node5，地址：172.16.5.105 
在管理節點安裝MHA管理組件，先安裝node再安裝manager軟件本身有依賴關係 
yum install ./mha4mysql-node-0.56-0.el6.noarch.rpm 
yum install ./mha4mysql-manager-0.56-0.el6.noarch.rpm 
把mha4mysql-node-0.56-0.el6.noarch.rpm程序包拷貝到其它三個節點上 
for i in 102 103 104; do scp mha4mysql-node-0.56-0.el6.noarch.rpm 172.16.5.$i:/root/ ;done 
三個節點都必須安裝 
node2，地址：172.16.5.102 
node3，地址：172.16.5.103 
node4，地址：172.16.5.104 
yuminstall ./mha4mysql-node-0.56-0.el6.noarch.rpm

初始化MHA

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

MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'172.16.5.%' identified by 'mhaadmin';
MariaDB [(none)]> flush privileges;
爲MHA專門創建一個管理用戶，方便以後使用，在mysql的主節點上，三個節點自動同步
mkdir /etc/mha_master
vim /etc/mha_master/app1.cnf
配置文件內容如下；
[server default] //適用於server1,2,3個server的配置
user=mhaadmin //mha管理用戶
password=mhaadmin //mha管理密碼
manager_workdir=/mydata/mha_master/app1 //mha_master自己的工作路徑
manager_log=/mydata/mha_master/manager.log // mha_master自己的日誌文件
remote_workdir=/mydata/mha_master/app1 //每個遠程主機的工作目錄在何處
ssh_user=root // 基於ssh的密鑰認證
repl_user=repuser //數據庫用戶名
repl_password=repuser //數據庫密碼
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.103
ssh_port=22
candidate_master=1

[server2]
hostname=172.16.5.104
ssh_port=22
candidate_master=1

檢測各節點間 ssh 互信通信配置是否 OK

[root@node5 .ssh]# masterha_check_ssh –conf=/etc/mha_master/app1.cnf 
輸出信息最後一行類似如下信息，表示其通過檢測。 [info] 
All SSH connection tests passed successfully.

檢查管理的 MySQL 複製集羣的連接配置參數是否 OK

目的是我們的數據庫定義的用戶repuser和密碼能否執行復制權限 
[root@node5 ~]# masterha_check_repl –conf=/etc/masterha/app1.cnf 
輸出信息如下所示，最後一行的“Health is OK”信息表示通過檢測。 
Mon Nov 9 17:22:48 2015 – [info] Slaves settings check done. 
…… 
MySQL Replication Health is OK. 
注意： 
在檢查完成後末尾會有兩條警號信息 
[warning] master_ip_failover_script is not defined. 
這個是用來定義master_ip地址的故障轉移，誰成爲主節點後自動把地址轉移過去，讓它成爲主節點，誰成爲主節點，誰配置vip（用來配置vip的）需要自己寫腳本 
[warning] shutdown_script is not defined. 
這個showdown腳本在安裝時已經有了 
rpm -qa mha4mysql-manager ，這個包裏有。不用寫 
以上兩個提供不提供無所謂，只是測試，我們用其它方式啓動

啓動 MHA

啓動方式用；nohup 後臺運行 
如果不用nohup就意味着前臺運行，如果終端關了。意味着服務就自動停了！！！ 
第一次啓動可以用配置文件啓動 
masterha_manager –conf=/etc/mha_master/app1.cnf >/mydata/mha_master/app1/manager.log 2>&1 
直接後臺運行，不用輸出重定向到某個目錄了 
masterha_manager –conf=/etc/mha_master/app1.cnf 
前臺運行，更直觀 
ok！！！ 
這個時候可以在數據庫裏做一些操作了，創建數據庫，創建表，刪除字段，刪除表，測試目的 
mysql>create database tbl05; 
mysql>drop database tbl04; 
mysql>use tbl05; 
mysql>create tables

啓動成功後，可通過如下命令來查看 master 節點的狀態

masterha_check_status --conf=/etc/mha_master/app1.cnf

[root@node5 mydata]# masterha_check_status –conf=/etc/mha_master/app1.cnf 
app1 (pid:3211) is running(0:PING_OK), master:172.16.5.102 
[root@node5 mydata]# 
正常運行中……

如果要停止 MHA，需要使用 masterha_stop 命令

masterha_stop --conf=/etc/mha_master/app1.cnf

[root@node5 mydata]# masterha_stop –conf=/etc/mha_master/app1.cnf

測試故障轉移

(1) 在 master 節點關閉 mariadb 服務 
killall mysqld mysqld_safe 
systemctl stop mariadb.service 
(2) 在 manager 節點查看日誌 
如果我們沒有記錄日誌是沒有的 
注意，故障轉移完成後，manager 將會自動停止，此時使用 masterha_check_status 
命令檢測將會遇到錯誤提示，如下所示。 
[root@node5 ~]# masterha_check_status --conf=/etc/mha-master/app1.cnf 
app1 is stopped(2:NOT_RUNNING) 
(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 >/mydata/mha_master/app1/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

手動完成在線主從節點切換

注意：所有都正常，只是想改一下主節點是誰而已 
masterha_master_switch --master state=alive --conf=/etc/mha_master/app1.cnf 
會提示你在數據庫主節點上執行某條語句 
flush no_write_to_binlog tables; //沒有寫操作的節點，執行flush 
確認，輸入yes 
手動檢測在各個節點上，把停止的節點手動修復，啓用爲slave模式

更進一步的提升工作效率

前面三個步驟已經配置了一個基本的MHA 環境。不過爲了更多實際應用需求，還需進一步完成如下操作。

(1)、提供額外檢測機制，指明對 master 的監控做出誤判； 
(2)、在 master 節點上提供虛擬 ip 地址向外提供服務，指明 master 節點轉換時，客戶端的請求無法正確送達； 
(3)、進行故障轉移時對原有 master 節點執行 STONITH 操作以避免腦裂； 可通過指定shutdown_script 實現； 
(4)、必要時可進行在線 master 節點轉換；

    done！！！