MySQL高可用架構之MHA
簡介：
MHA（MasterHigh Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現就職於Facebook公司）開發，是一套優秀的作為MySQL高可用性環境下故障切換和主從提升的高可用軟體。在MySQL故障切換過程中，MHA能做到在0~30秒之內自動完成資料庫的故障切換操作，並且在進行故障切換的過程中，MHA能在最大程度上保證資料的一致性，以達到真正意義上的高可用。
該軟體由兩部分組成：MHA Manager（管理節點）和MHA Node（資料節點）。MHA Manager可以單獨部署在一臺獨立的機器上管理多個master-slave叢集，也可以部署在一臺slave節點上。MHA Node執行在每臺MySQL伺服器上，MHA Manager會定時探測叢集中的master節點，當master出現故障時，它可以自動將最新資料的slave提升為新的master，然後將所有其他的slave重新指向新的master。整個故障轉移過程對應用程式完全透明。
在MHA自動故障切換過程中，MHA試圖從宕機的主伺服器上儲存二進位制日誌，最大程度的保證資料的不丟失，但這並不總是可行的。例如，如果主伺服器硬體故障或無法通過ssh訪問，MHA沒法儲存二進位制日誌，只進行故障轉移而丟失了最新的資料。使用MySQL 5.5的半同步複製，可以大大降低資料丟失的風險。MHA可以與半同步複製結合起來。如果只有一個slave已經收到了最新的二進位制日誌，MHA可以將最新的二進位制日誌應用於其他所有的slave伺服器上，因此可以保證所有節點的資料一致性。
目前MHA主要支援一主多從的架構，要搭建MHA,要求一個複製叢集中必須最少有三臺資料庫伺服器，一主二從，即一臺充當master，一臺充當備用master，另外一臺充當從庫，因為至少需要三臺伺服器，出於機器成本的考慮，淘寶也在該基礎上進行了改造，目前淘寶TMHA已經支援一主一從。另外對於想快速搭建的可以參考：
我們自己使用其實也可以使用1主1從，但是master主機宕機後無法切換，以及無法補全binlog。master的mysqld程序crash後，還是可以切換成功，以及補全binlog的。
官方介紹：https://code.google.com/p/mysql-master-ha/
圖01展示瞭如何通過MHA Manager管理多組主從複製。可以將MHA工作原理總結為如下：
（ 圖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執行狀態 masterha_master_monitor 檢測master是否宕機 masterha_master_switch 控制故障轉移（自動或者手動） masterha_conf_host 新增或刪除配置的server資訊
Node工具包（這些工具通常由MHA Manager的指令碼觸發，無需人為操作）主要包括以下幾個工具：
save_binary_logs 儲存和複製master的二進位制日誌 apply_diff_relay_logs 識別差異的中繼日誌事件並將其差異的事件應用於其他的slave filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用這個工具） purge_relay_logs 清除中繼日誌（不會阻塞SQL執行緒）
注意：
為了儘可能的減少主庫硬體損壞宕機造成的資料丟失，因此在配置MHA的同時建議配置成MySQL 5.5的半同步複製。關於半同步複製原理各位自己進行查閱。（不是必須）
1.部署MHA
接下來部署MHA，具體的搭建環境如下（所有作業系統均為centos 6.2 64bit，不是必須，server03和server04是server02的從，複製環境搭建後面會簡單演示，但是相關的安全複製不會詳細說明，需要的童鞋請參考前面的文章，MySQL Replication需要注意的問題）：
角色 ip地址 主機名 server_id 型別 Monitor host 192.168.0.20 server01 - 監控複製組 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）在所有節點安裝MHA node所需的perl模組（DBD:mysql），安裝指令碼如下：
[[email protected] ~]# cat install.sh #!/bin/bash wget http://xrl.us/cpanm --no-check-certificate mv cpanm /usr/bin chmod 755 /usr/bin/cpanm cat > /root/list << EOF install DBD::mysql EOF for package in `cat /root/list` do cpanm $package done [[email protected] ~]#
如果有安裝epel源，也可以使用yum安裝
yum install perl-DBD-MySQL -y
（2）在所有的節點安裝mha 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
安裝完成後會在/usr/local/bin目錄下生成以下指令碼檔案：
[[email protected] bin]# pwd /usr/local/bin [[email protected] 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 [[email protected] bin]#
關於上面指令碼的功能，上面已經介紹過了，這裡不再重複了。
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.gz tar xf mha4mysql-node-0.53.tar.gz cd mha4mysql-node-0.53 perl Makefile.PL make && 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.gz tar xf mha4mysql-manager-0.53.tar.gz cd mha4mysql-manager-0.53 perl Makefile.PL make && make install
安裝完成後會在/usr/local/bin目錄下面生成以下指令碼檔案，前面已經說過這些指令碼的作用，這裡不再重複
[[email protected] bin]# pwd /usr/local/bin [[email protected] 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 [[email protected] bin]#
複製相關指令碼到/usr/local/bin目錄(軟體包解壓縮後就有了，不是必須，因為這些指令碼不完整，需要自己修改，這是軟體開發著留給我們自己發揮的,如果開啟下面的任何一個指令碼對應的引數，而對應這裡的指令碼又沒有修改，則會拋錯，自己被坑的很慘)
[[email protected] scripts]# pwd /root/mha4mysql-manager-0.53/samples/scripts [[email protected] scripts]# ll total 32 -rwxr-xr-x 1 root root 3443 Jan 8 2012 master_ip_failover #自動切換時vip管理的指令碼，不是必須，如果我們使用keepalived的，我們可以自己編寫指令碼完成對vip的管理，比如監控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 #故障發生後關閉主機的指令碼，不是必須 -rwxr-xr-x 1 root root 1360 Jan 8 2012 send_report #因故障切換後傳送報警的指令碼，不是必須，可自行編寫簡單的shell完成。 [[email protected] scripts]# cp * /usr/local/bin/ [[email protected] scripts]#
3.配置SSH登入無密碼驗證（使用key登入，工作中常用）我的測試環境已經是使用key登入，伺服器之間無需密碼驗證的。關於配置使用key登入，我想我不再重複。但是有一點需要注意：不能禁止 password 登陸，否則會出現錯誤
4.搭建主從複製環境
注意：binlog-do-db 和 replicate-ignore-db 設定必須相同。 MHA 在啟動時候會檢測過濾規則，如果過濾規則不同，MHA 不啟動監控和故障轉移。
（1）在server02上執行備份（192.168.0.50）
[[email protected] ~]# mysqldump --master-data=2 --single-transaction -R --triggers -A > all.sql
其中--master-data=2代表備份時刻記錄master的Binlog位置和Position，--single-transaction意思是獲取一致性快照，-R意思是備份儲存過程和函式，--triggres的意思是備份觸發器，-A代表備份所有的庫。更多資訊請自行mysqldump --help檢視。
（2）在server02上建立複製使用者：
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：
[[email protected] ~]# head -n 30 all.sql | grep 'CHANGE MASTER TO' -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000010', MASTER_LOG_POS=112; [[email protected] ~]#
（4）把備份複製到server03和server04，也就是192.168.0.60和192.168.0.70
scp all.sql server03:/data/ scp all.sql server04:/data/
（5）匯入備份到server03，執行復制相關命令
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>
檢視複製狀態（可以看見覆製成功）：
[[email protected] ~]# 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 [[email protected] ~]#
（6）在server04（192.168.0.70）上搭建複製環境，操作和上面一樣。
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>
檢視複製狀態：
[[email protected] ~]# 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 [[email protected] ~]#
（7）兩臺slave伺服器設定read_only（從庫對外提供讀服務，只所以沒有寫進配置檔案，是因為隨時slave會提升為master）
[[email protected] ~]# mysql -e 'set global read_only=1' [[email protected] ~]#
[[email protected] ~]# mysql -e 'set global read_only=1' [[email protected] ~]#
（8）建立監控使用者（在master上執行，也就是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>
到這裡整個叢集環境已經搭建完畢，剩下的就是配置MHA軟體了。
5.配置MHA
（1）建立MHA的工作目錄，並且建立相關配置檔案（在軟體包解壓後的目錄裡面有樣例配置檔案）。
[[email protected] ~]# mkdir -p /etc/masterha [[email protected] ~]# cp mha4mysql-manager-0.53/samples/conf/app1.cnf /etc/masterha/ [[email protected] ~]#
修改app1.cnf配置檔案，修改後的檔案內容如下（注意，配置檔案中的註釋需要去掉，我這裡是為了解釋清楚）：
[[email protected] ~]# cat /etc/masterha/app1.cnf [server default] manager_workdir=/var/log/masterha/app1.log //設定manager的工作目錄 manager_log=/var/log/masterha/app1/manager.log //設定manager的日誌 master_binlog_dir=/data/mysql //設定master 儲存binlog的位置，以便MHA可以找到master的日誌，我這裡的也就是mysql的資料目錄 master_ip_failover_script= /usr/local/bin/master_ip_failover //設定自動failover時候的切換指令碼 master_ip_online_change_script= /usr/local/bin/master_ip_online_change //設定手動切換時候的切換指令碼 password=123456 //設定mysql中root使用者的密碼，這個密碼是前文中建立監控使用者的那個密碼 user=root 設定監控使用者root ping_interval=1 //設定監控主庫，傳送ping包的時間間隔，預設是3秒，嘗試三次沒有迴應的時候自動進行railover remote_workdir=/tmp //設定遠端mysql在發生切換時binlog的儲存位置 repl_password=123456 //設定複製使用者的密碼 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 //設定ssh的登入使用者名稱 [server1] hostname=192.168.0.50 port=3306 [server2] hostname=192.168.0.60 port=3306 candidate_master=1 //設定為候選master，如果設定該引數以後，發生主從切換以後將會將此從庫提升為主庫，即使這個主庫不是叢集中事件最新的slave check_repl_delay=0 //預設情況下如果一個slave落後master 100M的relay logs的話，MHA將不會選擇該slave作為一個新的master，因為對於這個slave的恢復需要花費很長時間，通過設定check_repl_delay=0,MHA觸發切換在選擇一個新的master的時候將會忽略複製延時，這個引數對於設定了candidate_master=1的主機非常有用，因為這個候選主在切換的過程中一定是新的master [server3] hostname=192.168.0.70 port=3306 [[email protected] ~]#
（2）設定relay log的清除方式（在每個slave節點上）：
[[email protected] ~]# mysql -e 'set global relay_log_purge=0' [[email protected] ~]# mysql -e 'set global relay_log_purge=0'
注意：
MHA在發生切換的過程中，從庫的恢復過程中依賴於relay log的相關資訊，所以這裡要將relay log的自動清除設定為OFF，採用手動清除relay log的方式。在預設情況下，從伺服器上的中繼日誌會在SQL執行緒執行完畢後被自動刪除。但是在MHA環境中，這些中繼日誌在恢復其他從伺服器時可能會被用到，因此需要禁用中繼日誌的自動刪除功能。定期清除中繼日誌需要考慮到複製延時的問題。在ext3的檔案系統下，刪除大的檔案需要一定的時間，會導致嚴重的複製延時。為了避免複製延時，需要暫時為中繼日誌建立硬連結，因為在linux系統中通過硬連結刪除大檔案速度會很快。（在mysql資料庫中，刪除大表時，通常也採用建立硬連結的方式）
MHA節點中包含了pure_relay_logs命令工具，它可以為中繼日誌建立硬連結，執行SET GLOBAL relay_log_purge=1,等待幾秒鐘以便SQL執行緒切換到新的中繼日誌，再執行SET GLOBAL relay_log_purge=0。
pure_relay_logs指令碼引數如下所示：
--user mysql 使用者名稱 --password mysql 密碼 --port 埠號 --workdir 指定建立relay log的硬連結的位置，預設是/var/tmp，由於系統不同分割槽建立硬連結檔案會失敗，故需要執行硬連結具體位置，成功執行指令碼後，硬連結的中繼日誌檔案被刪除 --disable_relay_log_purge 預設情況下，如果relay_log_purge=1，指令碼會什麼都不清理，自動退出，通過設定這個引數，當relay_log_purge=1的情況下會將relay_log_purge設定為0。清理relay log之後，最後將引數設定為OFF。
（3）設定定期清理relay指令碼（兩臺slave伺服器）
[[email protected] ~]# cat purge_relay_log.sh #!/bin/bash user=root passwd=123456 port=3306 log_dir='/data/masterha/log' work_dir='/data' purge='/usr/local/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 [[email protected] ~]#
新增到crontab定期執行
[[email protected] ~]# crontab -l 0 4 * * * /bin/bash /root/purge_relay_log.sh [[email protected] ~]#
purge_relay_logs指令碼刪除中繼日誌不會阻塞SQL執行緒。下面我們手動執行看看什麼情況。
[[email protected] ~]# 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. [[email protected] ~]#
6.檢查SSH配置
檢查MHA Manger到所有MHA Node的SSH連線狀態：
[[email protected] ~]# 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 [email protected](192.168.0.50:22) to [email protected](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 [email protected](192.168.0.50:22) to [email protected](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 [email protected](192.168.0.60:22) to [email protected](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 [email protected](192.168.0.60:22) to [email protected](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 [email protected](192.168.0.70:22) to [email protected](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 [email protected](192.168.0.70:22) to [email protected](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.
可以看見各個節點ssh驗證都是ok的。
7.檢查整個複製環境狀況。
通過masterha_check_repl指令碼檢視整個叢集的狀態
[[email protected] ~]# 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 48 Sun 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!
發現最後的結論說我的複製不是ok的。但是上面的資訊明明說是正常的，自己也進資料庫查看了。這裡一直踩坑。一直糾結，後來無意中發現火丁筆記的部落格，這才知道了原因，原來Failover兩種方式：一種是虛擬IP地址，一種是全域性配置檔案。MHA並沒有限定使用哪一種方式，而是讓使用者自己選擇，虛擬IP地址的方式會牽扯到其它的軟體,比如keepalive軟體，而且還要修改指令碼master_ip_failover。(最後修改指令碼後才沒有這個報錯，自己不懂perl也是折騰的半死，去年買了塊表)
如果發現如下錯誤：
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
解決方法如下，新增軟連線（所有節點）
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後和修改該指令碼以後再開啟該選項。
[[email protected] ~]# grep master_ip_failover /etc/masterha/app1.cnf #master_ip_failover_script= /usr/local/bin/master_ip_failover [[email protected] ~]#
再次進行狀態檢視：
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.
已經沒有明顯報錯，只有兩個警告而已，複製也顯示正常了。
8.檢查MHA Manager的狀態：
通過master_check_status指令碼檢視Manager的狀態：
[[email protected] ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 is stopped(2:NOT_RUNNING). [[email protected] ~]#
注意：如果正常，會顯示"PING_OK"，否則會顯示"NOT_RUNNING"，這代表MHA監控沒有開啟。
9.開啟MHA Manager監控
[[email protected] ~]# 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 [[email protected] ~]#
啟動引數介紹：
--remove_dead_master_conf 該引數代表當發生主從切換後，老的主庫的ip將會從配置檔案中移除。
--manger_log 日誌存放位置
--ignore_last_failover在預設情況下，如果MHA檢測到連續發生宕機，且兩次宕機間隔不足8小時的話，則不會進行Failover，之所以這樣限制是為了避免ping-pong效應。該引數代表忽略上次MHA觸發切換產生的檔案，預設情況下，MHA發生切換後會在日誌目錄，也就是上面我設定的/data產生app1.failover.complete檔案，下次再次切換的時候如果發現該目錄下存在該檔案將不允許觸發切換，除非在第一次切換後收到刪除該檔案，為了方便，這裡設定為--ignore_last_failover。
檢視MHA Manager監控是否正常：
[[email protected] ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:20386) is running(0:PING_OK), master:192.168.0.50 [[email protected] ~]#
可以看見已經在監控了，而且master的主機為192.168.0.50
10.檢視啟動日誌
[[email protected] ~]# tail -n20 /var/log/masterha/app1/manager.log Sun Apr 20 19:12:01 2014 - [info] Connecting to [email protected](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.70 Sun 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=3306 Sun 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.. [[email protected] ~]#
其中"Ping(SELECT) succeeded, waiting until MySQL doesn't respond.."說明整個系統已經開始監控了。
11.關閉MHA Manage監控
關閉很簡單，使用masterha_stop命令完成。
[[email protected] ~]# 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 [[email protected] ~]#
12.配置VIP
vip配置可以採用兩種方式，一種通過keepalived的方式管理虛擬ip的浮動；另外一種通過指令碼方式啟動虛擬ip的方式（即不需要keepalived或者heartbeat類似的軟體）。
1.keepalived方式管理虛擬ip，keepalived配置方法如下：
（1）下載軟體進行並進行安裝（兩臺master，準確的說一臺是master，另外一臺是備選master，在沒有切換以前是slave）：
[[email protected] ~]# 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/keepalived make && make install cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/ cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/ mkdir /etc/keepalived cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/ cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
（2）配置keepalived的配置檔案，在master上配置（192.168.0.50）
[[email protected] ~]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id MySQL-HA } vrrp_instance VI_1 { state BACKUP interface eth1 virtual_router_id 51 priority 150 advert_int 1 nopreempt authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.0.88 } } [[email protected] ~]#
其中router_id MySQL HA表示設定keepalived組的名稱，將192.168.0.88這個虛擬ip繫結到該主機的eth1網絡卡上，並且設定了狀態為backup模式，將keepalived的模式設定為非搶佔模式（nopreempt），priority 150表示設定的優先順序為150。下面的配置略有不同，但是都是一個意思。
在候選master上配置（192.168.0.60）
[[email protected] ~]# cat /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id MySQL-HA } vrrp_instance VI_1 { state BACKUP interface eth1 virtual_router_id 51 priority 120 advert_int 1 nopreempt authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.0.88 } } [[email protected] ~]#
（3）啟動keepalived服務，在master上啟動並檢視日誌
[[email protected] ~]# /etc/init.d/keepalived start Starting keepalived: [ OK ] [[email protected] ~]# 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 eth1 for 192.168.0.88 Apr 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 eth1 for 192.168.0.88
發現已經將虛擬ip 192.168.0.88綁定了網絡卡eth1上。
（4）檢視繫結情況
[[email protected] ~]# ip addr | grep eth1 3: eth1: <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 eth1 inet 192.168.0.88/32 scope global eth1 [[email protected] ~]#
在另外一臺伺服器，候選master上啟動keepalived服務，並觀察
[[email protected] ~]# /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 STATE Apr 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已經配置成功。
注意：
上面兩臺伺服器的keepalived都設定為了BACKUP模式，在keepalived中2種模式，分別是master->backup模式和backup->backup模式。這兩種模式有很大區別。在master->backup模式下，一旦主庫宕機，虛擬ip會自動漂移到從庫，當主庫修復後，keepalived啟動後，還會把虛擬ip搶佔過來，即使設定了非搶佔模式（nopreempt）搶佔ip的動作也會發生。在backup->backup模式下，當主庫宕機後虛擬ip會自動漂移到從庫上，當原主庫恢復和keepalived服務啟動後，並不會搶佔新主的虛擬ip，即使是優先順序高於從庫的優先級別，也不會發生搶佔。為了減少ip漂移次數，通常是把修復好的主庫當做新的備庫。
（5）MHA引入keepalived（MySQL服務程序掛掉時通過MHA 停止keepalived）:
要想把keepalived服務引入MHA，我們只需要修改切換是觸發的指令碼檔案master_ip_failover即可，在該指令碼中新增在master發生宕機時對keepalived的處理。
編輯指令碼/usr/local/bin/master_ip_failover，修改後如下，我對perl不熟悉，所以我這裡完整貼出該指令碼（主庫上操作，192.168.0.50）。
在MHA Manager修改指令碼修改後的內容如下（參考資料比較少）：
#!/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';
my $ssh_start_vip = "/etc/init.d/keepalived start";
my $ssh_stop_vip = "/etc/init.d/keepalived stop";
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";
&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";
#`ssh $ssh_user\@cluster1 \" $ssh_start_vip \"`;
exit 0;
}
else {
&usage();
exit 1;
}
}
# A simple system call that enable the VIP on the new master
sub start_vip() {
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
# A simple system call that disable the VIP on the old_master
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";
}
現在已經修改這個指令碼了，我們現在開啟在上面提到過的引數，再檢查叢集狀態，看是否會報錯。
[[email protected] ~]# grep 'master_ip_failover_script' /etc/masterha/app1.cnf master_ip_failover_script= /usr/local/bin/master_ip_failover [[email protected] ~]#
[[email protected] ~]# 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.70 Sun 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.
可以看見已經沒有報錯了。哈哈
/usr/local/bin/master_ip_failover新增或者修改的內容意思是當主庫資料庫發生故障時，會觸發MHA切換，MHA Manager會停掉主庫上的keepalived服務，觸發虛擬ip漂移到備選從庫，從而完成切換。當然可以在keepalived裡面引入指令碼，這個指令碼監控mysql是否正常執行，如果不正常，則呼叫該指令碼殺掉keepalived程序。
2.通過指令碼的方式管理VIP。這裡是修改/usr/local/bin/master_ip_failover，也可以使用其他的語言完成，比如php語言。使用php指令碼編寫的failover這裡就不介紹了。修改完成後內容如下，而且如果使用指令碼管理vip的話，需要手動在master伺服器上繫結一個vip（發現修改修改對perl竟然有感覺了。難道我適合學Perl？^_^）
[[email protected] ~]# /sbin/ifconfig eth1:1 192.168.0.88/24
通過指令碼來維護vip的測試我這裡就不說明了，童鞋們自行測試，指令碼如下（測試通過）
#!/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 eth1:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth1:$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";
&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";
}
為了防止腦裂發生，推薦生產環境採用指令碼的方式來管理虛擬ip，而不是使用keepalived來完成。到此為止，基本MHA叢集已經配置完畢。接下來就是實際的測試環節了。通過一些測試來看一下MHA到底是如何進行工作的。下面將從MHA自動failover，我們手動failover，線上切換三種方式來介紹MHA的工作情況。
一.自動Failover（必須先啟動MHA Manager，否則無法自動切換，當然手動切換不需要開啟MHA Manager監控。各位童鞋請參考前面啟動MHA Manager）
測試環境再次貼一下，文章太長，自己都搞暈了。
角色 ip地址 主機名 server_id 型別 Monitor host 192.168.0.20 server01 - 監控複製組 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生成測試資料（使用yum快速安裝）
yum install sysbench -y
在主庫（192.168.0.50）上進行sysbench資料生成，在sbtest庫下生成sbtest表，共100W記錄。
[[email protected] ~]# 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執行緒，所以還在繼續接收日誌。
（3）模擬sysbench壓力測試。
在主庫上（192.168.0.50）進行壓力測試，持續時間為3分鐘，產生大量的binlog。
[[email protected] ~]# 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: 16 Initializing 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程序，模擬主庫發生故障，進行自動failover操作。
[[email protected] ~]# 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現在已經上位了。
從上面的輸出可以看出整個MHA的切換過程，共包括以下的步驟：
1.配置檔案檢查階段，這個階段會檢查整個叢集配置檔案配置
2.宕機的master處理，這個階段包括虛擬ip摘除操作，主機關機操作（這個我這裡還沒有實現，需要研究）
3.複製dead maste和最新slave相差的relay log，並儲存到MHA Manger具體的目錄下
4.識別含有最新更新的slave
5.應用從master儲存的二進位制日誌事件（binlog events）
6.提升一個slave為新的master進行復制
7.使其他的slave連線新的master進行復制
最後啟動MHA Manger監控，檢視叢集裡面現在誰是master（在切換後監控就停止了。。。還有東西沒搞對？）後來在官方網站看到這句話就明白了 。
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.
[[email protected] ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:23971) is running(0:PING_OK), master:192.168.0.60 [[email protected] ~]#
二.手動Failover（MHA Manager必須沒有執行）
手動failover，這種場景意味著在業務上沒有啟用MHA自動切換功能，當主伺服器故障時，人工手動呼叫MHA來進行故障切換操作，具體命令如下：
注意：如果，MHA manager檢測到沒有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
進行手動切換命令如下：
[[email protected] ~]# 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提升為主庫的操作過程。
三.線上進行切換
在許多情況下， 需要將現有的主伺服器遷移到另外一臺伺服器上。 比如主伺服器硬體故障，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監控：
[[email protected] ~]# masterha_stop --conf=/etc/masterha/app1.cnf
其次，進行線上切換操作（模擬線上切換主庫操作，原主庫192.168.0.50變為slave，192.168.0.60提升為新的主庫）
[[email protected] ~]# 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其中引數的意思：
--orig_master_is_new_slave 切換時加上此引數是將原 master 變為 slave 節點，如果不加此引數，原來的 master 將不啟動
--running_updates_limit=10000,故障切換時,候選master 如果有延遲的話， mha 切換不能成功，加上此引數表示延遲在此時間範圍內都可切換（單位為s），但是切換的時間長短是由recover 時relay 日誌的大小決定
注意：由於線上進行切換需要呼叫到master_ip_online_change這個指令碼，但是由於該指令碼不完整，需要自己進行相應的修改，我google到後發現還是有問題，指令碼中new_master_password這個變數獲取不到，導致線上切換失敗，所以進行了相關的硬編碼，直接把mysql的root使用者密碼賦值給變數new_master_password，如果有哪位大牛知道原因，請指點指點。這個指令碼還可以管理vip。下面貼出指令碼：
View Code四.修復宕機的Master
通常情況下自動切換以後，原master可能已經廢棄掉，待原master主機修復後，如果資料完整的情況下，可能想把原來master重新作為新主庫的slave，這時我們可以藉助當時自動切換時刻的MHA日誌來完成對原master的修復。下面是提取相關日誌的命令：
[[email protected] 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'; [[email protected] app1]#
獲取上述資訊以後，就可以直接在修復後的master上執行change master to相關操作，重新作為從庫了。
最後補充一下郵件傳送指令碼send_report ，這個指令碼在詢問一位朋友後可以使用，如下：
View Code最後切換以後傳送告警的郵件示例，注意，這個是我後續的測試，和上面環境出現的ip不一致不要在意。
總結：
目前高可用方案可以一定程度上實現資料庫的高可用，比如前面文章介紹的MMM，heartbeat+drbd，Cluster等。還有percona的Galera Cluster等。這些高可用軟體各有優劣。在進行高可用方案選擇時，主要是看業務還有對資料一致性方面的要求。最後出於對資料庫的高可用和資料一致性的要求，推薦使用MHA架構。
參考資料：
http://huoding.com/2011/12/18/139
http://blog.itpub.net/88305/viewspace-730135/
https://code.google.com/p/mysql-master-ha/wiki/TableOfContents?tm=6（自備梯子）
http://k-1-ne-jp.blogspot.com/2013/02/masterhamasterswitch_13.html（自備梯子）