2. 程式人生 > >MySQL/MariaDB高可用架構之MHA

MySQL/MariaDB高可用架構之MHA

阿新 • • 發佈：2019-01-03

宣告：本次實驗使用的是MariaDB資料庫，所以本文中所出現的MariaDB與MySQL都是指的是MariaDB！！！

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 服務有兩種角色，MHA Manager(管理節點)和 MHA Node(資料節點)：

MHA Manager：

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

MHA node：

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

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

MHA常用工具：

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工作原理簡介

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 slave1

    node3: MariaDB slave2

    node4: MHA Manager

各節點的/etc/hosts檔案配置內容中新增：

    172.17.254.76     manager.wereal.top  manager

    172.17.250.230    master.wereal.top   master

    172.17.254.165    slave1.wereal.top   slave1

    172.17.254.180    slave2.wereal.top   slave2
1、初始主節點master配置：
[[email protected] ~]# vim /etc/my.cnf
[mysqld]
server-id = 1
log-bin = master-log
relay-log = relay-log
skip_name_resolve = ON
2、所有slave節點依賴的配置：
[root@CentOS7-slave1 ~]# vim /etc/my.cnf
[mysqld]
server-id = 2  #複製叢集中的各節點的id均必須唯一；
relay-log = relay-log  #開啟中繼日誌；
log-bin = master-log   #開啟二進位制日誌，因為每一臺slave都可能會變成master；
read_only = ON  #開啟只讀許可權；
relay_log_purge = 0 #是否自動清空不再需要的中繼日誌；
skip_name_resolve = ON  #不進行域名解析

[root@CentOS7-slave2 ~]# vim /etc/my.cnf
[mysqld]
server-id = 3 #複製叢集中的各節點的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 '[email protected]%.%' IDENTIFIED BY 'wereal';
MariaDB [(none)]>
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]>
MariaDB [(none)]> SHOW MASTER STATUS;

各slave節點上：

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.17.250.230', MASTER_USER='slave', MASTER_PASSWORD='wereal', MASTER_LOG_FILE='master-log.000003', MASTER_LOG_POS=498;
MariaDB [(none)]> 
MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> 
MariaDB [(none)]> SHOW SLAVE STATUS\G;

二、安裝配置MHA

1、許可權設定

在所有MYSQL節點授權擁有管理許可權的使用者可在本地網路中有其他節點上遠端訪問。當然，此時僅需要且只能在master節點執行類似如下SQL語句即可。

mysql> GRANT ALL ON *.* TO 'mhaadmin'@'172.17.%.%' IDENTIFIED BY 'mhapass';
2、準備基於SSH互信通訊環境：

MHA叢集中的各節點彼此之間均需要基於ssh互信通訊，以實現遠端控制及資料管理功能。簡單起見，可在Manager節點生成金鑰對兒，並設定其可遠端連線本地主機後，將私鑰檔案及authorized_keys檔案複製給餘下的所有節點即可。

下面操作在Manager 節點上操作（其餘機器上的操作也是一樣的！！！ ）：

[root@manager ~]# ssh-keygen -t rsa
[root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
[root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
[root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
[root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]
3、 進行MHA安裝包安裝

Manager 節點： 

yum install mha4mysql-manager-0.56-0.el6.noarch.rpm

所有節點，包括Manager： 

yum install mha4mysql-node-0.56-0.el6.norch.rpm

說明：在manager上若是選擇本地安裝，則最好將兩個包全都下載下來，然後執行以下指令，將兩個包一起安裝！ 命令如下：

yum -y localinstall mha4mysql-*
4、初始化MHA，進行配置

Manager 節點需要為每個監控的master/slave叢集提供一個專用的配置檔案，而所有的master/slave叢集也可共享全域性配置。全域性配置檔案預設為/etc/masterha_default.cnf，其為可選配置。如果僅監控一組master/slave叢集，也可直接通過application的配置來提供各伺服器的預設配置資訊。而每個application的配置檔案路徑為自定義。

5、 定義MHA管理配置檔案

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

[root@manager ~]# mkdir /etc/mha_master 
[root@manager ~]# 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=magedu //資料庫密碼 
ping_interval=1 // ping間隔時長 

[server1] //節點1，[server1]節點必須設定成master 
hostname=172.17.250.230 //節點1主機地址 
ssh_port=22 //節點1的ssh埠 
candidate_master=1 // 將來可不可以成為master候選節點/主節點 

[server2] //節點3 
hostname=172.17.254.165 //節點1主機地址 
ssh_port=22 //節點1的ssh埠 
candidate_master=1 // 將來可不可以成為master候選節點/主節點 

[server3] //節點2
hostname=172.17.254.180
ssh_port=22 
candidate_master=1

節點設定，有幾臺主從機器，就要設定幾個[serverX]（[server default]除外，[server default]是必須要有的！“X”為具體的數字！），節點設定必須要從[server1]開始！！

6、進行節點檢測

首先檢測各節點間ssh互信通訊配置是否Ok：

[root@nmanager ~]# masterha_check_ssh -conf=/etc/mha_master/app1.cnf

輸出資訊最後一行類似如下資訊，表示其通過檢測。
[info]All SSH connection tests passed successfully.
若是報錯，則要檢查幾臺機器的ssh設定是否都可以實現無祕鑰訪問！
檢測各節點許可權設定是否生效：

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/app1.cnf

如果測試時會報錯，可能是從節點上沒有賬號，因為這個架構，任何一個從節點，將有可能成為主節點，所以也需要建立賬號；若是報錯,則要檢查MySQLy使用者是否授權！
因此，這裡只要在各節點上執行以下操作，對manager進行授權即可：

MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO '[email protected]%.%' IDENTIFIED BY 'wereal';
MariaDB [(none)]> 
MariaDB [(none)]> FLUSH PRIVILEGES;

在Manager節點上再次執行，就顯示Ok了。

三、啟動MHA

[[email protected] ~]#nohup masterha_manager -conf=/etc/mha_master/app1.cnf &> /etc/mha_master/manager.log &

啟動成功後，可用過如下命令來檢視master節點的狀態:

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/app1.cnf

執行上面指令後，顯示如下的資訊app1 (pid:4978)is running(0:PING_OK)，表示MHA服務執行OK，否則，則會顯示為類似app1 is stopped(1:NOT_RUNNINg).

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

如果要停止MHA，需要使用master_stop命令。

[root@manager ~]# masterha_stop -conf=/etc/mha_master/app1.cnf

四、測試MHA測試故障轉移

1、在master節點關閉mariadb服務,模擬主節點資料崩潰
[root@master ~]# killall -9 mysqld mysqld_safe
[root@master ~]# rm -rf /var/lib/mysql/*
2、在manager節點檢視日誌：

/etc/mha_master/app1/manager.log 日誌檔案中出現如下資訊，表示manager檢測到172.17.250.230節點故障，而後自動執行故障轉移，將172.17.254.180提升為主節點。注意，故障轉移完成後，manager將會自動停止，此時使用masterha_check_status 命令檢測將會遇到錯誤提示，如下所示：

[root@manager ~]# masterha_check_status –conf=/etc/mha_master/app1.cnf

提示資訊：app1 is stopped(2:NOT_RINNING).

3、提供新的從節點以修復複製叢集

原有 master 節點故障後，需要重新準備好一個新的 MySQL 節點。基於來自於master 節點的備份恢復資料後，將其配置為新的 master 的從節點即可。

注意，新加入的節點如果為新增節點，其 IP 地址要配置為原來 master 節點的 IP，否則，還需要修改 app1.cnf 中相應的 ip 地址。隨後再次啟動 manager，並再次檢測其狀態。

4、新節點提供後再次執行檢查操作
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/app1.cnf

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/app1.cnf

檢查無誤，再次執行，這次要記錄日誌

[[email protected] ~]# masterha_manager -conf=/etc/mha_master/app1.cnf > /etc/mha_master/manager.log 2>&1

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

1、在生產環境中，當你的主節點掛了後，一定要在從節點上做一個備份，拿著備份檔案把主節點手動提升為從節點，並指明從哪一個日誌檔案的位置開始複製。

2、每一次自動完成轉換後，每一次的(replication health )檢測不ok始終都是啟動不了必須手動修復主節點，除非你改配置檔案

3、手動修復主節點提升為從節點後，再次執行檢測命令
[root@manager ~]# masterha_check_repl --conf=/etc/mha_master/app1.cnf

app1 (pid:3211) is running(0:PING_OK), master:172.17.254.165

4、再次執行起來就恢復成功了
[root@manager ~]# masterha_manager -conf=/etc/mha_master/app1.cnf

相關推薦

MySQL/MariaDB高可用架構之MHA

宣告：本次實驗使用的是MariaDB資料庫，所以本文中所出現的MariaDB與MySQL都是指的是MariaDB！！！ MHA（Master HA）是一款開源的 MySQL 的高可用程式，它為 MySQL主從複製架構提供 了 automating master

mysql實現高可用架構之MHA

行數據 reading glob restart 比較 實驗 是否 其余 one 一、簡介 　　MHA（Master HA）是一款開源的 MySQL 的高可用程序，它為 MySQL 主從復制架構提供了 automating master failover 功能。MHA 在監

MariaDB高可用架構之MHA--VIP切換

#!/usr/bin/env perl use strict; use warnings FATAL => 'all'; use Getopt::Long; my (     $command,          $ssh_user,        $orig_master_host, $orig_ma

MariaDB高可用架構之MHA

rep tom each edi ror state ant mman status MHA（Master High Availability） 該軟件由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。MHA Manager可以單獨部署在一臺獨

MySQL高可用架構之MHA

mysql1、關於MHAMHA(Master HA)是一款開源的MySQL的高可用程序，它為MySQL主從復制架構提供了automating master failover功能。MHA在監控到master節點故障時，會提升其中擁有的最新數據的slave節點成為新的master節點，在此期間，MHA會通過其它從

互聯網金融MySQL高可用架構之-MHA故障切換

文件 ads erro osi ddr app1 bind enabled ive 互聯網金融MySQL高可用架構之-MHA 在線平滑切換過程 --切換命令如下： [root@MHA bin]# masterha_master_switch --conf=/etc/app1

mysql高可用架構之MHA和mysql日誌優化

一、MHA簡介： MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現就職於 Facebook公司）開發，是一套優秀的作為MySQL高可用性環境下故障切換和主從提升的高可用軟體。在M

MySQL高可用架構之MHA搭建以及測試（二）

一、MHA特點 MHA監控複製架構的主伺服器，一旦檢測到主伺服器故障，就會自動進行故障轉移。 即使有些從伺服器沒有收到最新的relay log，MHA自動從最新的從伺服器上識別差異的relay log並把這些日誌應用到其他從伺服器上，因此所有的從伺服器保持一致性了。MHA通

MySQL高可用架構之基於MHA的搭建

MySQL高可用架構之基於MHA的搭建  一、MySQL MHA架構介紹： MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現就職於Facebook公司）開發，是一套

MySQL高可用架構之MySQL5.7.19 PXC

mysql高可用 5.7 sta var show mysql clu -- ike mysql> show global status like ‘wsrep_cluster_size‘;+--------------------+-------+| Variabl

mysql database 高可用架構：MariaDB Galera Cluster

[[email protected] ~]# rpm -ivh epel-release-6-8.noarch.rpm  [[email protected] ~]# yum install -y

MySQL 高可用架構之MMM

簡介 MMM（Master-Master replication manager for MySQL）是一套支援雙主故障切換和雙主日常管理的指令碼程式。MMM使用Perl語言開發，主要用來監控和管理MySQL Master-Master（雙主）複製，雖然叫做雙主複製，但是業務上同一時刻只允許對一個主進行寫入

MySQL雙主高可用架構之MMM實戰

MMM簡介： MMM即Master-Master Replication Manager for MySQL（mysql主主複製管理器），是關於mysql主主複製配置的監控、故障轉移和管理的一套可伸縮的指令碼套件（在任何時候只有一個節點可以被寫入），這個套件也能基於標準

CentOS 搭建 Mysql MMM 高可用架構

install 高可用 padding log isa har mmm_mond replica tro 環境 CentOS Mysql 5.1 前提 安裝了EPEL，詳細安裝步驟請參照 http://blog.csdn.net/robinsonmhj/articl

京東618：商城交易平臺的高可用架構之路

資源 系統 定位問題 修復 tle 峰值 網絡 寫入 差異 據騰訊科技報道，6月18日零點，京東全民年中購物節拉開了高潮的序幕。第一個小時的銷售額超過去年同期的250%。從淩晨開始的海量訂單讓6月1日就拉開序幕的京東年中購物節奏出最強音，大量用戶瞬間湧入，峰值訂單被不斷刷新

高可用架構之高可用的應用和服務

高可用的網站架構需要網站應用每個層面的支援，本文著重介紹應用層和服務層的高可用的解決方案。 1、高可用的應用 應用層主要處理網站應用的業務邏輯，因此有時也被稱作業務邏輯層，應用的一個顯著特點是應用的無狀態性。 所謂無狀態的應用是指應用伺服器不儲存業務的上下文資訊，而僅根據

京東商城交易平臺的高可用架構之路

作者：王曉鍾 編輯：木環、郭蕾 據騰訊科技報道，6 月 18 日零點，京東全民年中購物節拉開了高潮的序幕。第一個小時的銷售額超過去年同期的 250%。從凌晨開始的海量訂單讓 6 月 1 日就拉開序幕的京東年中購物節奏出最強音，大量使用者瞬間湧入，峰值訂單被不斷重新整理。為了應對如此大規模的流量增長

nfs高可用架構之DRBD+heartbeat

一：軟體簡介 Heartbeat介紹 官方站點：http://linux-ha.org/wiki/Main_Pageheartbeat可以資源(VIP地址及程式服務)從一臺有故障的伺服器快速的轉移到另一臺正常的伺服器提供服務，heartbeat和keepalived相似，h

高可用架構之分散式快取

為什麼需要快取?加速請求響應時間,響應延遲小減少對固化儲存的讀壓力 快取適用場合靜態資源的快取較少更改資源的快取讀多寫少場景不適合場景頻繁更新讀少寫多 高可用架構使用的快取型別有哪些?各自作用是什麼?本地快取靜態不變的資料減少網路I/O互動程序內快取和程序相關的動態資料動態

京東京麥開放平臺的高可用架構之路

京麥是京東商家的多端開放式工作平臺，是京東十萬商家唯一的店鋪運營管理平臺，為京東商家提供在移動和桌面端的操作業務，京麥本身是一個開放的端體系架構，由京東官方和 ISV 為商家提供多樣的應用服務。 京麥開發平臺是京東系統與外部系統通訊的重要平臺，技術架構從早期的單一 Ng