數據庫 之 MHA 簡要配置文檔

1  概述

當主服務器掛掉的時候，考慮將從服務器提高爲主服務器，通常是將數據落後最少的從服務器提高爲主服務器，可是，這裏有個問題是，若是被提高的從服務器上可能有些沒完成的事務在其餘從服務器上已經完成，所以，被提高的從服務器仍是存在數據不一樣步的狀況，要解決的方法是藉助外在的輔助機制，監控全部從服務器的事務完成狀況，並將全部進度作並集，將每個節點完成的事務並集補全在其中一臺數據最接近於主服務的從服務器上，所以補上並集的從服務器數據是最完整的。此時，主服務器異常時，就將該從服務器提高爲主服務器。

外部的輔助工具，最經常使用的是MHA，主節點高可用的縮寫，是一外部輔助工具，不只監控備用解決的事務狀況，並且輔助將從服務器提高成爲新的主服務器，並且不形成數據的不一樣步。

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

master/slave 節點。

MHA 服務有兩種角色，MHA Manager(管理節點)和 MHA Node(數據節點)

MHA Manager：一般單獨部署在一臺獨立機器上管理多個 master/slave 集羣（能夠直接配置在調度器上），每一個master/slave 集羣稱做一個 application；

MHA node：運行在每臺 MySQL 服務器上(master/slave/manager)，它經過監控具有解析和清理 logs 功能的腳原本加快故障轉移。

架構圖以下：

2 Architecture of MHA

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

特殊狀況下，若是全部的從節點都缺失某一事務，那麼就將該事務回退。

 

3  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 節點切換工具；

- masterha_conf_host：添加或刪除配置的節點；

- masterha_stop：關閉 MHA 服務的工具；

Node 節點:

- save_binary_logs：保存和複製 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 地址；

4  準備 MySQL Replication 環境

MHA 對 MySQL 複製環境有特殊要求，例如各節點都要開啓二進制日誌及中繼日誌，各從節點必須顯式啓用其 read-only 屬性，並關閉 relay_log_purge 功能等，這裏先對其配置作事先說明。

本實驗環境共有四個節點，其角色分配以下所示。

node75: MHA Manager

node71: MariaDB master

node76: MariaDB slave

node77: MariaDB slave

若是本地dns能夠解析各節點，或者在各節點的/etc/hosts 文件配置內容中添加：

192.168.1.75 node75.ghbsunny.cn node75

192.168.1.71 node71.ghbsunny.cn node71

192.168.1.76 node76.ghbsunny.cn node76

192.168.1.77 node77.ghbsunny.cn node77

初始主節點 master 配置：

[root@node71 ~]#vim /etc/my.cnf.d/server.cnf 

[server]

skip_name_resolve = ON

innodb_file_per_table = ON

max_connections = 20000

log_bin = master-log

relay-log=relay-bin #由於主節點可能會成爲從節點，因此要啓用中繼日誌

server_id = 1 

全部 slave 節點（76和77）依賴的配置：

[root@node76 ~]#vim /etc/my.cnf.d/server.cnf 

[server]

skip_name_resolve = ON

innodb_file_per_table = ON

max_connections = 20000

server_id=2 # 複製集羣中的各節點的 id 均必須唯一，另外一個節點爲3；

relay-log=relay-bin 

log-bin=master-bin 

relay_log_purge=0 #關閉中繼日誌自動修剪功能，由於中繼日誌默認會自動修剪 

read_only=1 #從節點要設置爲只讀，防止出現數據和主節點不一致

重啓三臺mysql服務器

在主節點上查看當前二進制文件是哪一個，以及位置在哪裏，待會複製須要從哪一個二進制文件的哪一個位置進行復制

在71上執行以下命令

MariaDB [(none)]> show master status\G;

在服務器主節點71上受權兩個帳號用來受權mha管理和從節點複製的權限

按上述要求分別配置好主從節點以後，按 MySQL 複製配置架構的配置方式將其配置完成， 並啓動 master 節點和各 slave 節點，以及爲各 slave 節點啓動其 IO 和 SQL 線程，確保主從複製運行無誤。

然後，在全部MySQL 節點受權擁有管理權限的用戶可在本地網絡中有其它節點上遠程訪問。固然，此時僅須要且只能在 master 節點運行相似以下 SQL 語句便可。如受權mhadmin帳號，使得該帳號能夠對mysql服務器具備管理權限

MariaDB [(none)]> GRANT ALL ON *.* TO 'mhaadmin'@'192.168.1.%' IDENTIFIED BY 'Pass123456';

MariaDB [(none)]> flush privileges;

另外，受權帳號sunnycopy具備複製的權限便可，使得從服務器能夠往主服務器複製二進制文件到中繼文件中

MariaDB [(none)]> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'sunnycp'@'192.168.1.%' IDENTIFIED BY 'Pass123456';

MariaDB [(none)]> flush privileges;

受權完成後，在兩個從節點76和77上上啓用複製進程

MariaDB [(none)]> change master to master_host='192.168.1.71',master_user='sunnycp',master_password='Pass1234',master_log_file='master-log.000010',master_log_pos=466;

MariaDB [(none)]> start slave;

查看複製是否完成

MariaDB [(none)]> show slave status\G;

查看受權的兩個帳號是否已經複製過來

MariaDB [(none)]> select host,user from mysql.user;

4  安裝配置 MHA

4.1 準備基於 ssh 互信通訊環境

MHA 集羣中的各節點彼此之間均須要基於 ssh 互信通訊，以實現遠程控制及數據管理功能。簡單起見，可在 Manager 節點生成密鑰對兒，並設置其可遠程鏈接本地主機後，將私鑰文件及 authorized_keys 文件複製給餘下的全部節點便可。

下面的操做在 manager 節點操做便可。

~]# ssh-keygen -t rsa -P ''

~]# cat .ssh/id_rsa.pub >> .ssh/authorized_keys

~]# chmod go= .ssh/authorized_keys

~]# scp -p .ssh/id_rsa .ssh/authorized_keys   root@node71:/root/.ssh/

~]# scp -p .ssh/id_rsa .ssh/authorized_keys   root@node76:/root/.ssh/

~]# scp -p .ssh/id_rsa .ssh/authorized_keys   root@node77:/root/.ssh/

以上步驟能夠直接用for循環實現，假設有七臺機器

在192.168.1.71上執行

[root@CentOS7A .ssh]#ssh-keygen -t rsa -P ''

生成密鑰對，將密鑰對發送給其餘機器

[root@CentOS7A .ssh]#cat .ssh/id_rsa.pub >> .ssh/authorized_keys

[root@CentOS7A .ssh]#chmod go= .ssh/authorized_keys

[root@CentOS7A .ssh]#for i in 71 72 73 75 76 77 78;do scp -p /root/.ssh/id_rsa /root/.ssh/authorized_keys root@192.168.1.$i:/root/.ssh/ ;done

注意：請事先確保 全部機器上的/root/.ssh 目錄存在，且在/root/.ssh 目錄下不能有id_rsa.pub，不然有id_rsa.pub的主機鏈接其餘機器仍是須要輸入密碼。或者，能夠直接把71上的id_rsa.pub也都拷貝到其餘機器上就不存在這個問題了。

4.2 安裝 MHA

除 了 源 碼 包 ， MHA 官 方 也 提 供 了 rpm 格 式 的 程 序 包 ， 其 下 載 地 址 爲https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。CentOS 7 系統可直接使用適用於 el6 的程序包。另外，MHA Manage 和 MHA Node 程序包的版本並不強制要求一致。

這裏採用提早下載好的服務包

Manager 節點：注意，若是 mha4mysql-manager安裝不成功，建議先安裝mha4mysql-node後安裝mha4mysql-manager，由於存在依賴關係。另外，server端也沒有啓動腳本，須要手動啓動

~]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm

全部節點，包括 Manager：

~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm

4.3 初始化 MHA

Manger 節點須要爲每一個監控的 master/slave 集羣提供一個專用的配置文件， 而全部的

master/slave 集羣也可共享全局配置。全局配置文件默認爲/etc/masterha_default.cnf，其爲可選配置。若是僅監控一組 master/slave 集羣，也可直接經過 application 的配置來提供各服務器的默認配置信息。而每一個 application 的配置文件路徑爲自定義，例如，本示例中將使用

/etc/masterha/app1.cnf，其內容以下所示。

在75節點上

首先建立相關目錄首先建立相關目錄

[root@node75 mha]#mkdir  /etc/masterha

[root@node75 mha]#vim /etc/masterha/app1.cnf

[server default]

user=mhaadmin # MySQL 管理員，用來管理各個節點

password=Pass123456 # MySQL 管理員mhaadmin的密碼

manager_workdir=/data/masterha/app1  #這個目錄/data/masterha/app1不須要建立，不存在時會自動建立

manager_log=/data/masterha/app1/manager.log 

remote_workdir=/data/masterha/app1 #指各個node節點的工做目錄

ssh_user=root #基於密鑰鏈接，因此不須要配置密碼

ssh_port=22  #這個選項是全局，若是不定義，就是使用默認的端口22，能夠在每一個節點上分別再定義端口，基於安全考慮，能夠把22端口改爲其餘的

repl_user=sunnycp 

repl_password=Pass123456

ping_interval=1 #多長時間檢測一次

[server1] 

hostname=192.168.1.71 

#ssh_port=22022 #這個選項若是不定義，就是默認的22端口

candidate_master=1 #未來是否能夠成爲主節點，若是不定義，就不能成爲候選的主節點

[server2] 

hostname=192.168.1.76 

#ssh_port=22022 

candidate_master=1 

[server3] 

hostname=192.168.1.77 

#ssh_port=22022 

#no_master=1 #若是定義no_master就不能成爲主節點

檢測各節點間 ssh 互信通訊配置是否 OK：--conf指定配置文件路徑

~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf 

輸出信息最後一行相似以下信息，表示其經過檢測。

[info] All SSH connection tests passed successfully.

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

~]# masterha_check_repl --conf=/etc/masterha/app1.cnf

輸出信息以下所示，最後一行的「Health is OK」信息表示經過檢測。

Mon Nov 9 17:22:48 2015 - [info] Slaves settings check done.

Mon Nov 9 17:22:48 2015 - [info]

192.168.1.71(192.168.1.71:3306) (current master)

+--192.168.1.76(192.168.1.76:3306)

+--192.168.1.77(192.168.1.77:3306)

 

…… ……

MySQL Replication Health is OK.

啓動 MHA，後臺運行，注意，masterha_manager沒有啓動的程序，須要手動啓動服務

~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/manager.log 2>&1 &

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

~]# masterha_check_status --conf=/etc/masterha/app1.cnf

app1 (pid:4978) is running(0:PING_OK), master:192.168.1.71

上面的信息中「app1 (pid:4978) is running(0:PING_OK)」表示 MHA 服務運行 OK，不然，則會顯示爲相似「app1 is stopped(1:NOT_RUNNING).」。

若是要中止 MHA，須要使用 masterha_stop 命令。

~]# masterha_stop --conf=/etc/masterha/app1.cnf Stopped app1 successfully.

4.4 測試故障轉移

(1) 在 master 節點71關閉 mariadb 服務

~]# killall -9 mysqld mysqld_safe

或者，直接關閉服務

[root@node71 mha]#systemctl stop mariadb;

(2) 在 manager 節點查看日誌

/data/masterha/app1/manager.log 日 志 文 件 中 出 現 的 如 下 信 息 ， 表 示 manager 檢 測 到

192.168.1.71 節點故障，然後自動執行故障轉移，將 192.168.1.76 提高爲了主節點。

Master 192.168.1.71(192.168.1.71:3306) is down!

Check MHA Manager logs at node75.ghbsunny.cn:/data/masterha/app1/manager.log for details. Started automated(non-interactive) failover.

The latest slave 192.168.1.76(192.168.1.76:3306) has all relay logs for recovery. Selected 192.168.1.76(192.168.1.76:3306) as a new master.

192.168.1.76(192.168.1.76:3306): OK: Applying all logs succeeded. 192.168.1.77(192.168.1.77:3306): This host has the latest relay log events. Generating relay diff files from the latest slave succeeded.

192.168.1.77(192.168.1.77:3306): OK: Applying all logs succeeded. Slave started, replicating from 192.168.1.76(192.168.1.76:3306)

192.168.1.76(192.168.1.76:3306): Resetting slave info succeeded.

Master failover to 192.168.1.76(192.168.1.76:3306) completed successfully.

此時在76上，鏈接mysql後測試以下

MariaDB [(none)]> show master status;

+-------------------+----------+--------------+------------------+

| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+-------------------+----------+--------------+------------------+

| master-log.000004 |      245 |              |                  |

+-------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

可是，slave status沒有數據了

MariaDB [(none)]> show slave status;

說明，76已經成爲主服務器

注意，故障轉移完成後，manager 將會自動中止，由於集羣已經不知足條件，因此會中止，須要從新進行設置。此時使用 masterha_check_status 命令檢測將會遇到錯誤提示，以下所示。

]# masterha_check_status --conf=/etc/masterha/app1.cnf 

app1 is stopped(2:NOT_RUNNING).

(3) 提供新的從節點以修復複製集羣

原有 master 節點故障後，須要從新準備好一個新的 MySQL 節點。基於來自於 master 節點的備份恢復數據後，將其配置爲新的 master 的從節點便可。注意，新加入的節點若是爲新增節點，其 IP 地址要配置爲原來 master 節點的 IP，不然，還須要修改 app1.cnf 中相應的 ip 地址。隨後再次啓動 manager，並再次檢測其狀態。

這裏演示將71從新進行修復，將71進行修復後，要修改71的配置文件，由於71已經成爲從服務器，須要添加以下的配置後才能重啓mysql服務，從新上線

[root@node71 mha]#vim /etc/my.cnf.d/server.cnf 

relay_log_purge = 0 

read_only = 1

[root@node71 mha]#systemctl start mariadb;

重啓服務後，當前主節點76不須要作修改，從新上線71後，要在71上指定76爲主服務器

鏈接如mysql

MariaDB [(none)]> change master to master_host='192.168.1.76',master_user='sunnycp',master_password='Pass1234',master_log_file='master-log.000004',master_log_pos=245;

MariaDB [(none)]> start slave;

注意，這裏若是71已經故障一段時間，76成爲主服務器後已經運行一段時間，則數據會不同，須要在76備份全量數據還原到71上，而後在重啓71的複製線程

71數據恢復完成，且啓動複製線程後

在75上檢查狀態

[root@node75 mha]#masterha_check_repl --conf=/etc/masterha/app1.cnf

正常後，從新啓動manager服務

~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/manager.log 2>&1 &

檢查運行狀態

[root@node75 mha]#masterha_check_status --conf=/etc/masterha/app1.cnf

app1 (pid:60043) is running(0:PING_OK), master:192.168.1.76

到這裏修復和從新上線mysql節點完成

5  進一步工做

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

(1) 提供額外檢測機制，以名對 master 的監控作出誤判；

(2) 在 master 節點上提供虛擬 ip 地址向外提供服務，以名 master 節點轉換時，客戶端的請求沒法正確送達；

(3) 進行故障轉移時對原有 master 節點執行 STONITH 操做以免腦裂； 可經過指定shutdon_script 實現；

(4)必要時，進行在線 master 節點轉換；