溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文主要給大家介紹MySQL之MHA分享，其所涉及的東西，從理論知識來獲悉，有很多書籍、文獻可供大家參考，從現實意義角度出發，億速云累計多年的實踐經驗可分享給大家。
簡介：
MHA（Master High 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已經支持一主一從。另外對于想快速搭建的可以參考：MHA快速搭建
我們自己使用其實也可以使用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），安裝腳本如下：
[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）在所有的節點安裝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]#
關于上面腳本的功能，上面已經介紹過了，這里不再重復了。
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目錄下面生成以下腳本文件，前面已經說過這些腳本的作用，這里不再重復
[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目錄(軟件包解壓縮后就有了，不是必須，因為這些腳本不完整，需要自己修改，這是軟件開發著留給我們自己發揮的,如果開啟下面的任何一個腳本對應的參數，而對應這里的腳本又沒有修改，則會拋錯，自己被坑的很慘)
[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的管理，比如監控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完成。 [root@192.168.0.20 scripts]# cp * /usr/local/bin/[root@192.168.0.20 scripts]#
3.配置SSH登錄無密碼驗證（使用key登錄，工作中常用）我的測試環境已經是使用key登錄，服務器之間無需密碼驗證的。關于配置使用key登錄，我想我不再重復。但是有一點需要注意：不能禁止 password 登陸，否則會出現錯誤
4.搭建主從復制環境
注意：binlog-do-db 和 replicate-ignore-db 設置必須相同。 MHA 在啟動時候會檢測過濾規則，如果過濾規則不同，MHA 不啟動監控和故障轉移。
（1）在server02上執行備份（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意思是備份存儲過程和函數，--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：
[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，執行復制相關命令
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>
查看復制狀態（可以看見復制成功）：
[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）上搭建復制環境，操作和上面一樣。
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>
查看復制狀態：
[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）創建監控用戶（在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的工作目錄，并且創建相關配置文件（在軟件包解壓后的目錄里面有樣例配置文件）。
[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配置文件，修改后的文件內容如下（注意，配置文件中的注釋需要去掉，我這里是為了解釋清楚）：
[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節點上）：
[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在發生切換的過程中，從庫的恢復過程中依賴于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服務器）
[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定期執行
[root@192.168.0.60 ~]# crontab -l0 4 * * * /bin/bash /root/purge_relay_log.sh[root@192.168.0.60 ~]#
purge_relay_logs腳本刪除中繼日志不會阻塞SQL線程。下面我們手動執行看看什么情況。
[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連接狀態：
[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.
可以看見各個節點ssh驗證都是ok的。
7.檢查整個復制環境狀況。
通過masterha_check_repl腳本查看整個集群的狀態
[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!
發現最后的結論說我的復制不是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后和修改該腳本以后再開啟該選項。
[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 ~]#
再次進行狀態查看：
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的狀態：
[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監控沒有開啟。
9.開啟MHA Manager監控
[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 ~]#
啟動參數介紹：
--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監控是否正常：
[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 ~]#
可以看見已經在監控了，而且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.."說明整個系統已經開始監控了。
11.關閉MHA Manage監控
關閉很簡單，使用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網卡上，并且設置了狀態為backup模式，將keepalived的模式設置為非搶占模式（nopreempt），priority 150表示設置的優先級為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
發現已經將虛擬ip 192.168.0.88綁定了網卡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已經配置成功。
注意：
上面兩臺服務器的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修改腳本修改后的內容如下（參考資料比較少）：
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
現在已經修改這個腳本了，我們現在打開在上面提到過的參數，再檢查集群狀態，看是否會報錯。
[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.
可以看見已經沒有報錯了。哈哈
/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？^_^）
[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
為了防止腦裂發生，推薦生產環境采用腳本的方式來管理虛擬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記錄。
[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線程，所以還在繼續接收日志。
（3）模擬sysbench壓力測試。
在主庫上（192.168.0.50）進行壓力測試，持續時間為3分鐘，產生大量的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進程，模擬主庫發生故障，進行自動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現在已經上位了。
從上面的輸出可以看出整個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（在切換后監控就停止了。。。還有東西沒搞對？）后來在官方網站看到這句話就明白了 。
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，這種場景意味著在業務上沒有啟用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
進行手動切換命令如下：
[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提升為主庫的操作過程。
三.在線進行切換
在許多情況下， 需要將現有的主服務器遷移到另外一臺服務器上。 比如主服務器硬件故障，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@192.168.0.20 ~]# masterha_stop --conf=/etc/masterha/app1.cnf
其次，進行在線切換操作（模擬在線切換主庫操作，原主庫192.168.0.50變為slave，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
其中參數的意思：
--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的修復。下面是提取相關日志的命令：
[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上執行change master to相關操作，重新作為從庫了。
最后補充一下郵件發送腳本send_report ，這個腳本在詢問一位朋友后可以使用，如下：
View Code
最后切換以后發送告警的郵件示例，注意，這個是我后續的測試，和上面環境出現的ip不一致不要在意。
總結：
目前高可用方案可以一定程度上實現數據庫的高可用，比如前面文章介紹的MMM，heartbeat+drbd，Cluster等。還有percona的Galera Cluster等。這些高可用軟件各有優劣。在進行高可用方案選擇時，主要是看業務還有對數據一致性方面的要求。最后出于對數據庫的高可用和數據一致性的要求，推薦使用MHA架構。
看了以上MySQL之MHA分享介紹，希望能給大家在實際運用中帶來一定的幫助。本文由于篇幅有限，難免會有不足和需要補充的地方，大家可以繼續關注億速云行業資訊板塊，會定期給大家更新行業新聞和知識，如有需要更加專業的解答，可在官網聯系我們的24小時售前售后，隨時幫您解答問題的。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
