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管理節點上生成的私鑰文件分別復制到其它三個節點上，確?？蔁o需驗證登錄
 可以在生成后的節點上自己做個測試執行；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就意味著前臺運行，如果終端關了。意味著服務就自動停了?。。?br />第一次啟動可以用配置文件啟動
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?。。?/span>