MySQL高可用架構之MHA

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 適合任何存儲引擎, 只要能主從複製的存儲引擎它都支持，不限於支持事物的 innodb 引擎。

 

官方介紹：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

 

查看系統數版本號

[bsauser@bsa188 ~]$ cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

 

接下來部署MHA，具體的搭建環境以下（全部操做系統均爲CentOS7.4 64bit）：

IP地址	主機名	角色	軟件
192.168.3.181	node-181	manager	mha4mysql-manager、mha4mysql-node
192.168.3.182	node-182	master	mha4mysql-node
192.168.3.183	node-183	Slave1,Candicate master	mha4mysql-node
192.168.3.184	node-184	Slave2	mha4mysql-node

 

其中master對外提供寫服務，備選Candicate master（實際爲slave1）提供讀服務，slave2也提供讀服務，一旦master宕機，將會把備選master提高爲新的master，slave指向新的master

 

（1）在全部節點安裝MHA node所需的perl模塊（DBD:mysql），安裝腳本以下：

 

先要安裝epel源，

Centos6安裝源：rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Centos7安裝源：rpm –ivh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-10.noarch.rpm

 

如下設置爲CentOS6操做

[epel]

name=Extra Packages for Enterprise Linux 6 - $basearch

baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch #將註釋的#去掉

#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch#前面加上#

yum clean all

yum list

使用yum安裝

所有依賴

yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager --skip-broken

 

 

（2）上傳MHA相關包，在全部的節點安裝mha-node：

rpm -ivh mha4mysql-node-0.54-0.el6.noarch.rpm

 

安裝完成後會在/usr/bin/目錄下生成如下腳本文件：

 

[root@xuegod67 bin]# pwd

/usr/bin/

[root@xuegod67 bin]# ll app* filter* purge* save*

-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

 

 

2.安裝MHA Manager

 

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

 

（1）安裝MHA Node軟件包以前須要安裝依賴。我這裏使用yum完成，首先epel源要安裝。注意：剛纔咱們已經配置epel源。

 

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

 

yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-CPAN -y

 

安裝MHA Manager軟件包：

[root@xuegod67 ~]# rpm -ivh mha4mysql-manager-0.55-0.el6.noarch.rpm

 

安裝完成後會在/usr/bin目錄下面生成如下腳本文件，前面已經說過這些腳本的做用，這裏再也不重複

 

[root@xuegod67 ~]# ll /usr/bin/mast*

-rwxr-xr-x 1 root root 1995 12月 13 2012 /usr/bin/masterha_check_repl

-rwxr-xr-x 1 root root 1779 12月 13 2012 /usr/bin/masterha_check_ssh

-rwxr-xr-x 1 root root 1865 12月 13 2012 /usr/bin/masterha_check_status

-rwxr-xr-x 1 root root 3201 12月 13 2012 /usr/bin/masterha_conf_host

-rwxr-xr-x 1 root root 2517 12月 13 2012 /usr/bin/masterha_manager

-rwxr-xr-x 1 root root 2165 12月 13 2012 /usr/bin/masterha_master_monitor

-rwxr-xr-x 1 root root 2373 12月 13 2012 /usr/bin/masterha_master_switch

-rwxr-xr-x 1 root root 3879 12月 13 2012 /usr/bin/masterha_secondary_check

-rwxr-xr-x 1 root root 1739 12月 13 2012 /usr/bin/masterha_stop

 

3.配置全部主機相互SSH登陸無密碼驗證（使用key登陸，工做中經常使用）。可是有一點須要注意：不能禁止 password 登錄，不然會出現錯誤

ssh免密碼登陸

[root@xuegod67 ~]# ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): 回車

Enter passphrase (empty for no passphrase): 回車

Enter same passphrase again: 回車

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

e1:9f:7e:15:f1:de:07:d3:33:03:cc:3d:36:0c:96:26 root@xuegod67.cn

The key's randomart image is:

+--[ RSA 2048]----+

|            oo=  |

|           E.*.* |

|        .   o o+o|

|       . .    ++o|

|        S      ==|

|         . .  . +|

|          o  .  .|

|         .  .    |

|          ..     |

+-----------------+

[root@xuegod67 ~]# ssh-copy-id 10.10.10.68

[root@xuegod67 ~]# ssh-copy-id 10.10.10.69

[root@xuegod67 ~]# ssh-copy-id 10.10.10.70

其餘主機重複上面操做。

 

 

4.搭建主從複製環境

 

注意：binlog-do-db 和 replicate-ignore-db 設置必須相同。 MHA 在啓動時候會檢測過濾規則，若是過濾規則不一樣，MHA 不啓動監控和故障轉移。

 

（1）在xuegod68配置主數據庫服務器

 

建立須要同步的數據庫：

mysql> create database HA;

mysql> use HA;

mysql> create table test(id int,name varchar(20));

service mysqld stop

配置my.cnf:

vim /etc/my.cnf

log-bin=mysql-bin-master  #啓用二進制日誌

server-id=1   #本機數據庫ID 標示

binlog-do-db=HA #能夠被從服務器複製的庫。二進制須要同步的數據庫名

binlog-ignore-db=mysql  #不能夠被從服務器複製的庫

validate-password=off

重啓mysql:

systemctl restart mysqld

受權：

mysql> grant replication slave on *.* to repl@'10.10.10.%' identified by '123456';

mysql> flush privileges;

查看狀態信息：

mysql> show master status;

導出數據庫到從服務器(2個從)

mysqldump  -uroot -p123456 –B HA >HA.sql

scp HA.sql 10.10.10.65:/root

scp HA.sql 10.10.10.66:/root

 

（2）在xuegod69導入數據庫並配置從服務：

[root@xuegod69 ~]# mysql -uroot -p123456 <HA.sql

配置my.cnf:

vim /etc/my.cnf

log-bin=mysql-slave1  #啓用二進制日誌

server-id=2   #本機數據庫ID 標示

binlog-do-db=HA #能夠被從服務器複製的庫。二進制須要同步的數據庫名

binlog-ignore-db=mysql  #不能夠被從服務器複製的庫

log_slave_updates=1 #只有開啓log_slave_updates，從庫binlog纔會記錄主庫同步的操做日誌

validate-password=off

[root@xuegod69 ~]# systemctl restart mysqld 重啓mysql

mysql> grant replication slave on *.* to 'repl'@'10.10.10.%' identified by '123456';

mysql> flush privileges;

創建主從關係

mysql> stop slave;

mysql> change master to master_host='10.10.10.68',master_user='repl',master_password='123456';

（3）在xuegod70導入數據庫並配置從服務：

 

[root@xuegod70 ~]# mysql -uroot -p123456 <HA.sql

配置my.cnf:

vim /etc/my.cnf

log-bin=mysql-slave2  #啓用二進制日誌

server-id=3          #本機數據庫ID 標示

binlog-do-db=HA      #能夠被從服務器複製的庫。二進制須要同步的數據庫名

binlog-ignore-db=mysql  #不能夠被從服務器複製的庫

log_slave_updates=1 #只有開啓log_slave_updates，從庫binlog纔會記錄主庫同步的操做日誌

validate-password=off

[root@xuegod70 ~]# systemctl restart mysqld 重啓mysql

mysql> grant replication slave on *.* to 'repl'@'10.10.10.%' identified by '123456';

mysql> flush privileges;

創建主從關係

mysql> stop slave;

mysql> change master to master_host='10.10.10.68',master_user='repl',master_password='123456';

 

（4）兩臺slave服務器設置read_only（從庫對外提供讀服務，只因此沒有寫進配置文件，是由於slave隨時會提高爲master）

 

[root@xuegod69~]# mysql -uroot -p123456 -e 'set global read_only=1'

[root@xuegod70 ~]# mysql -uroot -p123456 -e 'set global read_only=1'

 

（5）建立監控用戶（在主從上都執行）：

 

mysql> grant all privileges on *.* to 'root'@'10.10.10.%' identified  by '123456';

mysql> flush  privileges;

 

到這裏整個集羣環境已經搭建完畢，剩下的就是配置MHA軟件了。

 

5.配置MHA

 

（1）建立MHA的工做目錄，而且建立相關配置文件（在軟件包解壓後的目錄裏面有樣例配置文件）。

 

[root@ xuegod67 ~]# mkdir -p /etc/masterha

[root@ xuegod67 ~]# mkdir -p /var/log/masterha/app1

[root@ xuegod67 ~]# vim  /etc/masterha/app1.cnf

修改app1.cnf配置文件，修改後的文件內容以下（注意，配置文件中的註釋須要去掉，我這裏是爲了解釋清楚）：

 

 [server default]

manager_workdir=/var/log/masterha/app1            //設置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    //設置發生切換後發送的報警的腳本

shutdown_script=""      //設置故障發生後關閉故障主機腳本（該腳本的主要做用是關閉主機放在發生腦裂,這裏沒有使用）

ssh_user=root           //設置ssh的登陸用戶名

 

[server1]

hostname=10.10.10.68

port=3306

 

[server2]

hostname=10.10.10.69

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=10.10.10.70

port=3306

 

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

 

[root@xuegod69 ~]# mysql -uroot -p123456 -e 'set global relay_log_purge=0'

[root@xuegod70 ~]# mysql -uroot -p123456 -e 'set global relay_log_purge=0'

注意：

 

MHA在發生切換的過程當中，從庫的恢復過程當中依賴於relay log的相關信息，因此這裏要將relay log的自動清除設置爲OFF，採用手動清除relay log的方式。在默認狀況下，從服務器上的中繼日誌會在SQL線程執行完畢後被自動刪除。可是在MHA環境中，這些中繼日誌在恢復其餘從服務器時可能會被用到，所以須要禁用中繼日誌的自動刪除功能。按期清除中繼日誌須要考慮到複製延時的問題。在ext3的文件系統下，刪除大的文件須要必定的時間，會致使嚴重的複製延時。爲了不復制延時，須要暫時爲中繼日誌建立硬連接，由於在Linux系統中經過硬連接刪除大文件速度會很快。（在mysql數據庫中，刪除大表時，一般也採用創建硬連接的方式）

 

 

（3）.檢查SSH配置

 

檢查MHA Manger到全部MHA Node的SSH鏈接狀態：

 

 [root@xuegod67~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

 

能夠看見各個節點ssh驗證都是ok的。

 

（4）.檢查整個複製環境情況。

 

經過masterha_check_repl腳本查看整個集羣的狀態

 

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

 

MySQL Replication Health is NOT OK! 若是提示這個不ok，說明有問題

MySQL Replication Health is OK. 顯示Ok ，正常！

 

（5）.檢查MHA Manager的狀態：

 

經過master_check_status腳本查看Manager的狀態：

 

[root@xuegod67 ~]# masterha_check_status --conf=/etc/masterha/app1.cnf

 

app1 is stopped(2:NOT_RUNNING).  

注意：若是正常，會顯示"PING_OK"，不然會顯示"NOT_RUNNING"，這表明MHA監控沒有開啓。

（6）.開啓MHA Manager監控

 

[root@ xuegod67 ~]# 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

 

啓動參數介紹：

 

--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@ xuegod67 ~]# masterha_check_status --conf=/etc/masterha/app1.cnf

app1 (pid:20386) is running(0:PING_OK), master:10.10.10.64

能夠看見已經在監控了，並且master的主機爲10.10.10.64

 

（7）.查看啓動日誌

 

複製代碼

[root@xuegod67 ~]# tail -n20 /var/log/masterha/app1/manager.log  

………………..

…………………

Sun Apr 20 19:12:01 2014 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..

 

其中"Ping(SELECT) succeeded, waiting until MySQL doesn't respond.."說明整個系統已經開始監控了。

 

（8）.關閉MHA Manage監控

 

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

 

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

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

 

（9）模擬故障

 

[root@xuegod67 ~]# tail -f /var/log/masterha/app1/manager.log 打開新窗口觀察日誌

[root@xuegod68~]# service mysqld stop  模擬主庫掛掉

 

看日誌是否切換master成功

From:

10.10.10.68 (current master)

 +--10.10.10.69

 +--10.10.10.70

 

To:

10.10.10.69 (new master)

 +--10.10.10.70

Mon Oct  9 22:02:36 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info] * Phase 3.3: New Master Diff Log Generation Phase..

Mon Oct  9 22:02:36 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.

Mon Oct  9 22:02:36 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info] * Phase 3.4: Master Log Apply Phase..

Mon Oct  9 22:02:36 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.

Mon Oct  9 22:02:36 2017 - [info] Starting recovery on 10.10.10.69(10.10.10.69:3306)..

Mon Oct  9 22:02:36 2017 - [info]  This server has all relay logs. Waiting all logs to be applied..

Mon Oct  9 22:02:36 2017 - [info]   done.

Mon Oct  9 22:02:36 2017 - [info]  All relay logs were successfully applied.

Mon Oct  9 22:02:36 2017 - [info] Getting new master's binlog name and position..

Mon Oct  9 22:02:36 2017 - [info]  mysql-slave1.000001:598

Mon Oct  9 22:02:36 2017 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.10.10.69', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-slave1.000001', MASTER_LOG_POS=598, MASTER_USER='repl', MASTER_PASSWORD='xxx';

Mon Oct  9 22:02:36 2017 - [warning] master_ip_failover_script is not set. Skipping taking over new master ip address.

Mon Oct  9 22:02:36 2017 - [info] Setting read_only=0 on 10.10.10.69(10.10.10.69:3306)..

Mon Oct  9 22:02:36 2017 - [info]  ok.

Mon Oct  9 22:02:36 2017 - [info] ** Finished master recovery successfully.

Mon Oct  9 22:02:36 2017 - [info] * Phase 3: Master Recovery Phase completed.

Mon Oct  9 22:02:36 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info] * Phase 4: Slaves Recovery Phase..

Mon Oct  9 22:02:36 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info] * Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..

Mon Oct  9 22:02:36 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info] -- Slave diff file generation on host 10.10.10.70(10.10.10.70:3306) started, pid: 2923. Check tmp log /etc/masterha/app1/10.10.10.70_3306_20171009220233.log if it takes time..

Mon Oct  9 22:02:37 2017 - [info]

Mon Oct  9 22:02:37 2017 - [info] Log messages from 10.10.10.70 ...

Mon Oct  9 22:02:37 2017 - [info]

Mon Oct  9 22:02:36 2017 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.

Mon Oct  9 22:02:37 2017 - [info] End of log messages from 10.10.10.70.

Mon Oct  9 22:02:37 2017 - [info] -- 10.10.10.70(10.10.10.70:3306) has the latest relay log events.

Mon Oct  9 22:02:37 2017 - [info] Generating relay diff files from the latest slave succeeded.

Mon Oct  9 22:02:37 2017 - [info]

Mon Oct  9 22:02:37 2017 - [info] * Phase 4.2: Starting Parallel Slave Log Apply Phase..

Mon Oct  9 22:02:37 2017 - [info]

Mon Oct  9 22:02:37 2017 - [info] -- Slave recovery on host 10.10.10.70(10.10.10.70:3306) started, pid: 2925. Check tmp log /etc/masterha/app1/10.10.10.70_3306_20171009220233.log if it takes time..

Mon Oct  9 22:02:38 2017 - [info]

Mon Oct  9 22:02:38 2017 - [info] Log messages from 10.10.10.70 ...

Mon Oct  9 22:02:38 2017 - [info]

Mon Oct  9 22:02:37 2017 - [info] Starting recovery on 10.10.10.70(10.10.10.70:3306)..

Mon Oct  9 22:02:37 2017 - [info]  This server has all relay logs. Waiting all logs to be applied..

Mon Oct  9 22:02:37 2017 - [info]   done.

Mon Oct  9 22:02:37 2017 - [info]  All relay logs were successfully applied.

Mon Oct  9 22:02:37 2017 - [info]  Resetting slave 10.10.10.70(10.10.10.70:3306) and starting replication from the new master 10.10.10.69(10.10.10.69:3306)..

Mon Oct  9 22:02:38 2017 - [info]  Executed CHANGE MASTER.

Mon Oct  9 22:02:38 2017 - [info]  Slave started.

Mon Oct  9 22:02:38 2017 - [info] End of log messages from 10.10.10.70.

Mon Oct  9 22:02:38 2017 - [info] -- Slave recovery on host 10.10.10.70(10.10.10.70:3306) succeeded.

Mon Oct  9 22:02:38 2017 - [info] All new slave servers recovered successfully.

Mon Oct  9 22:02:38 2017 - [info]

Mon Oct  9 22:02:38 2017 - [info] * Phase 5: New master cleanup phase..

Mon Oct  9 22:02:38 2017 - [info]

Mon Oct  9 22:02:38 2017 - [info] Resetting slave info on the new master..

Mon Oct  9 22:02:38 2017 - [info]  10.10.10.69: Resetting slave info succeeded.

Mon Oct  9 22:02:38 2017 - [info] Master failover to 10.10.10.69(10.10.10.69:3306) completed successfully.

Mon Oct  9 22:02:38 2017 - [info] Deleted server1 entry from /etc/masterha/app1.conf .

Mon Oct  9 22:02:38 2017 - [info]

 

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

 

app1: MySQL Master failover 10.10.10.68 to 10.10.10.69 succeeded

 

Master 10.10.10.68 is down!

 

Check MHA Manager logs at xuegod67.cn:/var/log/masterha/app1/manager.log for details.

 

Started automated(non-interactive) failover.

The latest slave 10.10.10.69(10.10.10.69:3306) has all relay logs for recovery.

Selected 10.10.10.69 as a new master.

10.10.10.69: OK: Applying all logs succeeded.

10.10.10.70: This host has the latest relay log events.

Generating relay diff files from the latest slave succeeded.

10.10.10.70: OK: Applying all logs succeeded. Slave started, replicating from 10.10.10.69.

10.10.10.69: Resetting slave info succeeded.

Master failover to 10.10.10.69(10.10.10.69:3306) completed successfully.

 

咱們從日誌上能夠看到故障切換成功，恭喜你了.新的master是xuegod69.

登錄從服務器xuegod70查看show slave status\G是否成功切換

 

 

 

總結：

 

目前高可用方案能夠必定程度上實現數據庫的高可用，還有其餘方案heartbeat+drbd，Cluster、MGR等。這些高可用軟件各有優劣。在進行高可用方案選擇時，主要是看業務還有對數據一致性方面的要求。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

………………………………………………….我是MHA分割線……………………………………………………………………

 

 

 

 

/etc/masterha/app1.cnf 配置文件備份

[server default]

manager_workdir=/var/log/masterha/app1

manager_log=/var/log/masterha/app1/manager.log

master_binlog_dir=/var/lib/mysql

user=root

password=123456

ping_interval=1

remote_workdir=/tmp

repl_user=repl

repl_password=123456

ssh_user=root

 

[server1]

hostname=10.10.10.68

port=3306

 

[server2]

hostname=10.10.10.69

port=3306

candidate_master=1

check_repl_delay=0

 

[server3]

hostname=10.10.10.70

port=3306

 

擴展：

關於配置VIP配合MHA使用

vip配置能夠採用兩種方式，一種經過keepalived的方式管理虛擬ip的浮動；另一種經過腳本方式啓動虛擬ip的方式（即不須要keepalived或者heartbeat相似的軟件）。

 

關於keepalived方式我這裏不講了，由於爲了防止腦裂發生，推薦生產環境採用腳本的方式來管理虛擬ip，而不是使用keepalived來完成。自行腦補百度或者參考http://www.cnblogs.com/gomysql/p/3675429.html

下面是經過腳本的方式管理VIP。這裏是修改/usr/local/bin/master_ip_failover，修改完成後內容以下，並且若是使用腳本管理vip的話，須要手動在master服務器上綁定一個vip

編寫腳本/usr/ /bin/master_ip_failover，要會perl腳本語言（主庫上操做，xuegod68）。

 

在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() {

    `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";

}