當主服務器掛掉的時候，考慮將從服務器提升為主服務器，一般是將數據落後最少的從服務器提升為主服務器，但是，這裏有個問題是，如果被提升的從服務器上可能有些沒完成的事務在其他從服務器上已經完成，因此，被提升的從服務器還是存在數據不同步的情況，要解決的方法是借助外在的輔助機制，監控所有從服務器的事務完成情況，並將所有進度做並集，將每一個節點完成的事務並集補全在其中一臺數據最接近於主服務的從服務器上，因此補上並集的從服務器數據是最完整的。此時，主服務器異常時，就將該從服務器提升為主服務器。

外部的輔助工具，最常用的是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 [email protected].$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 節點轉換；

數據庫 之 MHA 簡要配置文檔