MySQL之MHA分享

本文主要給大家介紹MySQL之MHA分享，其所涉及的東西，從理論知識來獲悉，有很多書籍、文獻可供大家參考，從現(xiàn)實意義角度出發(fā)，億速云累計多年的實踐經(jīng)驗可分享給大家。

簡介：

MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現(xiàn)就職于Facebook公司）開發(fā)，是一套優(yōu)秀的作為MySQL高可用性環(huán)境下故障切換和主從提升的高可用軟件。在MySQL故障切換過程中，MHA能做到在0~30秒之內(nèi)自動完成數(shù)據(jù)庫的故障切換操作，并且在進行故障切換的過程中，MHA能在最大程度上保證數(shù)據(jù)的一致性，以達到真正意義上的高可用。

該軟件由兩部分組成：MHA Manager（管理節(jié)點）和MHA Node（數(shù)據(jù)節(jié)點）。MHA Manager可以單獨部署在一臺獨立的機器上管理多個master-slave集群，也可以部署在一臺slave節(jié)點上。MHA Node運行在每臺MySQL云服務器上，MHA Manager會定時探測集群中的master節(jié)點，當master出現(xiàn)故障時，它可以自動將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master。整個故障轉移過程對應用程序完全透明。

在MHA自動故障切換過程中，MHA試圖從宕機的主服務器上保存二進制日志，最大程度的保證數(shù)據(jù)的不丟失，但這并不總是可行的。例如，如果主服務器硬件故障或無法通過ssh訪問，MHA沒法保存二進制日志，只進行故障轉移而丟失了最新的數(shù)據(jù)。使用MySQL 5.5的半同步復制，可以大大降低數(shù)據(jù)丟失的風險。MHA可以與半同步復制結合起來。如果只有一個slave已經(jīng)收到了最新的二進制日志，MHA可以將最新的二進制日志應用于其他所有的slave服務器上，因此可以保證所有節(jié)點的數(shù)據(jù)一致性。

目前MHA主要支持一主多從的架構，要搭建MHA,要求一個復制集群中必須最少有三臺數(shù)據(jù)庫服務器，一主二從，即一臺充當master，一臺充當備用master，另外一臺充當從庫，因為至少需要三臺服務器，出于機器成本的考慮，淘寶也在該基礎上進行了改造，目前淘寶TMHA已經(jīng)支持一主一從。另外對于想快速搭建的可以參考：MHA快速搭建

我們自己使用其實也可以使用1主1從，但是master主機宕機后無法切換，以及無法補全binlog。master的mysqld進程crash后，還是可以切換成功，以及補全binlog的。

官方介紹：https://code.google.com/p/mysql-master-ha/

圖01展示了如何通過MHA Manager管理多組主從復制?？梢詫HA工作原理總結為如下：

                                 （ 圖01 ）

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

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

（3）應用差異的中繼日志（relay log）到其他的slave；

（4）應用從master保存的二進制日志事件（binlog events）；

（5）提升一個slave為新的master；

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

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

Manager工具包主要包括以下幾個工具：

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

Node工具包（這些工具通常由MHA Manager的腳本觸發(fā)，無需人為操作）主要包括以下幾個工具：

save_binary_logs                保存和復制master的二進制日志
apply_diff_relay_logs           識別差異的中繼日志事件并將其差異的事件應用于其他的slave
filter_mysqlbinlog              去除不必要的ROLLBACK事件（MHA已不再使用這個工具）
purge_relay_logs                清除中繼日志（不會阻塞SQL線程）

注意：

為了盡可能的減少主庫硬件損壞宕機造成的數(shù)據(jù)丟失，因此在配置MHA的同時建議配置成MySQL 5.5的半同步復制。關于半同步復制原理各位自己進行查閱。（不是必須）

1.部署MHA

接下來部署MHA，具體的搭建環(huán)境如下（所有操作系統(tǒng)均為centos 6.2 64bit，不是必須，server03和server04是server02的從，復制環(huán)境搭建后面會簡單演示，但是相關的安全復制不會詳細說明，需要的童鞋請參考前面的文章，MySQL Replication需要注意的問題）：

角色                    ip地址          主機名          server_id                  類型
Monitor host            192.168.0.20    server01            -                      監(jiān)控復制組
Master                  192.168.0.50    server02            1                      寫入
Candicate master        192.168.0.60    server03            2                      讀
Slave                   192.168.0.70    server04            3                      讀

其中master對外提供寫服務，備選master（實際的slave，主機名server03）提供讀服務，slave也提供相關的讀服務，一旦master宕機，將會把備選master提升為新的master，slave指向新的master

（1）在所有節(jié)點安裝MHA node所需的perl模塊（DBD:mysql），安裝腳本如下：

[root@192.168.0.50 ~]# cat install.sh #!/bin/bashwget http://xrl.us/cpanm --no-check-certificatemv cpanm /usr/binchmod 755 /usr/bin/cpanmcat > /root/list << EOFinstall DBD::mysql
EOFfor package in `cat /root/list`do
    cpanm $packagedone[root@192.168.0.50 ~]#

如果有安裝epel源，也可以使用yum安裝

yum install perl-DBD-MySQL -y

（2）在所有的節(jié)點安裝mha node：

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

安裝完成后會在/usr/local/bin目錄下生成以下腳本文件：

[root@192.168.0.50 bin]# pwd/usr/local/bin
[root@192.168.0.50 bin]# ll
total 40-r-xr-xr-x 1 root root 15498 Apr 20 10:05 apply_diff_relay_logs-r-xr-xr-x 1 root root  4807 Apr 20 10:05 filter_mysqlbinlog-r-xr-xr-x 1 root root  7401 Apr 20 10:05 purge_relay_logs-r-xr-xr-x 1 root root  7263 Apr 20 10:05 save_binary_logs
[root@192.168.0.50 bin]#

關于上面腳本的功能，上面已經(jīng)介紹過了，這里不再重復了。

2.安裝MHA Manager

MHA Manager中主要包括了幾個管理員的命令行工具，例如master_manger，master_master_switch等。MHA Manger也依賴于perl模塊，具體如下：

（1）安裝MHA Node軟件包之前需要安裝依賴。我這里使用yum完成，沒有epel源的可以使用上面提到的腳本（epel源安裝也簡單）。注意：在MHA Manager的主機也是需要安裝MHA Node。

rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

yum install perl-DBD-MySQL -y

安裝MHA Node軟件包，和上面的方法一樣，如下：

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

（2）安裝MHA Manager。首先安裝MHA Manger依賴的perl模塊（我這里使用yum安裝）：

yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y

安裝MHA Manager軟件包：

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

安裝完成后會在/usr/local/bin目錄下面生成以下腳本文件，前面已經(jīng)說過這些腳本的作用，這里不再重復

[root@192.168.0.20 bin]# pwd/usr/local/bin
[root@192.168.0.20 bin]# ll
total 76-r-xr-xr-x 1 root root 15498 Apr 20 10:58 apply_diff_relay_logs-r-xr-xr-x 1 root root  4807 Apr 20 10:58 filter_mysqlbinlog-r-xr-xr-x 1 root root  1995 Apr 20 11:33 masterha_check_repl-r-xr-xr-x 1 root root  1779 Apr 20 11:33 masterha_check_ssh-r-xr-xr-x 1 root root  1865 Apr 20 11:33 masterha_check_status-r-xr-xr-x 1 root root  3201 Apr 20 11:33 masterha_conf_host-r-xr-xr-x 1 root root  2517 Apr 20 11:33 masterha_manager-r-xr-xr-x 1 root root  2165 Apr 20 11:33 masterha_master_monitor-r-xr-xr-x 1 root root  2373 Apr 20 11:33 masterha_master_switch-r-xr-xr-x 1 root root  3749 Apr 20 11:33 masterha_secondary_check-r-xr-xr-x 1 root root  1739 Apr 20 11:33 masterha_stop-r-xr-xr-x 1 root root  7401 Apr 20 10:58 purge_relay_logs-r-xr-xr-x 1 root root  7263 Apr 20 10:58 save_binary_logs
[root@192.168.0.20 bin]#

復制相關腳本到/usr/local/bin目錄(軟件包解壓縮后就有了，不是必須，因為這些腳本不完整，需要自己修改，這是軟件開發(fā)著留給我們自己發(fā)揮的,如果開啟下面的任何一個腳本對應的參數(shù)，而對應這里的腳本又沒有修改，則會拋錯，自己被坑的很慘)

[root@192.168.0.20 scripts]# pwd/root/mha4mysql-manager-0.53/samples/scripts
[root@192.168.0.20 scripts]# ll
total 32-rwxr-xr-x 1 root root  3443 Jan  8  2012 master_ip_failover                #自動切換時vip管理的腳本，不是必須，如果我們使用keepalived的，我們可以自己編寫腳本完成對vip的管理，比如監(jiān)控mysql，如果mysql異常，我們停止keepalived就行，這樣vip就會自動漂移-rwxr-xr-x 1 root root  9186 Jan  8  2012 master_ip_online_change           #在線切換時vip的管理，不是必須，同樣可以可以自行編寫簡單的shell完成-rwxr-xr-x 1 root root 11867 Jan  8  2012 power_manager                     #故障發(fā)生后關閉主機的腳本，不是必須-rwxr-xr-x 1 root root  1360 Jan  8  2012 send_report                       #因故障切換后發(fā)送報警的腳本，不是必須，可自行編寫簡單的shell完成。
[root@192.168.0.20 scripts]# cp * /usr/local/bin/[root@192.168.0.20 scripts]#

3.配置SSH登錄無密碼驗證（使用key登錄，工作中常用）我的測試環(huán)境已經(jīng)是使用key登錄，服務器之間無需密碼驗證的。關于配置使用key登錄，我想我不再重復。但是有一點需要注意：不能禁止 password 登陸，否則會出現(xiàn)錯誤

4.搭建主從復制環(huán)境

注意：binlog-do-db 和 replicate-ignore-db 設置必須相同。 MHA 在啟動時候會檢測過濾規(guī)則，如果過濾規(guī)則不同，MHA 不啟動監(jiān)控和故障轉移。

（1）在server02上執(zhí)行備份（192.168.0.50）

[root@192.168.0.50 ~]# mysqldump --master-data=2 --single-transaction -R --triggers -A > all.sql

其中--master-data=2代表備份時刻記錄master的Binlog位置和Position，--single-transaction意思是獲取一致性快照，-R意思是備份存儲過程和函數(shù)，--triggres的意思是備份觸發(fā)器，-A代表備份所有的庫。更多信息請自行mysqldump --help查看。

（2）在server02上創(chuàng)建復制用戶：

mysql> grant replication slave on *.* to 'repl'@'192.168.0.%' identified by '123456';
Query OK, 0 rows affected (0.00 sec)

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

mysql>

（3）查看主庫備份時的binlog名稱和位置，MASTER_LOG_FILE和MASTER_LOG_POS：

[root@192.168.0.50 ~]# head -n 30 all.sql | grep 'CHANGE MASTER TO'-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000010', MASTER_LOG_POS=112;
[root@192.168.0.50 ~]#

（4）把備份復制到server03和server04，也就是192.168.0.60和192.168.0.70

scp all.sql server03:/data/scp all.sql server04:/data/

（5）導入備份到server03，執(zhí)行復制相關命令

mysql < /data/all.sql

mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.50',MASTER_USER='repl', MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000010',MASTER_LOG_POS=112;
Query OK, 0 rows affected (0.02 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

mysql>

查看復制狀態(tài)（可以看見復制成功）：

[root@192.168.0.60 ~]# mysql -e 'show slave status\G' | egrep 'Slave_IO|Slave_SQL'
               Slave_IO_State: Waiting for master to send event
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
[root@192.168.0.60 ~]#

（6）在server04（192.168.0.70）上搭建復制環(huán)境，操作和上面一樣。

mysql < /data/all.sql

mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.50',MASTER_USER='repl', MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000010',MASTER_LOG_POS=112;
Query OK, 0 rows affected (0.07 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql>

查看復制狀態(tài)：

[root@192.168.0.70 ~]# mysql -e 'show slave status\G' | egrep 'Slave_IO|Slave_SQL'
               Slave_IO_State: Waiting for master to send event
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
[root@192.168.0.70 ~]#

（7）兩臺slave服務器設置read_only（從庫對外提供讀服務，只所以沒有寫進配置文件，是因為隨時slave會提升為master）

[root@192.168.0.60 ~]# mysql -e 'set global read_only=1'[root@192.168.0.60 ~]#

[root@192.168.0.70 ~]# mysql -e 'set global read_only=1'[root@192.168.0.70 ~]#

（8）創(chuàng)建監(jiān)控用戶（在master上執(zhí)行，也就是192.168.0.50）：

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

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

mysql>

到這里整個集群環(huán)境已經(jīng)搭建完畢，剩下的就是配置MHA軟件了。

5.配置MHA

（1）創(chuàng)建MHA的工作目錄，并且創(chuàng)建相關配置文件（在軟件包解壓后的目錄里面有樣例配置文件）。

[root@192.168.0.20 ~]# mkdir -p /etc/masterha
[root@192.168.0.20 ~]# cp mha4mysql-manager-0.53/samples/conf/app1.cnf /etc/masterha/[root@192.168.0.20 ~]#

修改app1.cnf配置文件，修改后的文件內(nèi)容如下（注意，配置文件中的注釋需要去掉，我這里是為了解釋清楚）：

[root@. ~]#  /etc/masterha/=/var/log/masterha/app1.log              manager_log=/var/log/masterha/app1/manager.log          master_binlog_dir=/data/mysql                         master_ip_failover_script= /usr/local/bin/master_ip_failover    master_ip_online_change_script= /usr/local/bin/master_ip_online_change  password=         user==         remote_workdir=/tmp     repl_password=    repl_user=repl          report_script=/usr/local/send_report    secondary_check_script= /usr/local/bin/masterha_secondary_check -s server03 -s server02            
shutdown_script=      ssh_user=root           =.==.==   check_repl_delay=   =.=. ~]#

（2）設置relay log的清除方式（在每個slave節(jié)點上）：

[root@192.168.0.60 ~]# mysql -e 'set global relay_log_purge=0'[root@192.168.0.70 ~]# mysql -e 'set global relay_log_purge=0'

注意：

MHA在發(fā)生切換的過程中，從庫的恢復過程中依賴于relay log的相關信息，所以這里要將relay log的自動清除設置為OFF，采用手動清除relay log的方式。在默認情況下，從服務器上的中繼日志會在SQL線程執(zhí)行完畢后被自動刪除。但是在MHA環(huán)境中，這些中繼日志在恢復其他從服務器時可能會被用到，因此需要禁用中繼日志的自動刪除功能。定期清除中繼日志需要考慮到復制延時的問題。在ext3的文件系統(tǒng)下，刪除大的文件需要一定的時間，會導致嚴重的復制延時。為了避免復制延時，需要暫時為中繼日志創(chuàng)建硬鏈接，因為在linux系統(tǒng)中通過硬鏈接刪除大文件速度會很快。（在mysql數(shù)據(jù)庫中，刪除大表時，通常也采用建立硬鏈接的方式）

MHA節(jié)點中包含了pure_relay_logs命令工具，它可以為中繼日志創(chuàng)建硬鏈接，執(zhí)行SET GLOBAL relay_log_purge=1,等待幾秒鐘以便SQL線程切換到新的中繼日志，再執(zhí)行SET GLOBAL relay_log_purge=0。

pure_relay_logs腳本參數(shù)如下所示：

--user mysql                      用戶名--password mysql                  密碼--port                            端口號--workdir                         指定創(chuàng)建relay log的硬鏈接的位置，默認是/var/tmp，由于系統(tǒng)不同分區(qū)創(chuàng)建硬鏈接文件會失敗，故需要執(zhí)行硬鏈接具體位置，成功執(zhí)行腳本后，硬鏈接的中繼日志文件被刪除--disable_relay_log_purge         默認情況下，如果relay_log_purge=1，腳本會什么都不清理，自動退出，通過設定這個參數(shù)，當relay_log_purge=1的情況下會將relay_log_purge設置為0。清理relay log之后，最后將參數(shù)設置為OFF。

（3）設置定期清理relay腳本（兩臺slave服務器）

[root@192.168.0.60 ~]# cat purge_relay_log.sh #!/bin/bash
user=rootpasswd=123456port=3306log_dir='/data/masterha/log'work_dir='/data'purge='/usr/local/bin/purge_relay_logs'if [ ! -d $log_dir ]then
   mkdir $log_dir -pfi$purge --user=$user --password=$passwd --disable_relay_log_purge --port=$port --workdir=$work_dir >> $log_dir/purge_relay_logs.log 2>&1[root@192.168.0.60 ~]#

添加到crontab定期執(zhí)行

[root@192.168.0.60 ~]# crontab -l0 4 * * * /bin/bash /root/purge_relay_log.sh[root@192.168.0.60 ~]#

purge_relay_logs腳本刪除中繼日志不會阻塞SQL線程。下面我們手動執(zhí)行看看什么情況。

[root@192.168.0.60 ~]# purge_relay_logs --user=root --password=123456 --port=3306 -disable_relay_log_purge --workdir=/data/2014-04-20 15:47:24: purge_relay_logs script started.
 Found relay_log.info: /data/mysql/relay-log.info
 Removing hard linked relay log files server03-relay-bin* under /data/.. done.
 Current relay log file: /data/mysql/server03-relay-bin.000002
 Archiving unused relay log files (up to /data/mysql/server03-relay-bin.000001) ...
 Creating hard link for /data/mysql/server03-relay-bin.000001 under /data//server03-relay-bin.000001 .. ok.
 Creating hard links for unused relay log files completed.
 Executing SET GLOBAL relay_log_purge=1; FLUSH LOGS; sleeping a few seconds so that SQL thread can delete older relay log files (if it keeps up); SET GLOBAL relay_log_purge=0; .. ok.
 Removing hard linked relay log files server03-relay-bin* under /data/.. done.2014-04-20 15:47:27: All relay log purging operations succeeded.
[root@192.168.0.60 ~]#

6.檢查SSH配置

檢查MHA Manger到所有MHA Node的SSH連接狀態(tài)：

[root@192.168.0.20 ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf 
Sun Apr 20 17:17:39 2014 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Sun Apr 20 17:17:39 2014 - [info] Reading application default configurations from /etc/masterha/app1.cnf..
Sun Apr 20 17:17:39 2014 - [info] Reading server configurations from /etc/masterha/app1.cnf..
Sun Apr 20 17:17:39 2014 - [info] Starting SSH connection tests..
Sun Apr 20 17:17:40 2014 - [debug] 
Sun Apr 20 17:17:39 2014 - [debug]  Connecting via SSH from root@192.168.0.50(192.168.0.50:22) to root@192.168.0.60(192.168.0.60:22)..
Sun Apr 20 17:17:39 2014 - [debug]   ok.
Sun Apr 20 17:17:39 2014 - [debug]  Connecting via SSH from root@192.168.0.50(192.168.0.50:22) to root@192.168.0.70(192.168.0.70:22)..
Sun Apr 20 17:17:39 2014 - [debug]   ok.
Sun Apr 20 17:17:40 2014 - [debug] 
Sun Apr 20 17:17:40 2014 - [debug]  Connecting via SSH from root@192.168.0.60(192.168.0.60:22) to root@192.168.0.50(192.168.0.50:22)..
Sun Apr 20 17:17:40 2014 - [debug]   ok.
Sun Apr 20 17:17:40 2014 - [debug]  Connecting via SSH from root@192.168.0.60(192.168.0.60:22) to root@192.168.0.70(192.168.0.70:22)..
Sun Apr 20 17:17:40 2014 - [debug]   ok.
Sun Apr 20 17:17:41 2014 - [debug] 
Sun Apr 20 17:17:40 2014 - [debug]  Connecting via SSH from root@192.168.0.70(192.168.0.70:22) to root@192.168.0.50(192.168.0.50:22)..
Sun Apr 20 17:17:40 2014 - [debug]   ok.
Sun Apr 20 17:17:40 2014 - [debug]  Connecting via SSH from root@192.168.0.70(192.168.0.70:22) to root@192.168.0.60(192.168.0.60:22)..
Sun Apr 20 17:17:41 2014 - [debug]   ok.
Sun Apr 20 17:17:41 2014 - [info] All SSH connection tests passed successfully.

可以看見各個節(jié)點ssh驗證都是ok的。

7.檢查整個復制環(huán)境狀況。

通過masterha_check_repl腳本查看整個集群的狀態(tài)

[root@192.168.0.20 ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf
Sun Apr 20 18:36:55 2014 - [info] Checking replication health on 192.168.0.60..
Sun Apr 20 18:36:55 2014 - [info]  ok.
Sun Apr 20 18:36:55 2014 - [info] Checking replication health on 192.168.0.70..
Sun Apr 20 18:36:55 2014 - [info]  ok.
Sun Apr 20 18:36:55 2014 - [info] Checking master_ip_failover_script status:
Sun Apr 20 18:36:55 2014 - [info]   /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.0.50 --orig_master_ip=192.168.0.50 --orig_master_port=3306 Bareword "FIXME_xxx" not allowed while "strict subs" in use at /usr/local/bin/master_ip_failover line 88.
Execution of /usr/local/bin/master_ip_failover aborted due to compilation errors.
Sun Apr 20 18:36:55 2014 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln214]  Failed to get master_ip_failover_script status with return code 255:0.
Sun Apr 20 18:36:55 2014 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln383] Error happend on checking configurations.  at /usr/local/bin/masterha_check_repl line 48Sun Apr 20 18:36:55 2014 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln478] Error happened on monitoring servers.
Sun Apr 20 18:36:55 2014 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!

發(fā)現(xiàn)最后的結論說我的復制不是ok的。但是上面的信息明明說是正常的，自己也進數(shù)據(jù)庫查看了。這里一直踩坑。一直糾結，后來無意中發(fā)現(xiàn)火丁筆記的博客，這才知道了原因，原來Failover兩種方式：一種是虛擬IP地址，一種是全局配置文件。MHA并沒有限定使用哪一種方式，而是讓用戶自己選擇，虛擬IP地址的方式會牽扯到其它的軟件,比如keepalive軟件，而且還要修改腳本master_ip_failover。(最后修改腳本后才沒有這個報錯，自己不懂perl也是折騰的半死，去年買了塊表)

如果發(fā)現(xiàn)如下錯誤：

Can't exec "mysqlbinlog": No such file or directory at /usr/local/share/perl5/MHA/BinlogManager.pm line 99.mysqlbinlog version not found!

Testing mysql connection and privileges..sh: mysql: command not found

解決方法如下，添加軟連接（所有節(jié)點）

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

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

所以先暫時注釋master_ip_failover_script= /usr/local/bin/master_ip_failover這個選項。后面引入keepalived后和修改該腳本以后再開啟該選項。

[root@192.168.0.20 ~]# grep master_ip_failover /etc/masterha/app1.cnf
#master_ip_failover_script= /usr/local/bin/master_ip_failover
[root@192.168.0.20 ~]#

再次進行狀態(tài)查看：

Sun Apr 20 18:46:08 2014 - [info] Checking replication health on 192.168.0.60..
Sun Apr 20 18:46:08 2014 - [info]  ok.
Sun Apr 20 18:46:08 2014 - [info] Checking replication health on 192.168.0.70..
Sun Apr 20 18:46:08 2014 - [info]  ok.
Sun Apr 20 18:46:08 2014 - [warning] master_ip_failover_script is not defined.
Sun Apr 20 18:46:08 2014 - [warning] shutdown_script is not defined.
Sun Apr 20 18:46:08 2014 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

已經(jīng)沒有明顯報錯，只有兩個警告而已，復制也顯示正常了。
8.檢查MHA Manager的狀態(tài)：

通過master_check_status腳本查看Manager的狀態(tài)：

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

注意：如果正常，會顯示"PING_OK"，否則會顯示"NOT_RUNNING"，這代表MHA監(jiān)控沒有開啟。
9.開啟MHA Manager監(jiān)控

[root@192.168.0.20 ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &  [1] 30867[root@192.168.0.20 ~]#

啟動參數(shù)介紹：

--remove_dead_master_conf      該參數(shù)代表當發(fā)生主從切換后，老的主庫的ip將會從配置文件中移除。

--manger_log                            日志存放位置

--ignore_last_failover                 在缺省情況下，如果MHA檢測到連續(xù)發(fā)生宕機，且兩次宕機間隔不足8小時的話，則不會進行Failover，之所以這樣限制是為了避免ping-pong效應。該參數(shù)代表忽略上次MHA觸發(fā)切換產(chǎn)生的文件，默認情況下，MHA發(fā)生切換后會在日志目錄，也就是上面我設置的/data產(chǎn)生app1.failover.complete文件，下次再次切換的時候如果發(fā)現(xiàn)該目錄下存在該文件將不允許觸發(fā)切換，除非在第一次切換后收到刪除該文件，為了方便，這里設置為--ignore_last_failover。

查看MHA Manager監(jiān)控是否正常：

[root@192.168.0.20 ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:20386) is running(0:PING_OK), master:192.168.0.50[root@192.168.0.20 ~]#

可以看見已經(jīng)在監(jiān)控了，而且master的主機為192.168.0.50

10.查看啟動日志

[root@192.168.0.20 ~]# tail -n20 /var/log/masterha/app1/manager.logSun Apr 20 19:12:01 2014 - [info]   Connecting to root@192.168.0.70(192.168.0.70:22).. 
  Checking slave recovery environment settings..
    Opening /data/mysql/relay-log.info ... ok.
    Relay log found at /data/mysql, up to server04-relay-bin.000002
    Temporary relay log file is /data/mysql/server04-relay-bin.000002
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Sun Apr 20 19:12:01 2014 - [info] Slaves settings check done.
Sun Apr 20 19:12:01 2014 - [info] 
192.168.0.50 (current master) +--192.168.0.60
 +--192.168.0.70Sun Apr 20 19:12:01 2014 - [warning] master_ip_failover_script is not defined.
Sun Apr 20 19:12:01 2014 - [warning] shutdown_script is not defined.
Sun Apr 20 19:12:01 2014 - [info] Set master ping interval 1 seconds.
Sun Apr 20 19:12:01 2014 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s server03 -s server02 --user=root --master_host=server02 --master_ip=192.168.0.50 --master_port=3306Sun Apr 20 19:12:01 2014 - [info] Starting ping health check on 192.168.0.50(192.168.0.50:3306)..
Sun Apr 20 19:12:01 2014 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..[root@192.168.0.20 ~]#

其中"Ping(SELECT) succeeded, waiting until MySQL doesn't respond.."說明整個系統(tǒng)已經(jīng)開始監(jiān)控了。
11.關閉MHA Manage監(jiān)控

關閉很簡單，使用masterha_stop命令完成。

[root@192.168.0.20 ~]# masterha_stop --conf=/etc/masterha/app1.cnf
Stopped app1 successfully.
[1]+  Exit 1                  nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover --manager_log=/data/mamanager.log
[root@192.168.0.20 ~]#

12.配置VIP
vip配置可以采用兩種方式，一種通過keepalived的方式管理虛擬ip的浮動；另外一種通過腳本方式啟動虛擬ip的方式（即不需要keepalived或者heartbeat類似的軟件）。

1.keepalived方式管理虛擬ip，keepalived配置方法如下：

（1）下載軟件進行并進行安裝（兩臺master，準確的說一臺是master，另外一臺是備選master，在沒有切換以前是slave）：

[root@192.168.0.50 ~]# wget http://www.keepalived.org/software/keepalived-1.2.12.tar.gz

tar xf keepalived-1.2.12.tar.gz           
cd keepalived-1.2.12./configure --prefix=/usr/local/keepalivedmake &&  make installcp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/mkdir /etc/keepalivedcp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/cp /usr/local/keepalived/sbin/keepalived /usr/sbin/

（2）配置keepalived的配置文件，在master上配置（192.168.0.50）

[root@192.168.0.50 ~]# cat /etc/keepalived/keepalived.conf! Configuration File for keepalived

global_defs {
     notification_email {
     saltstack@163.com
   }
   notification_email_from dba@dbserver.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id MySQL-HA
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth2
    virtual_router_id 51
    priority 150
    advert_int 1
    nopreempt

    authentication {
    auth_type PASS
    auth_pass 1111
    }

    virtual_ipaddress {        192.168.0.88
    }
}

[root@192.168.0.50 ~]#

其中router_id MySQL HA表示設定keepalived組的名稱，將192.168.0.88這個虛擬ip綁定到該主機的eth2網(wǎng)卡上，并且設置了狀態(tài)為backup模式，將keepalived的模式設置為非搶占模式（nopreempt），priority 150表示設置的優(yōu)先級為150。下面的配置略有不同，但是都是一個意思。
在候選master上配置（192.168.0.60）

[root@192.168.0.60 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
     notification_email {
     saltstack@163.com
   }
   notification_email_from dba@dbserver.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id MySQL-HA
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth2
    virtual_router_id 51
    priority 120
    advert_int 1
    nopreempt

    authentication {
    auth_type PASS
    auth_pass 1111
    }

    virtual_ipaddress {        192.168.0.88
    }
}

[root@192.168.0.60 ~]#

（3）啟動keepalived服務，在master上啟動并查看日志

[root@192.168.0.50 ~]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@192.168.0.50 ~]# tail -f /var/log/messages
Apr 20 20:22:16 192 Keepalived_healthcheckers[15334]: Opening file '/etc/keepalived/keepalived.conf'.
Apr 20 20:22:16 192 Keepalived_healthcheckers[15334]: Configuration is using : 7231 Bytes
Apr 20 20:22:16 192 kernel: IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
Apr 20 20:22:16 192 kernel: IPVS: ipvs loaded.
Apr 20 20:22:16 192 Keepalived_healthcheckers[15334]: Using LinkWatch kernel netlink reflector...
Apr 20 20:22:19 192 Keepalived_vrrp[15335]: VRRP_Instance(VI_1) Transition to MASTER STATE
Apr 20 20:22:20 192 Keepalived_vrrp[15335]: VRRP_Instance(VI_1) Entering MASTER STATE
Apr 20 20:22:20 192 Keepalived_vrrp[15335]: VRRP_Instance(VI_1) setting protocol VIPs.
Apr 20 20:22:20 192 Keepalived_vrrp[15335]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth2 for 192.168.0.88Apr 20 20:22:20 192 Keepalived_healthcheckers[15334]: Netlink reflector reports IP 192.168.0.88 added
Apr 20 20:22:25 192 Keepalived_vrrp[15335]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth2 for 192.168.0.88

發(fā)現(xiàn)已經(jīng)將虛擬ip 192.168.0.88綁定了網(wǎng)卡eth2上。
（4）查看綁定情況

[root@192.168.0.50 ~]# ip addr | grep eth23: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.0.50/24 brd 192.168.0.255 scope global eth2
    inet 192.168.0.88/32 scope global eth2
[root@192.168.0.50 ~]#

在另外一臺服務器，候選master上啟動keepalived服務，并觀察

[root@192.168.0.60 ~]# /etc/init.d/keepalived start ; tail -f /var/log/messages
Starting keepalived:                                       [  OK  ]
Apr 20 20:26:18 192 Keepalived_vrrp[9472]: Registering gratuitous ARP shared channel
Apr 20 20:26:18 192 Keepalived_vrrp[9472]: Opening file '/etc/keepalived/keepalived.conf'.
Apr 20 20:26:18 192 Keepalived_vrrp[9472]: Configuration is using : 62976 Bytes
Apr 20 20:26:18 192 Keepalived_vrrp[9472]: Using LinkWatch kernel netlink reflector...
Apr 20 20:26:18 192 Keepalived_vrrp[9472]: VRRP_Instance(VI_1) Entering BACKUP STATEApr 20 20:26:18 192 Keepalived_vrrp[9472]: VRRP sockpool: [ifindex(3), proto(112), unicast(0), fd(10,11)]
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Netlink reflector reports IP 192.168.80.138 added
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Netlink reflector reports IP 192.168.0.60 added
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Netlink reflector reports IP fe80::20c:29ff:fe9d:6a9e added
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Netlink reflector reports IP fe80::20c:29ff:fe9d:6aa8 added
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Registering Kernel netlink reflector
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Registering Kernel netlink command channel
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Opening file '/etc/keepalived/keepalived.conf'.
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Configuration is using : 7231 Bytes
Apr 20 20:26:18 192 kernel: IPVS: Registered protocols (TCP, UDP, AH, ESP)
Apr 20 20:26:18 192 kernel: IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
Apr 20 20:26:18 192 kernel: IPVS: ipvs loaded.
Apr 20 20:26:18 192 Keepalived_healthcheckers[9471]: Using LinkWatch kernel netlink reflector...

從上面的信息可以看到keepalived已經(jīng)配置成功。
注意：

上面兩臺服務器的keepalived都設置為了BACKUP模式，在keepalived中2種模式，分別是master->backup模式和backup->backup模式。這兩種模式有很大區(qū)別。在master->backup模式下，一旦主庫宕機，虛擬ip會自動漂移到從庫，當主庫修復后，keepalived啟動后，還會把虛擬ip搶占過來，即使設置了非搶占模式（nopreempt）搶占ip的動作也會發(fā)生。在backup->backup模式下，當主庫宕機后虛擬ip會自動漂移到從庫上，當原主庫恢復和keepalived服務啟動后，并不會搶占新主的虛擬ip，即使是優(yōu)先級高于從庫的優(yōu)先級別，也不會發(fā)生搶占。為了減少ip漂移次數(shù)，通常是把修復好的主庫當做新的備庫。

（5）MHA引入keepalived（MySQL服務進程掛掉時通過MHA 停止keepalived）:

要想把keepalived服務引入MHA，我們只需要修改切換是觸發(fā)的腳本文件master_ip_failover即可，在該腳本中添加在master發(fā)生宕機時對keepalived的處理。

編輯腳本/usr/local/bin/master_ip_failover，修改后如下，我對perl不熟悉，所以我這里完整貼出該腳本（主庫上操作，192.168.0.50）。

在MHA Manager修改腳本修改后的內(nèi)容如下（參考資料比較少）：

 warnings FATAL =>  Getopt::,          ,        , ,    , , ,      =   =   =           => \,             => \,     => \,       => \,     => \,      => \,        => \,      => \, &  (  eq  ||  eq   =  & =     (  eq   =  & =    (  eq  
         & \@ \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

現(xiàn)在已經(jīng)修改這個腳本了，我們現(xiàn)在打開在上面提到過的參數(shù)，再檢查集群狀態(tài)，看是否會報錯。

[root@192.168.0.20 ~]# grep 'master_ip_failover_script' /etc/masterha/app1.cnf
master_ip_failover_script= /usr/local/bin/master_ip_failover
[root@192.168.0.20 ~]#

[root@192.168.0.20 ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf  
Sun Apr 20 23:10:01 2014 - [info] Slaves settings check done.
Sun Apr 20 23:10:01 2014 - [info] 
192.168.0.50 (current master) +--192.168.0.60
 +--192.168.0.70Sun Apr 20 23:10:01 2014 - [info] Checking replication health on 192.168.0.60..
Sun Apr 20 23:10:01 2014 - [info]  ok.
Sun Apr 20 23:10:01 2014 - [info] Checking replication health on 192.168.0.70..
Sun Apr 20 23:10:01 2014 - [info]  ok.
Sun Apr 20 23:10:01 2014 - [info] Checking master_ip_failover_script status:
Sun Apr 20 23:10:01 2014 - [info]   /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.0.50 --orig_master_ip=192.168.0.50 --orig_master_port=3306 Sun Apr 20 23:10:01 2014 - [info]  OK.
Sun Apr 20 23:10:01 2014 - [warning] shutdown_script is not defined.
Sun Apr 20 23:10:01 2014 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

可以看見已經(jīng)沒有報錯了。哈哈
 /usr/local/bin/master_ip_failover添加或者修改的內(nèi)容意思是當主庫數(shù)據(jù)庫發(fā)生故障時，會觸發(fā)MHA切換，MHA Manager會停掉主庫上的keepalived服務，觸發(fā)虛擬ip漂移到備選從庫，從而完成切換。當然可以在keepalived里面引入腳本，這個腳本監(jiān)控mysql是否正常運行，如果不正常，則調(diào)用該腳本殺掉keepalived進程。

2.通過腳本的方式管理VIP。這里是修改/usr/local/bin/master_ip_failover，也可以使用其他的語言完成，比如php語言。使用php腳本編寫的failover這里就不介紹了。修改完成后內(nèi)容如下，而且如果使用腳本管理vip的話，需要手動在master服務器上綁定一個vip（發(fā)現(xiàn)修改修改對perl竟然有感覺了。難道我適合學Perl？^_^）

[root@192.168.0.50 ~]# /sbin/ifconfig eth2:1 192.168.0.88/24

通過腳本來維護vip的測試我這里就不說明了，童鞋們自行測試，腳本如下（測試通過）

 warnings FATAL =>  Getopt::,          ,        , ,    , , ,      =   =   =   =           => \,             => \,     => \,       => \,     => \,      => \,        => \,      => \, &  (  eq  ||  eq   =  & =     (  eq   =  & =    (  eq   & \@ \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

為了防止腦裂發(fā)生，推薦生產(chǎn)環(huán)境采用腳本的方式來管理虛擬ip，而不是使用keepalived來完成。到此為止，基本MHA集群已經(jīng)配置完畢。接下來就是實際的測試環(huán)節(jié)了。通過一些測試來看一下MHA到底是如何進行工作的。下面將從MHA自動failover，我們手動failover，在線切換三種方式來介紹MHA的工作情況。

一.自動Failover（必須先啟動MHA Manager，否則無法自動切換，當然手動切換不需要開啟MHA Manager監(jiān)控。各位童鞋請參考前面啟動MHA Manager）

測試環(huán)境再次貼一下，文章太長，自己都搞暈了。

角色                    ip地址          主機名          server_id               類型
Monitor host            192.168.0.20    server01            -                   監(jiān)控復制組
Master                  192.168.0.50    server02            1                   寫入
Candicate master        192.168.0.60    server03            2                   讀
Slave                   192.168.0.70    server04            3                   讀

自動failover模擬測試的操作步驟如下。
（1）使用sysbench生成測試數(shù)據(jù)（使用yum快速安裝）

 yum install sysbench -y

在主庫（192.168.0.50）上進行sysbench數(shù)據(jù)生成，在sbtest庫下生成sbtest表，共100W記錄。

[root@192.168.0.50 ~]# sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=1800 --mysql-user=root --mysql-socket=/tmp/mysql.sock --mysql-password=123456 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex prepare

（2）停掉slave sql線程，模擬主從延時。（192.168.0.60）

mysql> stop slave io_thread;
Query OK, 0 rows affected (0.08 sec)

mysql>

另外一臺slave我們沒有停止io線程，所以還在繼續(xù)接收日志。

（3）模擬sysbench壓力測試。

在主庫上（192.168.0.50）進行壓力測試，持續(xù)時間為3分鐘，產(chǎn)生大量的binlog。

[root@192.168.0.50 ~]# sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=180 --mysql-user=root --mysql-socket=/tmp/mysql.sock --mysql-password=123456 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex run 
sysbench 0.4.12:  multi-threaded system evaluation benchmark

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


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

OLTP test statistics:
    queries performed:
        read:                            15092
        write:                           5390
        other:                           2156
        total:                           22638
    transactions:                        1078   (5.92 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 20482  (112.56 per sec.)
    other operations:                    2156   (11.85 per sec.)

Test execution summary:
    total time:                          181.9728s
    total number of events:              1078
    total time taken by event execution: 2910.4518
    per-request statistics:
         min:                                934.29ms
         avg:                               2699.86ms
         max:                               7679.95ms
         approx.  95 percentile:            4441.47ms

Threads fairness:
    events (avg/stddev):           67.3750/1.49
    execution time (avg/stddev):   181.9032/0.11

（4）開啟slave（192.168.0.60）上的IO線程，追趕落后于master的binlog。

mysql> start slave io_thread;     
Query OK, 0 rows affected (0.00 sec)

mysql>

（5）殺掉主庫mysql進程，模擬主庫發(fā)生故障，進行自動failover操作。

[root@192.168.0.50 ~]# pkill -9 mysqld

（6）查看MHA切換日志，了解整個切換過程，在192.168.0.20上查看日志：

 View Code

看到最后的Master failover to 192.168.0.60(192.168.0.60:3306) completed successfully.說明備選master現(xiàn)在已經(jīng)上位了。

從上面的輸出可以看出整個MHA的切換過程，共包括以下的步驟：

1.配置文件檢查階段，這個階段會檢查整個集群配置文件配置

2.宕機的master處理，這個階段包括虛擬ip摘除操作，主機關機操作（這個我這里還沒有實現(xiàn)，需要研究）

3.復制dead maste和最新slave相差的relay log，并保存到MHA Manger具體的目錄下

4.識別含有最新更新的slave

5.應用從master保存的二進制日志事件（binlog events）

6.提升一個slave為新的master進行復制

7.使其他的slave連接新的master進行復制

最后啟動MHA Manger監(jiān)控，查看集群里面現(xiàn)在誰是master（在切換后監(jiān)控就停止了。。。還有東西沒搞對？）后來在官方網(wǎng)站看到這句話就明白了 。

Running MHA Manager from daemontools

Currently MHA Manager process does not run as a daemon. If failover completed successfully or the master process was killed by accident, the manager stops working. To run as a daemon, daemontool. or any external daemon program can be used. Here is an example to run from daemontools.

[root@192.168.0.20 ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:23971) is running(0:PING_OK), master:192.168.0.60[root@192.168.0.20 ~]#

二.手動Failover（MHA Manager必須沒有運行）

手動failover，這種場景意味著在業(yè)務上沒有啟用MHA自動切換功能，當主服務器故障時，人工手動調(diào)用MHA來進行故障切換操作，具體命令如下：

注意：如果，MHA manager檢測到?jīng)]有dead的server，將報錯，并結束failover： 

Mon Apr 21 21:23:33 2014 - [info] Dead Servers:
Mon Apr 21 21:23:33 2014 - [error][/usr/local/share/perl5/MHA/MasterFailover.pm, ln181] None of server is dead. Stop failover.
Mon Apr 21 21:23:33 2014 - [error][/usr/local/share/perl5/MHA/ManagerUtil.pm, ln178] Got ERROR:  at /usr/local/bin/masterha_master_switch line 53

進行手動切換命令如下：

[root@192.168.0.20 ~]# masterha_master_switch --master_state=dead --conf=/etc/masterha/app1.cnf --dead_master_host=192.168.0.50 --dead_master_port=3306 --new_master_host=192.168.0.60 --new_master_port=3306 --ignore_last_failover

輸出的信息會詢問你是否進行切換：

 View Code

上述模擬了master宕機的情況下手動把192.168.0.60提升為主庫的操作過程。

三.在線進行切換

 在許多情況下， 需要將現(xiàn)有的主服務器遷移到另外一臺服務器上。 比如主服務器硬件故障，RAID 控制卡需要重建，將主服務器移到性能更好的服務器上等等。維護主服務器引起性能下降， 導致停機時間至少無法寫入數(shù)據(jù)。 另外， 阻塞或殺掉當前運行的會話會導致主主之間數(shù)據(jù)不一致的問題發(fā)生。 MHA 提供快速切換和優(yōu)雅的阻塞寫入，這個切換過程只需要 0.5-2s 的時間，這段時間內(nèi)數(shù)據(jù)是無法寫入的。在很多情況下，0.5-2s 的阻塞寫入是可以接受的。因此切換主服務器不需要計劃分配維護時間窗口。

MHA在線切換的大概過程：
1.檢測復制設置和確定當前主服務器
2.確定新的主服務器
3.阻塞寫入到當前主服務器
4.等待所有從服務器趕上復制
5.授予寫入到新的主服務器
6.重新設置從服務器 

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

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

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

為了保證數(shù)據(jù)完全一致性，在最快的時間內(nèi)完成切換，MHA的在線切換必須滿足以下條件才會切換成功，否則會切換失敗。

1.所有slave的IO線程都在運行

2.所有slave的SQL線程都在運行

3.所有的show slave status的輸出中Seconds_Behind_Master參數(shù)小于或者等于running_updates_limit秒，如果在切換過程中不指定running_updates_limit,那么默認情況下running_updates_limit為1秒。

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

在線切換步驟如下：

首先，停掉MHA監(jiān)控：

[root@192.168.0.20 ~]# masterha_stop --conf=/etc/masterha/app1.cnf

其次，進行在線切換操作（模擬在線切換主庫操作，原主庫192.168.0.50變?yōu)閟lave，192.168.0.60提升為新的主庫）

[root@192.168.0.20 ~]# masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.0.60 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000

最后查看日志，了解切換過程，輸出信息如下：

 View Code

其中參數(shù)的意思：

--orig_master_is_new_slave 切換時加上此參數(shù)是將原 master 變?yōu)?slave 節(jié)點，如果不加此參數(shù)，原來的 master 將不啟動

--running_updates_limit=10000,故障切換時,候選master 如果有延遲的話， mha 切換不能成功，加上此參數(shù)表示延遲在此時間范圍內(nèi)都可切換（單位為s），但是切換的時間長短是由recover 時relay 日志的大小決定 

注意：由于在線進行切換需要調(diào)用到master_ip_online_change這個腳本，但是由于該腳本不完整，需要自己進行相應的修改，我google到后發(fā)現(xiàn)還是有問題，腳本中new_master_password這個變量獲取不到，導致在線切換失敗，所以進行了相關的硬編碼，直接把mysql的root用戶密碼賦值給變量new_master_password，如果有哪位大牛知道原因，請指點指點。這個腳本還可以管理vip。下面貼出腳本：

 View Code

四.修復宕機的Master 

通常情況下自動切換以后，原master可能已經(jīng)廢棄掉，待原master主機修復后，如果數(shù)據(jù)完整的情況下，可能想把原來master重新作為新主庫的slave，這時我們可以借助當時自動切換時刻的MHA日志來完成對原master的修復。下面是提取相關日志的命令：

[root@192.168.0.20 app1]# grep -i "All other slaves should start" manager.log 
Mon Apr 21 22:28:33 2014 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.0.60', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000022', MASTER_LOG_POS=506716, MASTER_USER='repl', MASTER_PASSWORD='xxx';
[root@192.168.0.20 app1]#

獲取上述信息以后，就可以直接在修復后的master上執(zhí)行change master to相關操作，重新作為從庫了。

最后補充一下郵件發(fā)送腳本send_report ，這個腳本在詢問一位朋友后可以使用，如下：

 View Code

最后切換以后發(fā)送告警的郵件示例，注意，這個是我后續(xù)的測試，和上面環(huán)境出現(xiàn)的ip不一致不要在意。

總結：

目前高可用方案可以一定程度上實現(xiàn)數(shù)據(jù)庫的高可用，比如前面文章介紹的MMM，heartbeat+drbd，Cluster等。還有percona的Galera Cluster等。這些高可用軟件各有優(yōu)劣。在進行高可用方案選擇時，主要是看業(yè)務還有對數(shù)據(jù)一致性方面的要求。最后出于對數(shù)據(jù)庫的高可用和數(shù)據(jù)一致性的要求，推薦使用MHA架構。

 看了以上MySQL之MHA分享介紹，希望能給大家在實際運用中帶來一定的幫助。本文由于篇幅有限，難免會有不足和需要補充的地方，大家可以繼續(xù)關注億速云行業(yè)資訊板塊，會定期給大家更新行業(yè)新聞和知識，如有需要更加專業(yè)的解答，可在官網(wǎng)聯(lián)系我們的24小時售前售后，隨時幫您解答問題的。