MySQL高可用架構之MHA

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 Manager(管理節點)和 MHA Node(數據節點)：

MHA Manager：

通常單獨部署在一臺獨立機器上管理多個 master/slave 集羣(組)，每個master/slave 集羣稱作一個 application，用來管理統籌整個集羣。

MHA node：

運行在每臺 MySQL 服務器上(master/slave/manager)，它通過監控具備解析和清理 logs 功能的腳本來加快故障轉移。主要是接收管理節點所發出指令的代理，代理需要運行在每一個mysql節點上。

簡單講node就是用來收集從節點服務器上所生成的bin-log。對比打算提升爲新的主節點之上的從節點的是否擁有並完成操作，如果沒有發給新主節點在本地應用後提升爲主節點。

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

Manager節點：

masterha_check_ssh :MHA依賴的ssh環境監測工具

masterha_check_repl: MYSQL複製環境檢測工具；

masterga_manager: MHA 服務主程序

masterha_check_status: MHA 運行狀態探測工具；

masterha_master_monitor:MYSQL master節點可用性監測工具；

masterha_master_swith:master節點切換工具；

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

masterha_stop:關閉MHA服務的工具。

Node節點：

save_binary_logs:保存和複製master的二進制日誌；

apply_diff_relay_logs:識別差異的中繼日誌事件並應用於其他slave；

purge_relay_logs:清除中繼日誌（不會阻塞SQL線程）；自定義擴展

secondary_check_script:通過多條網絡路由檢測master的可用性；

master_ip_failover_script:更新application使用的masterip；

report_script:發送報告

init_conf_load_script:加載初始配置參數；

master_ip_online_change_script:更新master節點ip地址；

MHA工作原理總結爲以下幾條：

（1）從宕機崩潰的master保存二進制日誌事件（binlog events）;

（2）識別含有最新更新的slave;

（3）應用差異的中繼日誌(relay log) 到其他slave;

（4）應用從master保存的二進制日誌事件(binlog events);

（5）提升一個slave爲新master;

（6）使用其他的slave連接新的master進行復制。

具體實戰

一、準備實驗MYSQL Replication環境：

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

本實驗環境共有四個節點，其角色分配如下：

node1:MariaDB master
node2: MariaDB slave
node3: MariaDB slave
node4: MHA Manager

各節點的/etc/hosts文件配置內容中添加(每個節點都需要添加，以實現後期四個節點之間的ssh無密登錄)：

172.17.253.208 node1.magedu.com node1
172.17.254.204 node2.magedu.com node2
172.17.254.205 node3.magedu.com node3
172.17.254.188 node4.magedu.com node4

1、初始主節點master配置：

[mysqld]
server-id = 1
log-bin = master-log
relay-log = relay-log
skip_name_resolve = ON

2、所有slave節點依賴的配置（所有slave除了ID不同，其他配置都相同）：

依賴的配置：
[mysqld]
server-id = 2 #複製集羣中的各節點的id均必須唯一；
relay-log = relay-log
log-bin = master-log
read_only = ON
relay_log_purge = 0 #是否自動清空不再需要中繼日誌
skip_name_resolve = ON

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

master節點上：

MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON*.* TO slave@'172.17.%.%' IDENTIFIED BY '55555';
MariaDB [(none)]> FLUSH PRIVILEGES;#刷新MySQL的系統權限相關表
MariaDB [(none)]> SHOW MASTER STATUS;

各slave節點上：

[root@node3 ~]# mysql
MariaDB [(none)]> CHANGE MASTER TO
MASTER_HOST='172.17.253.208′,MASTER_USER='slave',MASTER_PASSWORD='55555',MASTER_LOG_FILE='masterlog.000003′,MASTER_LOG_POS=498;
MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G

二、安裝配置MHA

1、在所有MYSQL節點授權擁有管理權限的用戶可在本地網絡中有其他節點上遠程訪問。當然，此時僅需要且只能在master節點運行類似如下SQL語句即可。

mysql> GRANT ALL ON *.* TO 'mhaadmin'@'172.17.%.%' IDENTIFIED BY'mhapass';(授權MHA管理節點權限)

2、準備基於SSH互信通信環境：

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

下面操作在node4：Manager 節點上操作，每個節點上都需要同樣的操作：

[root@node4 ~]# ssh-keygen -t rsa
[root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@node4
[root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@node3
[root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@node2
[root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@node1

3、進行MHA安裝包安裝

Manager 節點： #yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
所有節點，包括Manager: #yum install mha4mysql-node-0.56-0.el6.norch.rpm

4、初始化MHA，進行配置

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

5、定義MHA管理配置文件

在manager上爲MHA專門創建一個管理用戶，方便以後使用，在mysql的主節點上，三個節點自動同步

mkdir /etc/mha_master
vim /etc/mha_master/app1.cnf

配置文件內容如下；

[server default] //適用於server1,2,3個server的配置
user=mhaadmin //mha管理用戶
password=mhapass //mha管理密碼
manager_workdir=/etc/mha_master/app1 //mha_master自己的工作路徑
manager_log=/etc/mha_master/manager.log // mha_master自己的日誌文件
remote_workdir=/mydata/mha_master/app1 //每個遠程主機的工作目錄在何處，如果不存在該目錄則需手動創建目錄
ssh_user=root // 基於ssh的密鑰認證
repl_user=slave//數據庫用戶名
repl_password=55555 //數據庫密碼
ping_interval=1 // ping間隔時長
[server1] //節點1（主節點），節點是按照節點數字從小到大讀的
hostname=172.17.253.208 //節點1主機地址
ssh_port=22 //節點1的ssh端口
candidate_master=1 // 將來可不可以成爲master候選節點/主節點

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

[server3]
hostname=172.17.254.205
ssh_port=22
candidate_master=1

6、檢測各節點間ssh互信通信配置是否Ok:

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

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

[root@node4 ~]#masterha_check_repl -conf=/etc/mha_master/app1.cnf
如果測試時會報錯，可能是從節點上沒有賬號，因爲這個架構，任何一個從節點，將有可能成爲主節點，所以也需要創建賬號。
因此，這裏只要在mater節點上再次執行以下操作即可：
MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON
*.* TO slave@'172.17.%.%' IDENTIFIED BY '55555';
MariaDB [(none)]> FLUSH PRIVILEGES;
Manager節點上再次運行，就顯示Ok了。
有時也會出現如下的報錯信息
Fri Nov 24 17:30:21 2017 - [error][/usr/share/perl5/vendor_perl/MHA/Server.pm, ln393] 172.17.253.208(172.17.253.208:3306): User slave does not exist or does not have REPLICATION SLAVE privilege! Other slaves can not start replication from this host.
Fri Nov 24 17:30:21 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations.  at /usr/share/perl5/vendor_perl/MHA/ServerManager.pm line 1403.
Fri Nov 24 17:30:21 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Fri Nov 24 17:30:21 2017 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!
信息中會給出具體出錯的節點IP，此時在該節點上運行如上操作也可以解決問題。

三、啓動MHA

[root@node4 ~]#nohup masterha_manager -conf=/etc/mha_master/app1.cnf
&> /etc/mha_master/manager.log &（最後一個&符號表示在後臺運行）

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

[root@node4 ~]#masterha_check_status -conf=/etc/mha_master/app1.cnf
app1 (pid:4978)is running(0:PING_OK),master:172.16.252.18
上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服務運行OK，否則，則會顯示爲類似“app1 is stopped(1:NOT_RUNNINg).”
如果要停止MHA，需要使用masterha_stop命令。
[root@node4 ~]#masterha_stop -conf=/etc/mha_master/app1.cnf

四、測試MHA測試故障轉移

(1)在master節點關閉mariadb服務,模擬主節點數據崩潰

#killall -9 mysqld mysqld_safe
#rm -rf /var/lib/mysql/*

(2)在manager節點查看日誌：

/etc/masterha/app1/manager.log 日誌文件中出現如下信息（日誌文件的位置是在之前的application的配置中配置的路徑），表示manager檢測到172.17.253.208節點故障，而後自動執行故障轉移，將172.17.254.204提升爲主節點。注意，故障轉移完成後，manager將會自動停止，具體日誌內容如下：

----- Failover Report -----

app1: MySQL Master failover 172.17.253.208(172.17.253.208:3306) to 172.17.254.204(172.17.254.204:3306) succeeded

Master 172.17.253.208(172.17.253.208:3306) is down!

Check MHA Manager logs at localhost.localdomain:/etc/mha_master/manager.log for details.

Started automated(non-interactive) failover.
The latest slave 172.17.254.204(172.17.254.204:3306) has all relay logs for recovery.
Selected 172.17.254.204(172.17.254.204:3306) as a new master.
172.17.254.204(172.17.254.204:3306): OK: Applying all logs succeeded.
172.17.254.205(172.17.254.205:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
172.17.254.205(172.17.254.205:3306): OK: Applying all logs succeeded. Slave started, replicating from 172.17.254.204(172.17.254.204:3306)
172.17.254.204(172.17.254.204:3306): Resetting slave info succeeded.
Master failover to 172.17.254.204(172.17.254.204:3306) completed successfully.

此時使用masterha_check_status命令檢測將會遇到錯誤提示，如下所示：

#masterha_check_status –conf=/etc/masterha/app1.cnf 
app1 is stopped(2:NOT_RINNING).

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

原有 master 節點故障後，需要重新準備好一個新的 MySQL 節點。基於來自於master 節點的備份恢復數據後，將其配置爲新的 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
&>/etc/mha_master/manager.log &

五、新節點上線，故障轉換恢復注意事項

(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

MySQL高可用架構之MHA

MySQL 核心模塊揭祕 | 18 期 | 鎖在內存里長什麼樣*

使用perf工具生成火焰圖

HttpSecurity 是如何組裝過濾器鏈的

數說海南——近6年海南各市縣人口簡單看

長序列中Transformers的高級注意力機制總結

響應式界面控件DevExtreme * 更強的數據分析和可視化功能

MySQL高可用架構之MHA

Redis

nginx簡述

Samba服務

MySQL高可用架構之MHA

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結