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 將按以下步驟進行故障轉移。

一、Slave等待咱們的sql線程把本地所複製過來的全部事件，都在本地完成重放 
二、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
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！！！