Step By Step 搭建 MySql MHA 集羣

時間 2019-11-06

標籤 step 搭建 mysql mha 集羣欄目 MySQL 简体版

原文原文鏈接

關於MHA

MHA（Master High Availability）是一款開源的mysql高可用程序，目前在mysql高可用方面是一個相對成熟的解決方案。MHA 搭建的前提是MySQL集羣中已經搭建了MySql Replication環境，有了Master/Slave節點。MHA的主要做用就是監測到Master節點故障時會提高主從複製環境中擁有最新數據的Slave節點成爲新的master節點。同時，在切換master期間，MHA會經過從其餘的Slave節點來獲取額外的信息來避免一致性的問題，整個的切換過程對於應用程序而言是徹底透明的。MHA還提供了master節點在線切換功能，即按需切換master/slave節點。 node

MHA Manager 和 MHA Node

MHA 服務有兩個角色，MHA Manager 和 MHA Node
MHA Manager: 一般單獨部署在一臺獨立機器上管理 master/slave 集羣，每一個master/slave 集羣能夠理解爲一個application。mysql

MHA Node: 運行在每臺mysql 服務器(master/slave)上。它經過監控具有解析和清理logs功能來加快故障轉移。git

總體上的架構以下圖所示。 github

MHA 在自動切換的過程當中會從宕掉的MySql master節點中保存二進制日誌，以保證數據的完整性。可是若是master節點直接宕機了呢，或者網絡直接不能聯通了呢？MHA就沒有辦法獲取master的二進制日誌，也就沒有辦法保證數據的完整性了。這也就是爲何MHA應該與MySql主從複製結合起來。這樣的話，只要有一個slave節點從master節點複製到了最新的日誌，MHA就能夠將最近的二進制日誌應用到其餘的slave節點上，這樣就能夠最大限度上保證數據的完整性。 sql

MHA 自動切換的原理能夠總結爲下面幾點.shell

從宕機崩潰的master保存二進制日誌事件（binlog events）;
識別含有最新更新的slave;
應用差別的中繼日誌（relay log）到其餘的slave;
應用從master保存的二進制日誌事件（binlog events);
提高一個slave爲新的master;
使其餘的slave鏈接新的master進行復制;

MHA 工具組件

MHA 提供了不少的程序組件，經過這些組件，咱們能夠很方便的管理MHA集羣。後端

Manager節點：centos

masterha_check_ssh：MHA依賴的環境監測工具;
masterha_check_ssh: MySql複製環境檢測工具;
masterha_manager: MHA 服務主程序;
masterha_check_status: MHA運行狀態探測工具;
masterha_master_monitor: MySql master節點可用性檢測工具;
masterha_switch: master 節點切換工具;
masterha_conf_host: 添加或刪除配置的節點;
masterha_stop: 關閉MHA服務的工具;

Node節點:服務器

save_binary_logs:保存和複製master節點的二進制日誌;
apply_diff_relay_logs: 識別差別的中繼日誌事件並應用於其餘的slave;
purge_relay_logs:清除中集日誌(不會阻塞SQL線程);

實驗介紹

在實際的生產環境中有不少的因素須要考慮，例如MHA Manager的單點問題。可是咱們因爲環境有限，因此就暫時不考慮這些。這次實驗中實驗環境以下。網絡

擔任角色	主機名	地址	功能描述	對應軟件版本
MHA Manager	manager	192.168.0.20	MHA Manager,控制Master節點故障轉移	mha4mysql-manager-0.56-0.el6.noarch
MySql Master	master	192.168.0.21	MySql Master 節點	Mariadb-server-5.5.56-2.el7
MySql Slave	Slave1	192.168.0.22	Mysql Repliaction集羣中的Slave1 節點	Mariadb-server-5.5.56-2.el7
MySql Slave	Slave2	192.168.0.26	MySql Repliaction 集羣中的Slave2節點	Mariadb-server-5.5.56-2.el7

準備MySql Replication 環境

安裝PLUGIN

某種意義上說，Master節點不會一直充當master節點。Master節點從故障狀態中恢復以後，頗有可能充當的是slave節點，因此咱們在安裝插件的時候，不作區別對待。
mysql 支持多種插件/var/lib/mysql/plugin 目錄下，須要安裝方可以使用。在Master(192.168.0.21)，和Slave(192.168.0.22,192.168.0.26)節點上安裝semisync_master.so semisync_slave.so 兩個插件。

MariaDB [(none)]> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 
MariaDB [(none)]> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

而後在三臺主機上開啓下面兩個參數

MariaDB [(none)]> SET GLOBAL rpl_semi_sync_master_enabled=ON;                     
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SET GLOBAL rpl_semi_sync_slave_enabled=ON; 
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';    
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled       | ON    |
| rpl_semi_sync_master_timeout       | 10000 |
| rpl_semi_sync_master_trace_level   | 32    |
| rpl_semi_sync_master_wait_no_slave | ON    |
| rpl_semi_sync_slave_enabled        | ON    |
| rpl_semi_sync_slave_trace_level    | 32    |
+------------------------------------+-------+
6 rows in set (0.00 sec)

到目前而言，三臺主機之間沒有差異，也沒有角色上的區分。接下來咱們開始設置master與slave來實現主從複製。

編輯 /etc/my.cnf.d/server.cnf 文件，加入下面這樣一段配置

[mariadb]
server-id=1    #Master設置1，Slave1設置2，Slave2設置3
log-bin=mysql-bin
relay-log=mysql-relay-bin
relay_log_purge=0

修改完配置文件以後，重啓Mariadb. systemctl restart mariadb

在master節點上進行操做

# 這裏須要記住 File 以及Position的數據,在SLAVE 節點上要用到
MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      245 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)   

MariaDB [(none)]> GRANT REPLICATION MASTER ON *.* TO 'repl'@'%' IDENTIFIED BY '123'; 
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

在slave節點上進行操做

MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '123';
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> CHANGE MASTER TO
    -> MASTER_HOST='192.168.0.21',
    -> MASTER_PORT=3306,
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='123',
    -> MASTER_LOG_FILE='mysql-bin.000001', 
    -> MASTER_LOG_POS=245; 
Query OK, 0 rows affected (0.03 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

上面的操做完成後，在master主機上查看master的狀態。

MariaDB [(none)]> SHOW SLAVE HOSTS;  
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         3 |      | 3306 |         1 |
|         2 |      | 3306 |         1 |
+-----------+------+------+-----------+

在slave主機上能夠查看slave主機的狀態。

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.21
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 245
              .............
              .............
             Slave_IO_Running: Yes
             Save_SQL_Running: Yes
              .............

在Master節點上建立MHA監控所須要的用戶，該用戶會同步到slave端。

MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'mha_rep'@'%' IDENTIFIED BY '123'; 

MariaDB [(none)]>  flush privileges;

至此，MySql 主從複製環境就搭建好了。下面就能夠開始來安裝MHA了。

注：在查看slave節點狀態時，若是出現問題，能夠檢查一下SELinux，iptables，以及其餘權限問題，在實驗開始以前，最好先將這些環境設置好，避免出現問題。

安裝配置MHA

設置SSH免密通訊

MHA 集羣中的各節點之間須要基於SSH互相通訊，以實現遠程控制以及數據管理功能。簡單起見，咱們以Manager節點爲例，而後將生成的文件發送到須要管理的主機上。四個節點都須要進行這個操做。

[root@manager ~]# ssh-keygen -t rsa 
[root@manager ~]# for i in 21 22 26;do ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.0.$i; done

這樣MHA Manager就實現了經過SSH免密管理其餘的mysql節點

安裝MHA

MHA 官方提供了rpm的安裝包，經過搜索能夠找到。CentOS 7 能夠直接使用el6 的rpm安裝包。下面是本次實驗中rpm安裝包的下載地址。https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads。

在全部節點上安裝node安裝包

[root@manager ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm

在Manager節點上安裝manager安裝包

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

還能夠在上述網站上下載源碼包，裏面有不少的例子和腳本能夠直接拿來使用。將下載的源碼包解壓以後在samples/scripts下的全部腳本複製到/usr/bin目錄(由於安裝的mha manager的相關命令就在/usr/bin/目錄下，可使用rpm -ql mha4mysql-manager-0.56-0.el6 來查看)下。
腳本以下：

master_ip_failover    #自動切換時vip管理的腳本，不是必須，若是咱們使用keepalived的，咱們能夠本身編寫腳本完成對vip的管理，好比監控mysql，若是mysql異常，咱們中止keepalived就行，這樣vip就會自動漂移
master_ip_online_change    #在線切換時vip的管理，不是必須，一樣能夠能夠自行編寫簡單的shell完成
power_manager    #故障發生後關閉主機的腳本，不是必須
send_report    #因故障切換後發送報警的腳本，不是必須，可自行編寫簡單的shell完成。

這裏有一點須要注意，拷貝到/usr/bin 目錄下的文件若是沒有執行權限，要加上執行權限。

初始化MHA

Manager節點須要爲每一個監控的master/slave 集羣提供專用的配置文件，而全部的master/slave集羣也能夠共享全局配置。全局配置文件默認在/etc/masterha_default.cnf，其爲可選配置。若是僅監控一組master/slave集羣，也能夠直接經過application 的配置來提供給個服務器的默認配置信息。而滅個application的配置文件路徑爲自定義，咱們的實例中，只有一個master/slave集羣，因此咱們就定義一個配置文件好了。

[root@manager ~]# cat /etc/masterha/app1.cnf

[server default]
manager_workdir=/etc/masterha
manager_log=/etc/masterha/manager.log
user=mha_rep
password=123
ping_interval=3
remote_workdir=/etc/masterha
repl_user=repl
repl_password=123
ssh_user=root
master_ip_failover_script=/usr/bin/master_ip_failover
master_ip_online_change_script=/usr/bin/master_ip_online_change
report_script=/usr/bin/send_report
shutdown_script=""
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.22 -s 192.168.0.26   --user=root --master_host=192.168.0.21  --master_ip=192.168.0.21  --master_port=3306

[server1]
hostname=192.168.0.21
port=3306
master_binlog_dir=/var/lib/mysql/
candidate_master=1 
check_repl_delay=0 

[server2]  
hostname=192.168.0.22 
port=3306
master_binlog_dir=/var/lib/mysql/
candidate_master=1  
check_repl_delay=0

[server3]  
hostname=192.168.0.26
port=3306
master_binlog_dir=/var/lib/mysql/
no_master=1

編輯一下 /etc/masterha_default.cnf 文件，添加一些全局的配置。配置文件的內容以下。

[root@manager ~]# cat /etc/masterha_default.cnf 

[server default]
user=mha_rep 
password=123 
repl_user=repl
repl_password=123
ssh_user=root
ping_interval=3
master_binlog_dir=/var/lib/mysql
remote_workdir=/etc/masterha
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.22 -s 192.168.0.26 --user=root --master_host=192.168.0.21  --master_ip=192.168.0.21 --master_port=3306
# 設置自動failover時候的切換腳本;
master_ip_failover_script=/usr/bin/master_ip_failover
# 設置手動切換時候的切換腳本;
master_ip_online_change_script=/usr/bin/master_ip_online_change
# 設置發生切換後發送的報警的腳本;
report_script=/usr/bin/send_report
# 設置故障發生後關閉故障主機腳本（該腳本的主要做用是關閉主機防止發生腦裂,這裏沒有使用）;
shutdown_script=""

檢查mysqlbinlog mysql 命令

在master，slave1 和slave2 節點上執行下面的命令檢查一下mysqlbinlog和mysql 命令的位置。

[root@master ~]# type mysqlbinlog
mysqlbinlog is /usr/bin/mysqlbinlog
[root@master ~]# type mysql      
mysql is /usr/bin/mysql

必定要確保 mysqlbinlog 和mysql 兩個命令在 /usr/bin 目錄下。因爲我安裝的是mariadb ，因此這兩個文件默認就在這兩個目錄，若是是其餘版本的mysql，不在這兩個目錄下的話可使用軟鏈接的方式，在這個目錄下添加兩個軟鏈接。
不然，在進行檢查的時候，會出現以下的相似錯誤。

mysqlbinlog

.....

Can't exec "mysqlbinlog": No suchfile or directory at /usr/local/share/perl5/MHA/BinlogManager.pm line 106.
mysqlbinlog version command failed with rc1:0, please verify PATH, LD_LIBRARY_PATH, and client options

.....

mysql

.....
Testing mysql connection and privileges..sh: mysql: command not found
mysql command failed with rc 127:0!
.....

配置VIP

在master 節點上進行操做，給ens33網卡添加一個VIP，這樣用戶訪問的時候，就會能夠經過VIP進行訪問，並不須要關心MySQL集羣中的具體細節。同時若是master宕機以後，VIP會自動進行轉移，並不會影響到用戶的訪問，後端VIP漂移的過程對用戶來講徹底透明。

[root@manager ~]# ifconfig ens33:1 192.168.0.88

在MHA manager上進行操做，修改/usr/bin/master_ip_failover腳本以下，主要是VIP的修改。

[root@centos7-1 ~]# cat /usr/bin/master_ip_failover 
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';

use Getopt::Long;

my (
    $command,          $ssh_user,        $orig_master_host, $orig_master_ip,
    $orig_master_port, $new_master_host, $new_master_ip,    $new_master_port
);

my $vip = '192.168.0.88/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";

GetOptions(
    'command=s'          => \$command,
    'ssh_user=s'         => \$ssh_user,
    'orig_master_host=s' => \$orig_master_host,
    'orig_master_ip=s'   => \$orig_master_ip,
    'orig_master_port=i' => \$orig_master_port,
    'new_master_host=s'  => \$new_master_host,
    'new_master_ip=s'    => \$new_master_ip,
    'new_master_port=i'  => \$new_master_port,
);

exit &main();

sub main {

    print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";

    if ( $command eq "stop" || $command eq "stopssh" ) {

        my $exit_code = 1;
        eval {
            print "Disabling the VIP on old master: $orig_master_host \n";
            &stop_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn "Got Error: $@\n";
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "start" ) {

        my $exit_code = 10;
        eval {
            print "Enabling the VIP - $vip on the new master - $new_master_host \n";
            # 這一行很重要，表示在master上mysql服務中止以後，關閉掉VIP，以避免地址衝突
            &stop_vip();
            &start_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn $@;
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "status" ) {
        print "Checking the Status of the script.. OK \n";
        exit 0;
    }
    else {
        &usage();
        exit 1;
    }
}

sub start_vip() {
    `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {
     return 0  unless  ($ssh_user);
    `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}

sub usage {
    print
    "Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

驗證MHA

通過上述的一系列的的配置和操做，咱們就順利的配置好了MySql replication 環境和MHA 環境，接下來開始驗證一下。
在MHA manager 上進行一下下面的操做。

# 檢測主機之間的SSH 聯通性
[root@manager ~]#  masterha_check_ssh --conf=/etc/masterha/app1.cnf
.....
# 省略了不少非關鍵信息 出現相似下面的 successfully 表示SSH 聯通性檢測成功
Sun Jan 14 20:09:30 2018 - [info] All SSH connection tests passed successfully.

# 檢測mysql 複製集羣的配置參數是否正確
[root@manager ~]#  masterha_check_ssh --conf=/etc/masterha/app1.cnf

.......

#  能夠看到咱們配置的master/slave信息
192.168.0.21(192.168.0.21:3306) (current master)
 +--192.168.0.22(192.168.0.22:3306)
 +--192.168.0.26(192.168.0.26:3306)

.....

# 省略了不少非必要信息，出現下面的Health is OK ，說明主從複製檢測成功
MySQL Replication Health is OK.

啓動MHA

在manager 節點上進行操做。

[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 &
[1] 7861
[root@manager ~]#  masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:7861) is running(0:PING_OK), master:192.168.0.21

中止MHA

若是想要中止MHA 能夠執行以下的命令

[root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf                                                        
Stopped app1 successfully.
[1]+  Exit 1                  nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1

MHA 測試故障轉移

在master節點關閉mariadb 服務

systemctl stop mariadb

在Manager 節點查看/etc/masterha/manager.log

在manager節點查看 manager.log 的日誌，能夠看到下面的切換過程

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

app1: MySQL Master failover 192.168.0.21(192.168.0.21:3306) to 192.168.0.22(192.168.0.22:3306) succeeded

Master 192.168.0.21(192.168.0.21:3306) is down!

Check MHA Manager logs at manager:/etc/masterha/manager.log for details.

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

注意，故障轉移完成以後，manager會自動中止，此時使用masterha_check_status命令檢測將會是下面這種結果.

[root@manager ~]#  masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).

在新的Master上進行驗證

在新的master主機slave1上進行查看,master_id 已經進行了切換，而且少了一臺slave 主機。

MariaDB [(none)]> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         3 |      | 3306 |         2 |
+-----------+------+------+-----------+
1 row in set (0.00 sec)

在slave2主機上查看slave 的當前狀態。

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.22
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000004
          Read_Master_Log_Pos: 384
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 529
        Relay_Master_Log_File: mysql-bin.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

            .......................

能夠看到最新的master的IP 已經變成了以前slave1 主機的IP地址，這說明master 切換成功。

在新Master主機上查看VIP遷移，舊master主機上查看IP

在新的master 主機上查看ip地址的變化,若是VIP 漂移成功說明，以前的配置沒有問題。

[root@slave1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:37:c4:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.88/24 brd 192.168.0.255 scope global ens33:1
       valid_lft forever preferred_lft forever
    inet 192.168.0.22/24 brd 192.168.0.255 scope global secondary dynamic ens33
       valid_lft 6390sec preferred_lft 6390sec
    inet6 fe80::e9cb:24a6:f81d:1810/64 scope link 
       valid_lft forever preferred_lft forever

在舊的master主機上查看VIP是否已經被移除。

[root@master ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:29:d0:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.21/24 brd 192.168.0.255 scope global dynamic ens33
       valid_lft 7198sec preferred_lft 7198sec
    inet6 fe80::c28a:e648:5959:5ad6/64 scope link 
       valid_lft forever preferred_lft forever

若是上面兩項的檢測都沒有問題，說明在實際的使用過程當中VIP 就不會產生地址衝突了。並且地址切換過程對用戶來講，基本上沒有任何感知，這樣就保證了mysql服務的高可用了。

搶救故障節點，從新加入集羣

生產中mysql服務停掉能夠當即監監控到，並且這基本上屬於以及故障須要當即進行排除。
從新恢復宕掉的mysql服務比較好的思路是，將其基於最新的master節點的數據備份進行數據恢復，而後從新啓動服務，將其設置爲slave節點，並加入到新的master集羣，以後重啓MHA監控。
備份還原過程，此處再也不贅述。將啓動後的節點從新加入到新的master集羣中。過程與以前介紹的相似。

MariaDB [(none)]> CHANGE MASTER TO
    ->  MASTER_HOST='192.168.0.22',
    ->    MASTER_PORT=3306,
    ->    MASTER_USER='repl',
    ->   MASTER_PASSWORD='123',
    ->     MASTER_LOG_FILE='mysql-bin.000004', 
    -> MASTER_LOG_POS=384; 
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

在新的master節點上查看最新的slave主機狀態。

MariaDB [(none)]> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         1 |      | 3306 |         2 |
|         3 |      | 3306 |         2 |
+-----------+------+------+-----------+
2 rows in set (0.00 sec)

能夠看到slave 主機的server_id 已經變化了。

在manager主機上檢查MHA

在manager上修改/etc/masterha/app1.cnf中secondary_check_script中的master IP值，將新的master ip修改上

secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.21 -s 192.168.0.26   --user=root --master_host=192.168.0.22  --master_ip=192.168.0.22  --master_port=3306

修改/etc/masterha_default.cnf 中secondary_check_script 中的IP地址

secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.21 -s 192.168.0.26 --user=root --master_host=192.168.0.22  --master_ip=192.168.0.22 --master_port=3306

在Manager 上啓動MHA 而後檢查MHA的狀態

[root@centos7-1 ~]#  masterha_check_repl --conf=/etc/masterha/app1.cnf   

.........

192.168.0.22(192.168.0.22:3306) (current master)
 +--192.168.0.21(192.168.0.21:3306)
 +--192.168.0.26(192.168.0.26:3306)

......

MySQL Replication Health is OK.

啓動MHA ，檢查MHA的狀態

[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 &
[1] 9186
[root@manager ~]#  masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:9186) is running(0:PING_OK), master:192.168.0.22