mysql高可用研究(一) 主從+MHA架構

時間 2019-11-19

標籤 mysql 可用研究主從 mha 架構欄目 MySQL 简体版

原文原文鏈接

最近在研究mysql的高可用架構，本身想總結下經常使用的高可用方案都有哪些、有哪些優缺點以及應用的場景？搞得是頭昏腦漲，天昏地暗，看了諸多資料，每次都以爲公說公有理婆說婆有理。其實嘛，你們說的都有必定的道理，只不過適合本身的纔是最正確的。今天就從比較經常使用的主從+MHA提及。html

學習一種新的架構仍是軟件，最好仍是先從瞭解它的原理開始，這樣才能在應用時揚長避短。node

1、【MHA原理】mysql

相較於其它HA軟件，MHA的目的在於維持MySQL Replication中Master庫的高可用性，其最大特色是能夠修復多個Slave之間的差別日誌，最終使全部Slave保持數據一致，而後從中選擇一個充當新的Master，並將其它Slave指向它。sql

MHA軟件由兩部分組成，Manager工具包和Node工具包，具體的說明以下。數據庫

Manager工具包主要包括如下幾個工具：vim

masterha_check_ssh              檢查MHA的SSH情況
masterha_check_repl             檢查MySQL複製情況
masterha_manger                 啓動MHA
masterha_check_status           檢測當前MHA運行狀態
masterha_master_monitor         檢測master是否宕機
masterha_master_switch          控制故障轉移（自動或者手動）
masterha_conf_host              添加或刪除配置的server信息

Node工具包（這些工具一般由MHA Manager的腳本觸發，無需人爲操做）主要包括如下幾個工具：bash

save_binary_logs                保存和複製master的二進制日誌
apply_diff_relay_logs           識別差別的中繼日誌事件並將其差別的事件應用於其餘的slave
filter_mysqlbinlog              去除沒必要要的ROLLBACK事件（MHA已再也不使用這個工具）
purge_relay_logs                清除中繼日誌（不會阻塞SQL線程）

基本工做流程大體以下：服務器

（1） Manager按期監控Master，監控時間間隔由參數ping_interval決定，缺省爲3秒鐘一次；可利用其自身的監控功能，也可調用第三方軟件來監控；MHA自身提供了兩種監控方式：SELECT（執行SELECT 1）和CONNECT（建立鏈接/斷開鏈接），session

主要由ping_type參數決定，默認是select方式。架構

（2）當監測到Master故障時，調用SSH腳本對全部Node執行一次檢查，包括以下幾個方面：

――MySQL實例是否能夠鏈接；

――Master服務器是否能夠SSH連通；

　　 ――檢查SQL Thread的狀態；

　　 ――檢查哪些Server死掉了，哪些Server是活動的，以及活動的Slave實例；

　　 ――檢查Slave實例的配置及複製過濾規則；

　　 ――最後退出監控腳本並返回表明特殊意義代碼。

（3）開始Master故障切換，包括以下幾個子階段：

　　 ――Phase 1: Configuration Check Phase

在這個階段，若某個Slave實例的SQL Thread中止了，則會自動啓動它；並再次確認活動的Servers及Slaves。

　　 ――Phase 2: Dead Master Shutdown Phase

在這個階段，首先調用master_ip_failover_script，若HA是基於VIP實現的，則關閉VIP，如果基於目錄數據庫實現的，則修改映射記錄。而後調用shutdown_script腳本強制關閉主機，以免服務重啓時，發生腦裂。

　　 ――Phase 3: Master Recovery Phase

　　　又包括以下3個子階段：

　　　　 Phase 3.1: Getting Latest Slaves Phase

　　　　檢查各個Slave，獲取最近的和最舊的binary log file和position，並檢查各個Slave成爲Master的優先級，依賴於candidate_master、no_master、 [server_xxx]順序、binary log差別量等因素。

　　　　 Phase 3.2: Saving Dead Master's Binlog Phase

　　　　若dead master所在服務器依然能夠經過SSH連通，則提取dead master的binary log，提取日誌的起點就是上一步獲取的最新的binary log file和position，直到最後一條事件日誌，並在dead master本地的工做目錄（由參數remote_workdir決定）中

建立文件保存這些提取到的日誌，而後將該文件拷貝到Manager服務器的工做目錄下（由參數manager_workdir決定）。若dead master系統就沒法鏈接，也就不存在差別的binary log了。MHA還要對各個Slave節點進行健康檢查，主要是SSH連通性。

　　　　Phase 3.3: Determining New Master Phase

　　　　接下來調用apply_diff_relay_logs命令恢復Slave的差別日誌，這個差別日誌指的是各個Slave之間的relay log。恢復完成後，全部的Slave數據是一致的，此時就能夠根據優先級選擇New Master了。

　　　　Phase 3.4: New Master Diff Log Generation Phase

　　　　這裏是生成dead master和new master之間的差別日誌，即將Phase 3.2保存的binary log拷貝到New Master的工做目錄中（remote_workdir）。

　　　　Phase 3.5: Master Log Apply Phase

　　　　將上一步拷貝的差別日誌恢復到New Master上，若發生錯誤，也可手動恢復。而後獲取New Master的binlog name和position，以便其它Slave從這個新的binlog name和position開始複製。最後會開啓New Master的寫權限，即將read_only參數設置爲0。

　　 ――Phase 4: Slaves Recovery Phase

　　　　Phase 4.1: Starting Parallel Slave Diff Log Generation Phase

　　　　生成Slave與New Slave之間的差別日誌，並將該日誌拷貝到各Slave的工做目錄下，這部分日誌dead master和new master之間差別的那部分日誌，由於各個Slave在Phase 3.3階段已經同步了。

　　　　Phase 4.2: Starting Parallel Slave Log Apply Phase

　　　　在各個Slave上應用這部分差別日誌，而後經過CHANGE MASTER TO命令將這些Slave指向新的New Master，最後開始複製(start slave)。

　　 ――Phase 5: New master cleanup phase

　　　　清理New Master其實就是重置slave info，即取消原來的Slave信息。至此整個Master故障切換過程完成。

2、【實驗部分】

一、【環境說明】：默認三臺機器上都已安裝mysql5.6,且主從複製已經配置完成。
角色                 主機名      ip地址       功能
主庫                    node1   192.168.245.129    (w/r)
candidate_master       node2   192.168.245.131     (r)
從庫                    node3    192.168.245.132    (r)
vip： 192.168.245.100

129爲主庫，對外提供讀寫服務，而131和132機器對外提供讀服務，須要設置爲只讀狀態，不建議將它寫入配置文件，由於從庫隨時會切換爲主庫。以下：

set global read_only=1

二、配置三臺機器之間的信任機制（省）

目的：機器之間可以無需輸入密碼進行訪問。

三、安裝mha軟件

rpm安裝：每臺機器都要安裝node，manager節點建議安裝到單獨的一臺機器上或者一個不用切換爲主的從庫上

#安裝可能須要的依賴包
[root@node1 software]# yum install perl-DBD-MySQL  
[root@node1 software]# yum install perl-Config-Tiny
[root@node1 software]# yum install perl-Parallel-ForkManager*.rpm                
[root@node1 software]# yum install perl-Mail-Sender*.rpm 
[root@node1 software]# yum install perl-Mail-Sendmail*.rpm 
[root@node1 software]# yum install perl-Log-Dispatch*.rpm 
#安裝mha，這裏用rpm包安裝，默認在/usr/bin
[root@node1 software]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm
[root@node1 software]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm

二進制包安裝

#node安裝
wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.53.tar.gz
tar xf mha4mysql-node-0.53.tar.gz
cd mha4mysql-node-0.53
perl Makefile.PL
make && make install

#manager安裝
wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.53.tar.gz
tar xf mha4mysql-manager-0.53.tar.gz 
cd mha4mysql-manager-0.53
perl Makefile.PL
make && make install

四、手工配置主庫服務器的vip並測試

這裏經過腳本手動建立vip，以下：

[root@node1 scripts]# cat init_vip.sh 
vip="192.168.245.100/32"
/sbin/ip addr add $vip dev eth0

【測試】

綁定完成後，能夠用如下命令查看綁定狀況：

[root@node2 etc]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:d7:0f:4a brd ff:ff:ff:ff:ff:ff
    inet 192.168.245.131/24 brd 192.168.245.255 scope global eth0
    inet 192.168.245.100/32 scope global eth0
    inet6 fe80::20c:29ff:fed7:f4a/64 scope link 
       valid_lft forever preferred_lft forever

到任意從庫ssh 192.168.245.100 --看是否連上vip或者mysql -h 192.168.245.100 -udarren -pdarren --是否連上vip數據庫. 若是都可以鏈接上，表示vip設置成功了。

五、配置mha及啓動

（1）建立mha監控用戶（在主庫執行，這樣每一個服務器都有這個用戶了）

mysql> grant all privileges on *.* to 'root'@'%' identified  by '123456';
Query OK, 0 rows affected (0.00 sec)

mysql> flush  privileges;
Query OK, 0 rows affected (0.01 sec)

（2）關閉purge_relay_logs：

在修改配置文件前，注意一個知識點，須將從庫上的relay log自動清除設置爲OFF，由於MySQL數據庫主從複製在缺省狀況下從庫的relay logs會在SQL線程執行完畢後被自動刪除，可是對於MHA場景下，對於某些滯後從庫的恢復依賴於其餘從庫的relay log，所以採起禁用自動刪除功能以及按期清理的辦法。對於清理過多過大的relay log須要注意引發的複製延遲資源開銷等。MHA可經過purge_relay_logs腳本及配合cronjob來完成此項任務。

purge_relay_logs的主要功能：

a、爲relay日誌建立硬連接(最小化批量刪除大文件致使的性能問題)

b、SET GLOBAL relay_log_purge=1; FLUSH LOGS; SET GLOBAL relay_log_purge=0;
c、刪除relay log（rm –f /path/to/archive_dir/*）

purge_relay_logs的用法及相關參數
1 purge_relay_logs --help
   Usage:
       purge_relay_logs --user=root --password=rootpass --host=127.0.0.1

2 參數描述
--user             用戶名，缺省爲root
--password         密碼
--port             端口號
--host             主機名，缺省爲127.0.0.1
--workdir          指定建立relay log的硬連接的位置，默認是/var/tmp，成功執行腳本後，硬連接的中繼日誌文件被刪除,因爲系統不一樣分區建立硬連接文件會失敗，故須要執行硬連接具體位置，建議指定爲relay log相同的分區
--disable_relay_log_purge 默認狀況下，若是參數relay_log_purge=1，腳本不作任何處理，自動退出.設定該參數，腳本會將relay_log_purge設置爲0，當清理relay log以後，最後將參數設置爲OFF(0)

3 定製清理relay log cronjob
pureg_relay_logs腳本在不阻塞SQL線程的狀況下自動清理relay log。對於不斷產生的relay log直接將該腳本部署到crontab以實現按天或按小時按期清理。
$ crontab -l 
# purge relay logs at 5am 
0 5 * * * app /usr/bin/purge_relay_logs --user=root --password=PASSWORD --disable_relay_log_purge >> /var/log/masterha/purge_relay_logs.log 2>&1

在咱們的兩個從庫上設置relaylog爲OFF:

(product)root@127.0.0.1 [(none)]> set global relay_log_purge=0;
Query OK, 0 rows affected (0.00 sec)

而後經過定時任務，每隔一天定時清除relaylog：

#清除腳本
#!/bin/bash
user=root
passwd=root
port=3306
log_dir='/data/masterha/log'
work_dir='/data'
purge='/usr/bin/purge_relay_logs'

if [ ! -d $log_dir ]
then
   mkdir $log_dir -p
fi

$purge --user=$user --password=$passwd --disable_relay_log_purge --port=$port --workdir=$work_dir >> $log_dir/purge_relay_logs.log 2>&1

#定時任務
crontab -e
#天天早上5點10分執行
10 5 * * * sh /data/scripts/purge_relay_log.sh

（3）修改配置文件：

到manager節點的/etc下面新建masterha目錄，並將mha須要的配置初始化文件拷貝到該目錄下：

[root@node3 ~]# cd /etc
[root@node3 etc]# mkdir masterha
#建立如下mha日誌目錄，沒有則報錯
[root@node3 etc]#mkdir -p /var/log/masterha/app1

[root@node3 mastermha]# ll
total 32
-rw-r--r--. 1 root root   503 Nov  9 01:26 app1.conf
-rwxr-xr-x. 1 root root    55 Nov  9 01:26 drop_vip.sh
-rwxr-xr-x. 1 root root    55 Nov  9 01:26 init_vip.sh
-rw-r--r--. 1 root root   357 Nov  9 01:26 masterha_default.conf
-rwxr-xr-x. 1 root root  3888 Nov  9 01:26 master_ip_failover
-rwxr-xr-x. 1 root root 10298 Nov  9 01:26 master_ip_online_change

而後修改vip的值：在masterha目錄下執行grep "vip" *,將會列出全部文件中vip變量，而後一一修改成192.168.245.100。

修改app1.conf文件：

[server default]
manager_log=/var/log/masterha/app1/app1.log
manager_workdir=/var/log/masterha/app1
master_ip_failover_script="/etc/masterha/master_ip_failover"
master_ip_online_change_script="/etc/masterha/master_ip_online_change"
password=root
ping_interval=1
remote_workdir=/var/log/masterha/app1
repl_password=repl4slave
repl_user=repl
report_script="/etc/masterha/send_mail"
shutdown_script=""
ssh_user=root
user=root

[server1]
candidate_master=1
check_repl_delay=0
hostname=192.168.245.129
master_binlog_dir=/data/mysql/mysql_3306/logs

[server3]
hostname=192.168.245.132
port=3306

（4）檢查mha環境並啓動

#檢查MHA Manger到全部MHA Node的SSH鏈接狀態：
[root@node3 masterha]# /usr/bin/masterha_check_ssh --conf=/etc/masterha/app1.conf
Mon Nov 16 01:24:21 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Nov 16 01:24:21 2015 - [info] Reading application default configuration from /etc/masterha/app1.conf..
Mon Nov 16 01:24:21 2015 - [info] Reading server configuration from /etc/masterha/app1.conf..
Mon Nov 16 01:24:21 2015 - [info] Starting SSH connection tests..
Mon Nov 16 01:24:24 2015 - [debug] 
Mon Nov 16 01:24:21 2015 - [debug]  Connecting via SSH from root@192.168.245.129(192.168.245.129:22) to root@192.168.245.131(192.168.245.131:22)..
Mon Nov 16 01:24:23 2015 - [debug]   ok.
Mon Nov 16 01:24:23 2015 - [debug]  Connecting via SSH from root@192.168.245.129(192.168.245.129:22) to root@192.168.245.132(192.168.245.132:22)..
Mon Nov 16 01:24:24 2015 - [debug]   ok.
Mon Nov 16 01:24:25 2015 - [debug] 
Mon Nov 16 01:24:22 2015 - [debug]  Connecting via SSH from root@192.168.245.131(192.168.245.131:22) to root@192.168.245.129(192.168.245.129:22)..
Mon Nov 16 01:24:23 2015 - [debug]   ok.
Mon Nov 16 01:24:23 2015 - [debug]  Connecting via SSH from root@192.168.245.131(192.168.245.131:22) to root@192.168.245.132(192.168.245.132:22)..
Mon Nov 16 01:24:25 2015 - [debug]   ok.
Mon Nov 16 01:24:25 2015 - [debug] 
Mon Nov 16 01:24:22 2015 - [debug]  Connecting via SSH from root@192.168.245.132(192.168.245.132:22) to root@192.168.245.129(192.168.245.129:22)..
Mon Nov 16 01:24:24 2015 - [debug]   ok.
Mon Nov 16 01:24:24 2015 - [debug]  Connecting via SSH from root@192.168.245.132(192.168.245.132:22) to root@192.168.245.131(192.168.245.131:22)..
Mon Nov 16 01:24:25 2015 - [debug]   ok.
Mon Nov 16 01:24:25 2015 - [info] All SSH connection tests passed successfully.

View Code

若是遇到這個報錯：

Can't exec "mysqlbinlog": No such file or directory at /usr/share/perl5/vendor_perl/MHA/BinlogManager.pm line 106.
mysqlbinlog version command failed with rc 1:0, please verify PATH, LD_LIBRARY_PATH, and client options
 at /usr/bin/apply_diff_relay_logs line 493
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln205] Slaves settings check failed!
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln413] Slave configuration failed.
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations.  at /usr/bin/masterha_check_repl line 48
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Mon Nov 16 01:32:36 2015 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!

解決方法以下，添加軟鏈接（全部節點）

ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog

ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

到此爲止，都沒問題了，開始啓動manager節點進行監控，通常啓動咱們都使用nohup方式，可是當出現故障成功切換後，manager監控也會關閉，因此建議使用daemontools方式在後臺運行。

nohup方式啓動

nohup /usr/bin/masterha_manager --conf=/etc/masterha/app1.conf --remove_dead_master_conf --ignore_last_failover &
#關閉mha監控
/usr/bin/masterha_stop --conf=/etc/masterha/app1.conf

daemontools方式啓動：

#下載daemontools工具
wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
#安裝
cd /home/software/daemontools/admin/daemontools-0.76
vim src/conf-cc #在第一行最後空一格後添加 -include /usr/include/errno.h 避免編譯時報錯
package/install  #安裝
#在/etc/init/建立svscan.conf文件並添加以下內容：
vim /etc/init/svscan.conf
start on runlevel [345]
        respawn
        exec /command/svscanboot
#在/etc/init目錄下從新加載並啓動
[root@node3 init]# initctl reload-configuration
[root@node3 init]# initctl start svscan
svscan start/running, process 17002

使用daemon啓動mha監控：

[root@node3 init]# mkdir -p /service/masterha_app
[root@node3 ~]# cd /service/masterha_app/
[root@node3 masterha_app]# pwd
/service/masterha_app
#在/service/masterha_app/建立run腳本並增長執行權限，內容以下
[root@node3 masterha_app]# cat /service/masterha_app/run
#!/bin/bash
 exec /usr/bin/masterha_manager --conf=/etc/masterha/app1.conf --remove_dead_master_conf --ignore_last_failover
[root@node3 masterha_app]# chmod +x /service/masterha_app/run
#中止監控 
svc -d /service/masterha_app 
#開啓監控 
svc -u /service/masterha_app

另起一個session，查看啓動日誌：

[root@node3 app1]# tail -f app1.log 
192.168.245.129(192.168.245.129:3306) (current master)
 +--192.168.245.131(192.168.245.131:3306)
 +--192.168.245.132(192.168.245.132:3306)

Mon Nov 16 01:55:10 2015 - [warning] master_ip_failover_script is not defined.
Mon Nov 16 01:55:10 2015 - [warning] shutdown_script is not defined.
Mon Nov 16 01:55:10 2015 - [info] Set master ping interval 1 seconds.
Mon Nov 16 01:55:10 2015 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Mon Nov 16 01:55:10 2015 - [info] Starting ping health check on 192.168.245.129(192.168.245.129:3306)..
Mon Nov 16 01:55:10 2015 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..

當看到最後一句「Ping(SELECT) succeeded, waiting until MySQL doesn't respond..」表示mha已經啓動起來了。固然，你或許在一臺機子上但願監控多套master-salve複製，這很是容易，只要爲第二套集羣建立一個新的配置文件並啓動manager

1	`# masterha_manager` `--conf=/etc/conf/masterha/app1.cnf <br># masterha_manager --conf=/etc/conf/masterha/app2.cnf<br>若是你在app1和app2上有一些共有的參數，可在全局配置文件中配置。`

啓動參數介紹：

--remove_dead_master_conf 該參數表示當發生主從切換後，老的主庫的ip將會從配置文件中移除。若是故障機器修復好了，須要手工添加ip信息到配置文件中

--manger_log 日誌存放位置

--ignore_last_failover 在缺省狀況下，若是MHA檢測到連續發生宕機，且兩次宕機間隔不足8小時的話，則不會進行Failover，之因此這樣限制是爲了不ping-pong效應。該參數表明忽略上次MHA觸發切換產生的文件，默認狀況下，MHA發生切換後會在日誌目錄，也就是上面我設置的/data產生app1.failover.complete文件，下次再次切換的時候如果發現該目錄下存在該文件將不容許觸發切換，除非在第一次切換後收到刪除該文件，爲了方便，這裏設置爲--ignore_last_failover。

查看MHA Manager監控是否正常：

[root@node3 app1]#  /usr/bin/masterha_check_status --conf=/etc/masterha/app1.conf
app1 (pid:6795) is running(0:PING_OK), master:192.168.245.129

六、模擬測試

（1）自動Failover測試

首先用sysbench工具模擬主庫業務的寫入。

#下載sysbench
http://dev.mysql.com/downloads/benchmarks.html
#安裝sysbench
yum install libtool -y  #依賴包
tar zxvf sysbench-0.4.12.7.tar.gz
cd sysbench-0.4.12.7
./configure && make && make install

在主庫執行，建立sysbench測試表：

(product)root@127.0.0.1 [(none)]> create database sbtest;
Query OK, 1 row affected (0.00 sec)

[root@node1 sysbench-0.4.12.7]# /usr/local/bin/sysbench --test=oltp --oltp-table-size=100000 --oltp-read-only=off --init-rng=on --num-threads=4 --max-requests=0 --oltp-dist-type=uniform --max-time=1800 --mysql-user=root --mysql-socket=/tmp/mysql_3306.sock --mysql-password=root --mysql-host=192.168.245.129 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex prepare
sysbench 0.4.12.6:  multi-threaded system evaluation benchmark

Creating table 'sbtest'...
Creating 100000 records in table 'sbtest'...

中止接管主庫那個從庫的io_thread線程：

(product)root@127.0.0.1 [(none)]> stop slave io_thread;
Query OK, 0 rows affected (0.01 sec)

向主庫插入數據：

[root@node1 sysbench-0.4.12.7]# /usr/local/bin/sysbench --test=oltp --oltp-table-size=100000 --oltp-read-only=off --init-rng=on --num-threads=4 --max-requests=0 --oltp-dist-type=uniform --max-time=180 --mysql-user=root --mysql-socket=/tmp/mysql_3306.sock --mysql-password=root --mysql-host=192.168.245.129 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex run
sysbench 0.4.12.6:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Initializing random number generator from timer.

Random number generator seed is 0 and will be ignored


Doing OLTP test.
Running mixed OLTP test
Using Uniform distribution
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Using 1 test tables
Threads started!
Time limit exceeded, exiting...
(last message repeated 3 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            489090
        write:                           174675
        other:                           69870
        total:                           733635
    transactions:                        34935  (194.05 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 663765 (3686.93 per sec.)
    other operations:                    69870  (388.10 per sec.)

Test execution summary:
    total time:                          180.0317s
    total number of events:              34935
    total time taken by event execution: 719.7722
    per-request statistics:
         min:                                  3.47ms
         avg:                                 20.60ms
         max:                                444.43ms
         approx.  95 percentile:              28.17ms

Threads fairness:
    events (avg/stddev):           8733.7500/260.92
    execution time (avg/stddev):   179.9430/0.01

而後啓動從庫上io_thread:

(product)root@127.0.0.1 [(none)]> start slave io_thread;
Query OK, 0 rows affected, 1 warning (0.00 sec)

kill主庫的mysqld：

pkill -9 mysqld

最後，查看mha日誌，這時已經接管過來了！

View Code)

（2）修復故障master

一般狀況下自動切換之後，待原master主機修復後，若是數據完整的狀況下，可能想把原來master從新做爲新主庫的slave，這時咱們能夠藉助當時自動切換時刻的MHA日誌來完成對原master的修復。下面是提取相關日誌的命令：

[root@node3 masterha]#  grep -i "All other slaves should start" /var/log/masterha/app1/app1.log
Mon Nov 16 03:02:20 2015 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.245.131', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000013', MASTER_LOG_POS=35416929, MASTER_USER='repl', MASTER_PASSWORD='xxx';

將change master to拿到原master上執行，那麼就做爲新master的slave了。

（3）在線切換測試

在許多狀況下，須要將現有的主服務器遷移到另一臺服務器上。好比主服務器硬件故障，RAID 控制卡須要重建，將主服務器移到性能更好的服務器上等等。 MHA 提供快速切換和優雅的阻塞寫入，這個切換過程只須要 0.5-2s 的時間，這段時間內數據是沒法寫入的。在不少狀況下，0.5-2s 的阻塞寫入是能夠接受的。所以切換主服務器不須要計劃分配維護時間窗口。

MHA在線切換的大概過程：
1.檢測複製設置和肯定當前主服務器
2.肯定新的主服務器
3.阻塞寫入到當前主服務器
4.等待全部從服務器遇上覆制
5.授予寫入到新的主服務器
6.從新設置從服務器

注意，在線切換的時候應用架構須要考慮如下兩個問題：

1.自動識別master和slave的問題（master的機器可能會切換），若是採用了vip的方式，基本能夠解決這個問題。

2.負載均衡的問題（能夠定義大概的讀寫比例，每臺機器可承擔的負載比例，當有機器離開集羣時，須要考慮這個問題）

爲了保證數據徹底一致性，在最快的時間內完成切換，MHA的在線切換必須知足如下條件纔會切換成功，不然會切換失敗。

1.全部slave的IO線程都在運行

2.全部slave的SQL線程都在運行

3.全部的show slave status的輸出中Seconds_Behind_Master參數小於或者等於running_updates_limit秒，若是在切換過程當中不指定running_updates_limit,那麼默認狀況下running_updates_limit爲1秒。

4.在master端，經過show processlist輸出，沒有一個更新花費的時間大於running_updates_limit秒。

在線切換步驟以下：

首先，停掉MHA監控：

[root@node3 app1]# svc -d /service/masterha_app
[root@node3 app1]# checkstatus 
app1 is stopped(2:NOT_RUNNING).

其次，進行在線切換操做（模擬在線切換主庫操做，原主庫192.168.245.129變爲slave，192.168.245.131提高爲新的主庫）

[root@node3 masterha]# /usr/bin/masterha_master_switch --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.245.131 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000
Mon Nov 16 21:47:24 2015 - [info] MHA::MasterRotate version 0.56.
Mon Nov 16 21:47:24 2015 - [info] Starting online master switch..
Mon Nov 16 21:47:24 2015 - [info] 
Mon Nov 16 21:47:24 2015 - [info] * Phase 1: Configuration Check Phase..
Mon Nov 16 21:47:24 2015 - [info] 
Mon Nov 16 21:47:24 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Nov 16 21:47:24 2015 - [info] Reading application default configuration from /etc/masterha/app1.conf..
Mon Nov 16 21:47:24 2015 - [info] Reading server configuration from /etc/masterha/app1.conf..
Mon Nov 16 21:47:24 2015 - [info] GTID failover mode = 0
Mon Nov 16 21:47:24 2015 - [info] Current Alive Master: 192.168.245.129(192.168.245.129:3306)
Mon Nov 16 21:47:24 2015 - [info] Alive Slaves:
Mon Nov 16 21:47:24 2015 - [info]   192.168.245.132(192.168.245.132:3306)  Version=5.6.21-log (oldest major version between slaves) log-bin:enabled
Mon Nov 16 21:47:24 2015 - [info]     Replicating from 192.168.245.129(192.168.245.129:3306)

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.245.129(192.168.245.129:3306)? (YES/no): yes
Mon Nov 16 21:47:35 2015 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Mon Nov 16 21:47:35 2015 - [info]  ok.
Mon Nov 16 21:47:35 2015 - [info] Checking MHA is not monitoring or doing failover..
Mon Nov 16 21:47:35 2015 - [info] Checking replication health on 192.168.245.132..
Mon Nov 16 21:47:35 2015 - [info]  ok.
Mon Nov 16 21:47:35 2015 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln1218] 192.168.245.131 is not alive!
Mon Nov 16 21:47:35 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm, ln232] Failed to get new master!
Mon Nov 16 21:47:35 2015 - [error][/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm, ln177] Got ERROR:  at /usr/bin/masterha_master_switch line 53

這裏怎麼會報錯呢？意思是131這個機器not alive，但是我去檢查下沒有問題啊，主從也ok的，後來發現了問題所在，緣由是：以前啓動的manager腳本中加上了--remove_dead_master_conf參數，致使appl.conf中沒有131機器的配置。

而後到app1.conf中加上131機器的配置信息，再次執行：

View Code

其中參數的意思：

--orig_master_is_new_slave 切換時加上此參數是將原 master 變爲 slave 節點，若是不加此參數，原來的 master 將不啓動

--running_updates_limit=10000,故障切換時,候選master 若是有延遲的話， mha 切換不能成功，加上此參數表示延遲在此時間範圍內均可切換（單位爲s），可是切換的時間長短是由recover 時relay 日誌的大小決定

（4）切換時發送郵件：

須要建立一個send_mail腳本，而後將腳本路徑寫入app1.conf中便可。

View Code

至此，mysql mha部分就搞定了，下面將會結合mha這個架構加入代理層，從而實現讀寫分離功能，主要採用360公司的Atlas，敬請期待。。。