|
MHA，即Master High Availability Manager and Tools for MySQL，是日本的一位MySQL專家采用Perl語言編寫的一個腳本管理工具，該工具僅適用于MySQL Replication（二層）環(huán)境，目的在于維持Master主庫的高可用性。 一、簡介學習一個高可用小軟件，不但要熟悉其功能，還要了解其架構(gòu)及工作原理。 1. 架構(gòu)從架構(gòu)上來說，MHA分為如下兩大部分： （1） Node 我們知道，MHA是基于MySQL Replication環(huán)境的，在該環(huán)境中，不管是Master角色，還是Slave角色，都稱為Node，是被監(jiān)控管理的對象節(jié)點。 Node服務(wù)器上需要安裝MHA Node包。 （2） Manager Manager為MHA架構(gòu)中的管理者，建議部署在一臺獨立的服務(wù)器上，當然也可部署在某個Slave上，但該Slave永遠不要被選擇成為新的Master，否則故障切換后的MHA架構(gòu)就失去了高可用性。 Manager服務(wù)器需要安裝MHA Manager包，并完善一個主配置文件。 一個Manager可管理多套MySQL Replication環(huán)境。 2. 工作原理相較于其它HA軟件，MHA的目的在于維持MySQL Replication中Master庫的高可用性，其最大特點是可以修復(fù)多個Slave之間的差異日志，最終使所有Slave保持數(shù)據(jù)一致，然后從中選擇一個充當新的Master，并將其它Slave指向它。 基本工作流程大致如下： （1） Manager定期監(jiān)控Master，監(jiān)控時間間隔由參數(shù)ping_interval決定，缺省為3秒鐘一次；可利用其自身的監(jiān)控功能，也可調(diào)用第三方軟件來監(jiān)控；MHA自身提供了兩種監(jiān)控方式：SELECT（執(zhí)行SELECT 1）和CONNECT（創(chuàng)建連接/斷開連接），由于參數(shù)ping_type決定，缺省為SELECT方式。 （2） 當監(jiān)測到Master故障時，調(diào)用SSH腳本對所有Node執(zhí)行一次檢查，包括如下幾個方面： ――MySQL實例是否可以連接； ――Master服務(wù)器是否可以SSH連通； ――檢查SQL Thread的狀態(tài)； ――檢查哪些Server死掉了，哪些Server是活動的，以及活動的Slave實例； ――檢查Slave實例的配置及復(fù)制過濾規(guī)則； ――最后退出監(jiān)控腳本并返回代表特殊意義代碼。 （3） 開始Master故障切換，包括如下幾個子階段： ――Phase 1: Configuration Check Phase 在這個階段，若某個Slave實例的SQL Thread停止了，則會自動啟動它；并再次確認活動的Servers及Slaves。 ――Phase 2: Dead Master Shutdown Phase 在這個階段，首先調(diào)用master_ip_failover_script，若HA是基于VIP實現(xiàn)的，則關(guān)閉VIP，若是基于目錄數(shù)據(jù)庫實現(xiàn)的，則修改映射記錄。 然后調(diào)用shutdown_script腳本強制關(guān)閉主機，以避免服務(wù)重啟時，發(fā)生腦裂。 ――Phase 3: Master Recovery Phase 又包括如下3個子階段： Phase 3.1: Getting Latest Slaves Phase 檢查各個Slave，獲取最近的和最舊的binary log file和position，并檢查各個Slave成為Master的優(yōu)先級，依賴于candidate_master、no_master、[server_xxx]順序、binary log差異量等因素。 Phase 3.2: Saving Dead Master's Binlog Phase 若dead master所在服務(wù)器依然可以通過SSH連通，則提取dead master的binary log，提取日志的起點就是上一步獲取的最新的binary log file和position，直到最后一條事件日志，并在dead master本地的工作目錄（由參數(shù)remote_workdir決定）中創(chuàng)建文件保存這些提取到的日志，然后將該文件拷貝到Manager服務(wù)器的工作目錄下（由參數(shù)manager_workdir決定）。 當然，若dead master系統(tǒng)就無法連接，也就不存在差異的binary log了。 另外，MHA還要對各個Slave節(jié)點進行健康檢查，主要是SSH連通性。 Phase 3.3: Determining New Master Phase 接下來調(diào)用apply_diff_relay_logs命令恢復(fù)Slave的差異日志，這個差異日志指的是各個Slave之間的relay log。 恢復(fù)完成后，所有的Slave數(shù)據(jù)是一致的，此時就可以根據(jù)優(yōu)先級選擇New Master了。 Phase 3.3: New Master Diff Log Generation Phase 這里是生成dead master和new master之間的差異日志，即將Phase 3.2保存的binary log拷貝到New Master的工作目錄中（remote_workdir）。 Phase 3.4: Master Log Apply Phase 將上一步拷貝的差異日志恢復(fù)到New Master上，若發(fā)生錯誤，也可手動恢復(fù)。 然后獲取New Master的binlog name和position，以便其它Slave從這個新的binlog name和position開始復(fù)制。 最后會開啟New Master的寫權(quán)限，即將read_only參數(shù)設(shè)置為0。 ――Phase 4: Slaves Recovery Phase Phase 4.1: Starting Parallel Slave Diff Log Generation Phase 生成Slave與New Slave之間的差異日志，并將該日志拷貝到各Slave的工作目錄下，這部分日志dead master和new master之間差異的那部分日志，因為各個Slave在Phase 3.3階段已經(jīng)同步了。 Phase 4.2: Starting Parallel Slave Log Apply Phase 在各個Slave上應(yīng)用這部分差異日志，然后通過CHANGE MASTER TO命令將這些Slave指向新的New Master，最后開始復(fù)制(start slave)。 ――Phase 5: New master cleanup phase 清理New Master其實就是重置slave info，即取消原來的Slave信息。 至此整個Master故障切換過程完成。 3. 功能從官方網(wǎng)站的介紹來看，MHA具有如下幾個功能： （1） Master自動監(jiān)控和故障轉(zhuǎn)移 基于現(xiàn)有的MySQL主從復(fù)制環(huán)境，MHA可以監(jiān)控Master，當發(fā)現(xiàn)其故障時，自動進行切換。 在多個Slave環(huán)境中，如果個別Slave沒有接受到最新的relay log events，MHA則會自動從最新的那個Slave上查找差異的relay log events，并將這些差異事件應(yīng)用到有延遲的Slave上，最終保持所有的Slave數(shù)據(jù)一致。通常情況下，MHA可在9-12秒內(nèi)監(jiān)測到Master故障，7-10秒內(nèi)關(guān)閉主機以避免腦裂，然后花費幾秒時間應(yīng)用差異的relay log，整個過程通常只需10－30秒即可完成。 既然MHA可以自動修復(fù)多個Slaves之間的差異日志，所以不用擔心數(shù)據(jù)一致性問題。當Master故障時，MHA會從多個Slave中隨機選擇一個充當新的Master；當然，也可在配置文件中指定某一個Slave優(yōu)先成為Master。 （2） 互動（手動）Master故障轉(zhuǎn)移 可以只使用MHA的故障轉(zhuǎn)移功能，而不監(jiān)控Master，當其故障時，手動調(diào)用MHA來進行故障切換。 （3）非交互式自動故障轉(zhuǎn)移 MHA還支持非交互式的Master故障切換（不監(jiān)控Master，但實現(xiàn)自動故障切換），這個特性其實是將Master的監(jiān)控和VIP接管交給第三方工具來做，比如Heartbeat，MHA只負責Master故障轉(zhuǎn)移和Slave之間的數(shù)據(jù)同步。 （4） 在線切換Master到不同的主機 在有些情況下，比如更換Raid控制器，升級主機硬件等，則需要將其上的Master實例遷移到其它主機上，MHA支持快速的Master切換和短暫的寫操作阻塞，通常只需0.5－2秒的downtime，這是可以接受的，也方便了DBA的操作。 二、搭建環(huán)境系統(tǒng)環(huán)境 OS：CentOS 5.8 (x86_64) 內(nèi)核：2.6.18-308.el5 DB：MySQL 5.5.17 hostname IP MySQL Role MHA Role node1 192.168.3.27 master node
node2 192.168.3.28 slave1 （備用） node
node3 192.168.3.25 slave2 node
mmm 192.168.3.26 manager 1.安裝MHAMHA的安裝包也包括Manager和Node兩部分，其中Node包不但要在所有的Node節(jié)點上安裝，而且還需在Manager節(jié)點上安裝，因為Manager模塊內(nèi)部依賴Node模塊，
Manager包則只需在Manager節(jié)點安裝即可。
從MHA官網(wǎng)http://code.google.com/p/mysql-master-ha/downloads/list下載合適的安裝包，可以是源碼包，也可以是RPM包，本例采用RPM包，如下：
Manager包：mha4mysql-manager-0.55-1.el5.noarch.rpm
Node包：mha4mysql-node-0.54-1.el5.noarch.rpm MHA是采用perl語言編寫的一個腳本管理工具，所以需要安裝一系列perl依賴包。 1、在所有節(jié)點上安裝perl語言依賴包
# rpm -ivh MySQL-shared-compat-5.5.17-1.rhel5.x86_64.rpm
# rpm -ivh perl-DBI-1.52-2.el5.x86_64.rpm
# rpm -ivh perl-DBD-MySQL-3.0007-2.el5.x86_64.rpm (以下依賴包為Manager節(jié)點需要）
# rpm -ivh perl-Params-Validate-0.95-1.el5.rf.x86_64.rpm
# rpm -ivh perl-Log-Dispatch-2.26-1.el5.rf.noarch.rpm
# rpm -ivh perl-Config-Tiny-2.12-1.el5.rf.noarch.rpm
# rpm -ivh perl-Parallel-ForkManager-0.7.5-2.2.el5.rf.noarch.rpm 在所有節(jié)點及manager上安裝node包
# rpm -ivh mha4mysql-node-0.54-1.el5.noarch.rpm 在manager節(jié)點上安裝manager包
# rpm -ivh mha4mysql-manager-0.55-1.el5.noarch.rpm
成功安裝后，會在/usr/bin目錄下生成如下一系列命令工具：
/usr/bin/masterha_check_repl
/usr/bin/masterha_conf_host
/usr/bin/masterha_master_switch
/usr/bin/masterha_check_ssh
/usr/bin/masterha_manager
/usr/bin/masterha_secondary_check
/usr/bin/masterha_check_status
/usr/bin/masterha_master_monitor
/usr/bin/masterha_stop
2.配置MHA接下來就可以配置MHA配置文件了，只需在Manager服務(wù)器上操作；RPM包安裝時，缺省不會生成該配置文件，可手動生成，也可從MHA Manager源碼安裝包中查找配置文件模板，及一系列調(diào)用腳本。 創(chuàng)建工作目錄
在Node上創(chuàng)建一個單獨的工作目錄，用于remote_workdir參數(shù)來存放相關(guān)日志文件，缺省為/var/tmp，若未創(chuàng)建，MHA也會自動創(chuàng)建，但這需要有創(chuàng)建權(quán)限。
# mkdir -p /mha/appl
在Manager上創(chuàng)建工作目錄，用于manager_workdir參數(shù)，其中存放日志文件和一系列腳本文件等。
# mkdir -p /mha/appl
# mkdir -p /mha/scripts 配置masterha_default.cnf文件
這是全局配置文件，缺省為/etc/masterha_default.cnf，適用于一個Manager管理多套MySQL Replication的情況，在[server_default]下定義一些多套復(fù)制環(huán)境通用的Global Scope類型的參數(shù)。本例只有一套MySQL Replication，所以也可不用配置該文件，而是在對應(yīng)的應(yīng)用配置文件（appl.conf）下的[server_default]中定義相關(guān)參數(shù)。
執(zhí)行MHA相關(guān)命令時，會在/etc目錄下搜索該配置文件，若找不到，雖然不會有什么錯誤，但會給出一個警告，如“[warning] Global configuration file /etc/masterha_default.cnf not found.”。
為此可以在/etc目錄下創(chuàng)建一個名為masterha_default.cnf的空文件，本例不打算這么做，而是在其中配置一些通用的[server_default]類參數(shù)，如下： # vi /etc/masterha_default.cnf
[server default]
user = root
password = mysql --mysql密碼
ssh_user = root
repl_user = repl
repl_password = repl_pwd
ping_interval = 3
ping_type = SELECT
配置appl.conf文件
這是針對每一套MySQL Replication應(yīng)用專門的配置文件，若管理多套MySQL Replication，可配置多個文件，其中包括[server_default]和[server_xxx]兩個項目，分別用于配置App Scope、Local Scope類型的參數(shù)。
# vi /etc/appl.cnf
[server default]
manager_workdir = /mha/appl
manager_log = /mha/appl/manager.log
remote_workdir = /mha/appl #master_ip_failover_script=/mha/scripts/master_ip_failover [server1]
hostname = 192.168.3.27
master_binlog_dir = /data/lib/mysql
candidate_master = 1 [server2]
hostname = 192.168.3.28
master_binlog_dir = /data/lib/mysql
candidate_master =1 [server3]
hostname = 192.168.3.25
no_master = 1 3.配置SSH等效連接因為MHA管理節(jié)點以及各個Node節(jié)點之間需要無密碼登錄并執(zhí)行相關(guān)腳本，所以需要配置各個節(jié)點之間的SSH等效性，如下：
――生成密鑰文件（各個節(jié)點均需執(zhí)行） # mkdir -p ~/.ssh
# cd .ssh
# /usr/bin/ssh-keygen -t rsa （提示處直接回車即可）
# /usr/bin/ssh-keygen -t dsa （提示處直接回車即可）
執(zhí)行完成后，在/root/.ssh 目錄下會生產(chǎn)四個密鑰文件。 ――任意一個節(jié)點執(zhí)行即可（本例選擇在manager節(jié)點執(zhí)行） # ssh 192.168.3.27 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.27 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.28 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.28 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.25 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.25 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.26 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.26 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# scp ~/.ssh/authorized_keys 192.168.3.27:.ssh/
# scp ~/.ssh/authorized_keys 192.168.3.28:.ssh/
# scp ~/.ssh/authorized_keys 192.168.3.25:.ssh/ ――修改authorized_keys文件的權(quán)限為600（所有節(jié)點均需執(zhí)行）
# chmod 600 ~/.ssh/authorized_keys ――測試一下
在各節(jié)點執(zhí)行如下命令，測試一下，看是否不提示密碼即可顯示，否則則說明SSH配置不成功。
# ssh 192.168.3.26 hostname
# ssh 192.168.3.26 date 另外，還可采用MHA提供的工具命令來檢查，如下：
[root@mmm .ssh]# /usr/bin/masterha_check_ssh --conf=/etc/appl.cnf
Fri Jul 18 16:52:12 2014 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Fri Jul 18 16:52:12 2014 - [info] Reading application default configurations from /etc/appl.cnf..
Fri Jul 18 16:52:12 2014 - [info] Reading server configurations from /etc/appl.cnf..
Fri Jul 18 16:52:12 2014 - [info] Starting SSH connection tests..
Fri Jul 18 16:52:13 2014 - [debug]
Fri Jul 18 16:52:12 2014 - [debug] Connecting via SSH from root@192.168.3.27(192.168.3.27:22) to root@192.168.3.28(192.168.3.28:22)..
Fri Jul 18 16:52:12 2014 - [debug] ok.
Fri Jul 18 16:52:12 2014 - [debug] Connecting via SSH from root@192.168.3.27(192.168.3.27:22) to root@192.168.3.25(192.168.3.25:22)..
Fri Jul 18 16:52:12 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug]
Fri Jul 18 16:52:12 2014 - [debug] Connecting via SSH from root@192.168.3.28(192.168.3.28:22) to root@192.168.3.27(192.168.3.27:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug] Connecting via SSH from root@192.168.3.28(192.168.3.28:22) to root@192.168.3.25(192.168.3.25:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug]
Fri Jul 18 16:52:13 2014 - [debug] Connecting via SSH from root@192.168.3.25(192.168.3.25:22) to root@192.168.3.27(192.168.3.27:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug] Connecting via SSH from root@192.168.3.25(192.168.3.25:22) to root@192.168.3.28(192.168.3.28:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [info] All SSH connection tests passed successfully. 從中可以看到，該命令會從應(yīng)用配置文件中讀取相關(guān)信息（IP和SSH_USER），然后在各個Node之間相互驗證，保證可以通過SSH方式相互登錄（用于同步差異日志）。 4.配置hosts解析這一步的目的是在hostname和ip之間提供一個解析途徑，配置方法很簡單，就是將各個節(jié)點的主機名及對應(yīng)的IP地址寫入/etc/hosts文件，所有節(jié)點均需配置，且保持一致，如下：
# vi /etc/hosts
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.3.27 node1
192.168.3.28 node2
192.168.3.25 node3
192.168.3.26 mmm
為了省事，在一個節(jié)點配置，然后拷貝到其它節(jié)點即可；配置完成后，可以相互ping一下主機名，看能否成功解析。
5.搭建MySQL主從復(fù)制
按照規(guī)劃，在node1、node2、node3上安裝MySQL數(shù)據(jù)庫，并搭建成一主二從的MySQL Replication結(jié)構(gòu)；具體操作不做說明了，可參考http://blog.csdn.net/dbaxiaosa/article/details/22421969 對于MHA來說，搭建MySQL Replication需要注意以下幾點：
read_only――是否限制Slave實例為只讀狀態(tài)，缺省為0，即不限制，MHA要求設(shè)置為1。
relay_log_purge――這個參數(shù)用于限制中繼日志應(yīng)用完之后是否刪除，缺省為1，即應(yīng)用完之后立即刪除；在MHA中，Manager就是通過這些日志來同步各個Slave之間的數(shù)據(jù)差異的，所以必須設(shè)置為0，即不刪除中繼日志。
log_bin――是否開啟二進制日志，若某個Slave可能被選擇成為新的Master，則必須開啟；若某個Slave被限制永遠不會成為新的Master，可以不用開啟。 成功搭建后，通過MHA命令檢查一下，確保無誤。 [root@mmm scripts]# /usr/bin/masterha_check_repl --conf=/etc/appl.cnf
Mon Jul 21 10:40:12 2014 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Mon Jul 21 10:40:12 2014 - [info] Reading application default configurations from /etc/appl.cnf..
Mon Jul 21 10:40:12 2014 - [info] Reading server configurations from /etc/appl.cnf..
Mon Jul 21 10:40:12 2014 - [info] MHA::MasterMonitor version 0.55.
Mon Jul 21 10:40:12 2014 - [info] Dead Servers:
Mon Jul 21 10:40:12 2014 - [info] Alive Servers:
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.28(192.168.3.28:3306)
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.25(192.168.3.25:3306)
Mon Jul 21 10:40:12 2014 - [info] Alive Slaves:
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.28(192.168.3.28:3306) Version=5.5.17-log (oldest major version between slaves) log-bin:enabled
Mon Jul 21 10:40:12 2014 - [info] Replicating from 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] Primary candidate for the new Master (candidate_master is set)
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.25(192.168.3.25:3306) Version=5.5.17 (oldest major version between slaves) log-bin:disabled
Mon Jul 21 10:40:12 2014 - [info] Replicating from 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] Not candidate for the new Master (no_master is set)
Mon Jul 21 10:40:12 2014 - [info] Current Alive Master: 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] Checking slave configurations..
Mon Jul 21 10:40:12 2014 - [warning] relay_log_purge=0 is not set on slave 192.168.3.28(192.168.3.28:3306).
Mon Jul 21 10:40:12 2014 - [warning] log-bin is not set on slave 192.168.3.25(192.168.3.25:3306). This host can not be a master.
Mon Jul 21 10:40:12 2014 - [info] Checking replication filtering settings..
Mon Jul 21 10:40:12 2014 - [info] binlog_do_db= , binlog_ignore_db=
Mon Jul 21 10:40:12 2014 - [info] Replication filtering check ok.
Mon Jul 21 10:40:12 2014 - [info] Starting SSH connection tests..
Mon Jul 21 10:40:13 2014 - [info] All SSH connection tests passed successfully.
Mon Jul 21 10:40:13 2014 - [info] Checking MHA Node version..
Mon Jul 21 10:40:14 2014 - [info] Version check ok.
Mon Jul 21 10:40:14 2014 - [info] Checking SSH publickey authentication settings on the current master..
Mon Jul 21 10:40:14 2014 - [info] HealthCheck: SSH to 192.168.3.27 is reachable.
Mon Jul 21 10:40:14 2014 - [info] Master MHA Node version is 0.54.
Mon Jul 21 10:40:14 2014 - [info] Checking recovery script configurations on the current master..
Mon Jul 21 10:40:14 2014 - [info] Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data/lib/mysql --output_file=/mha/appl/save_binary_logs_test --manager_version=0.55 --start_file=mysql-bin.000004
Mon Jul 21 10:40:14 2014 - [info] Connecting to root@192.168.3.27(192.168.3.27)..
Creating /mha/appl if not exists.. ok.
Checking output directory is accessible or not..
ok.
Binlog found at /data/lib/mysql, up to mysql-bin.000004
Mon Jul 21 10:40:14 2014 - [info] Master setting check done.
Mon Jul 21 10:40:14 2014 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Mon Jul 21 10:40:14 2014 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='root' --slave_host=192.168.3.28 --slave_ip=192.168.3.28 --slave_port=3306 --workdir=/mha/appl --target_version=5.5.17-log --manager_version=0.55 --relay_log_info=/data/lib/mysql/relay-log.info --relay_dir=/data/lib/mysql/ --slave_pass=xxx
Mon Jul 21 10:40:14 2014 - [info] Connecting to root@192.168.3.28(192.168.3.28:22)..
Checking slave recovery environment settings..
Opening /data/lib/mysql/relay-log.info ... ok.
Relay log found at /data/lib/mysql, up to mysql-relay-bin.000006
Temporary relay log file is /data/lib/mysql/mysql-relay-bin.000006
Testing mysql connection and privileges.. done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Mon Jul 21 10:40:14 2014 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='root' --slave_host=192.168.3.25 --slave_ip=192.168.3.25 --slave_port=3306 --workdir=/mha/appl --target_version=5.5.17 --manager_version=0.55 --relay_log_info=/data/lib/mysql/relay-log.info --relay_dir=/data/lib/mysql/ --slave_pass=xxx
Mon Jul 21 10:40:14 2014 - [info] Connecting to root@192.168.3.25(192.168.3.25:22)..
Creating directory /mha/appl.. done.
Checking slave recovery environment settings..
Opening /data/lib/mysql/relay-log.info ... ok.
Relay log found at /data/lib/mysql, up to mysql-relay-bin.000008
Temporary relay log file is /data/lib/mysql/mysql-relay-bin.000008
Testing mysql connection and privileges.. done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Mon Jul 21 10:40:15 2014 - [info] Slaves settings check done.
Mon Jul 21 10:40:15 2014 - [info]
192.168.3.27 (current master)
+--192.168.3.28
+--192.168.3.25 Mon Jul 21 10:40:15 2014 - [info] Checking replication health on 192.168.3.28..
Mon Jul 21 10:40:15 2014 - [info] ok.
Mon Jul 21 10:40:15 2014 - [info] Checking replication health on 192.168.3.25..
Mon Jul 21 10:40:15 2014 - [info] ok.
Mon Jul 21 10:40:15 2014 - [warning] master_ip_failover_script is not defined.
Mon Jul 21 10:40:15 2014 - [warning] shutdown_script is not defined.
Mon Jul 21 10:40:15 2014 - [info] Got exit code 0 (Not master dead). MySQL Replication Health is OK. 注：如果有錯誤，根據(jù)檢查的錯誤提示，進行相應(yīng)的修改設(shè)置()。 從中可以看出，該命令首先從主配置文件和應(yīng)用配置文件中讀取相關(guān)參數(shù)，然后檢查各個Slave的狀態(tài)、參數(shù)配置、SSH連通性、執(zhí)行save_binary_logs、apply_diff_relay_logs命令等操作，確保最后的提示為“MySQL Replication Health is OK”，否則需要重新檢查MySQL Replication配置。
另外，其中給出了兩個警告，提示沒有定義master_ip_failover_script、shutdown_script，這個暫且不管，在后面環(huán)節(jié)再詳細說明。 三、測試經(jīng)過上面一系列步驟，成功搭建及配置了MHA，下面我們就來簡單試用一下，并進行一下功能測試。 1.命令工具MHA提供的命令工具包括Manager工具和Node工具，簡單介紹如下：
Manager工具
/usr/bin/masterha_check_repl ――檢查MySQL Replication是否正常；
/usr/bin/masterha_conf_host ――添加或刪除配置的Server信息；
/usr/bin/masterha_master_switch ――用于手動Master切換；
/usr/bin/masterha_check_ssh ――檢查各個Node之間SSH登錄是否正常；
/usr/bin/masterha_manager ――開啟MHA
/usr/bin/masterha_secondary_check ――檢查多路由配置；
/usr/bin/masterha_check_status ――檢查MHA是否開啟并正常運行；
/usr/bin/masterha_master_monitor ――手動開啟監(jiān)控，啟動MHA時會自動啟動監(jiān)控
/usr/bin/masterha_stop ――關(guān)閉MHA
Node工具
/usr/bin/save_binary_logs ――保存和復(fù)制master的二進制日志；
/usr/bin/apply_diff_relay_logs ――識別差異的中繼日志事件并應(yīng)用于其它Slave；
/usr/bin/filter_mysqlbinlog ――去除不必要的Rollback事件（MHA已不再使用該工具）；
/usr/bin/purge_relay_logs ――清除中繼日志（不會阻塞SQL線程）；
備注：Node端工具通常由MHA Manager的腳本觸發(fā)調(diào)用，無需DBA操作。 2.開啟MHA在開啟MHA之前，可以先通過masterha_check_repl檢查一下MySQL Replication是否正常，通過masterha_check_ssh檢查一下各個node之間SSH登錄是否正常，這在前面均已試用該命令。
開啟MHA的命令為masterha_manager，其用法如下：
[root@mmm scripts]# /usr/bin/masterha_manager --help
Usage:
masterha_manager --global_conf=/etc/masterha_default.cnf
--conf=/usr/local/masterha/conf/app1.cnf See online reference
(http://code.google.com/p/mysql-master-ha/wiki/masterha_manager) for
details. 可見其只有兩個參數(shù)，--global_conf缺省為/etc/masterha_default.cnf，本例中符合缺省要求，所以可以不指定，為了方便，通過如下命令使其后臺運行。如下：
[root@mmm appl]# /usr/bin/masterha_manager --conf=/etc/appl.cnf &
[1] 5674
[root@mmm appl]# Mon Jul 21 10:56:32 2014 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Mon Jul 21 10:56:32 2014 - [info] Reading application default configurations from /etc/appl.cnf..
Mon Jul 21 10:56:32 2014 - [info] Reading server configurations from /etc/appl.cnf.. 為了使MHA持續(xù)運行在服務(wù)器端，可通過如下命令使其不掛起運行在后臺： [root@mmm appl]# nohup /usr/bin/masterha_manager --conf=/etc/appl.cnf &
[1] 5905
[root@mmm appl]# nohup: appending output to `nohup.out' MHA開啟之后，會在其工作目錄下生成如下兩個文件：
[root@mmm appl]# ls
appl.master_status.health manager.log 其中appl.master_status.health為Master實例的健康監(jiān)控文件，MHA開啟時生成，關(guān)閉后消失，里面內(nèi)容如下：
[root@mmm appl]# more appl.master_status.health
5674 0:PING_OK master:192.168.3.27 而manager.log為MHA的日志文件，其內(nèi)容較多，執(zhí)行masterha_check_repl命令時的輸入內(nèi)容類似。 可通過masterha_check_status命令檢查MHA是否在運行，比如：
[root@mmm appl]# /usr/bin/masterha_check_status --conf=/etc/appl.cnf
appl (pid:5905) is running(0:PING_OK), master:192.168.3.27 若MHA正常運行，則提示如上，否則提示：appl is stopped(2:NOT_RUNNING). 對于一個正在運行的MHA，可通過masterha_stop命令關(guān)閉，如下：
[root@mmm appl]# /usr/bin/masterha_check_status --conf=/etc/appl.cnf
appl is stopped(2:NOT_RUNNING). 3.Master自動故障轉(zhuǎn)移及差異日志恢復(fù)》模擬復(fù)制不同步，造成數(shù)據(jù)差異
――關(guān)閉node3的復(fù)制線程，然后在Master主庫（node1）上創(chuàng)建一張表，以此造成node3數(shù)據(jù)不同步 mysql> stop slave;
Query OK, 0 rows affected (0.01 sec) mysql> use test;
Database changed
mysql> CREATE TABLE student(s_id INT,s_name VARCHAR(10),PRIMARY KEY(s_id));
Query OK, 0 rows affected (0.01 sec) ――關(guān)閉node2的復(fù)制進線程，
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec) mysql> insert into student(s_id,s_name) values(1,'aaa');
Query OK, 1 row affected (0.01 sec) 通過這個模擬，現(xiàn)在node1（Master）上有一張student表，并有一條數(shù)據(jù)；node2（slave1）上有student這張表，但里面沒有數(shù)據(jù)；node3（slave2）上還沒有student這張表，所以這套復(fù)制環(huán)境的3個節(jié)點目前是不同步的。
》關(guān)閉node1（Master）的mysqld進程，模擬MySQL實例故障
[root@node1 data]# service mysql stop;
Shutting down MySQL... [ OK ]
此時檢查node2，發(fā)現(xiàn)已恢復(fù)了差異數(shù)據(jù)（一條記錄），停掉了原來的復(fù)制線程，被選擇為新的Master，并賦予寫操作權(quán)限。
mysql> select * from student;
+------+--------+
| s_id | s_name |
+------+--------+
| 1 | aaa |
+------+--------+
1 row in set (0.00 sec) mysql> show slave status \G;
Empty set (0.00 sec) mysql> show variables like 'read_only%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only | OFF |
+---------------+-------+
1 row in set (0.00 sec) 檢查node3，發(fā)現(xiàn)差異數(shù)據(jù)也被恢復(fù)（student表和一條記錄），并將master_host指向新的Master（node2） mysql> use test;
Database changed
mysql> select * from student;
+------+--------+
| s_id | s_name |
+------+--------+
| 1 | aaa |
+------+--------+
1 row in set (0.00 sec) mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.3.28 （這里指向了新的master：node2）
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 520069
Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 520069
Relay_Log_Space: 409
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 28
1 row in set (0.00 sec) 從中可以看到，當MHA監(jiān)控到Master實例故障時，自動恢復(fù)了Master與Slave以及Slaves之間的差異日志，然后從兩個Slave實例中選擇node2充當新的Master，并將另一個Slave實例node2重新指向到新的Master實例node2開始復(fù)制，組成新的MySQL Replication結(jié)構(gòu)。而原來的Master則被排除在新的MySQL Replication結(jié)構(gòu)之外，即使其恢復(fù)正常，也不會被自動加入。 4.手動Master故障切換開啟MHA后，自動啟動監(jiān)控功能，當監(jiān)測到Master故障時，自動實現(xiàn)切換。
另外，在沒有開啟MHA的情況下，我們還可以執(zhí)行交互式的手動切換、非交互式的自動切換，及在線切換Master到不同主機等操作，這些都是通過masterha_master_switch命令工具實現(xiàn)的。
該命令用法如下： [root@mmm appl]# /usr/bin/masterha_master_switch --help
Usage:
# For master failover masterha_master_switch --master_state=dead
--global_conf=/etc/masterha_default.cnf
--conf=/usr/local/masterha/conf/app1.cnf --dead_master_host=host1 # For online master switch masterha_master_switch --master_state=alive
--global_conf=/etc/masterha_default.cnf
--conf=/usr/local/masterha/conf/app1.cnf See online reference
(http://code.google.com/p/mysql-master-ha/wiki/masterha_master_switch)
for details. 從中可以看到，該命令有# For master failover、# For online master switch兩個用法，區(qū)別在于前者需要指定Master的狀態(tài)為dead，后者需要指定Master的狀態(tài)為alive。 下面通過兩個示例來體會一下： 》 For master failover
現(xiàn)在的Master為node2，手動停止mysqld實例
[root@node2 ~]# service mysql stop
Shutting down MySQL... [ OK ]
下面手動執(zhí)行Master故障切換，這個切換過程是交互式的，期間需要輸入指令來確認；另外，由于MHA沒有啟動，也就不會自動監(jiān)控Master實例狀態(tài)，所以需要指定master_state為dead，并且指定dead master的host、ip、port等信息，如下： [root@mmm ~]# /usr/bin/masterha_master_switch --master_state=dead --conf=/etc/appl.cnf --dead_master_host=node2 》 For online master switch
這個功能是指Master實例運行正常，但出于運維工作（比如：更換硬件等），需要將其上的Master切換到另一主機上。
切換過程都一樣，期間也需要交互，只不過指定master_state=alive即可，如下：
# /usr/bin/masterha_master_switch --master_state=alive --conf=/etc/appl.cnf
通過這兩個示例，我們知道，不管是自動Master故障切換，還是手動交互式Master切換，以及在線切換Master到另外主機，其切換過程和步驟都是一樣的。 至此MHA成功搭建完畢，該小節(jié)告一段落，通過前面的學習，我們了解了MHA這一高可用工具的Master故障切換功能及實現(xiàn)原理，但若在實際生產(chǎn)環(huán)境中采用它，還存在許多問題，需要進一步的改進與配置。我們先來探討一下上面這套環(huán)境中存在的問題，及MHA提供的解決辦法。 問題： 前端應(yīng)用連接問題 理論上來說，后端數(shù)據(jù)庫故障切換，對前端應(yīng)用應(yīng)該是透明的；也就是說：當Master從一臺主機切換到另一臺主機上時，前端應(yīng)用不需要做任何額外的操作，主要體現(xiàn)為數(shù)據(jù)庫連接串變化。 對于這個問題，通常有兩種解決方案：一是引入VIP，當數(shù)據(jù)庫切換時，VIP隨之切換；常用的HA軟件中，大多是采用VIP實現(xiàn)的，比如Oracle RAC，SQL Server群集、Heartbeat等。二是采用全局目錄數(shù)據(jù)庫，即將應(yīng)用和數(shù)據(jù)庫之間的連接映射為一個列表，當數(shù)據(jù)庫切換時，更改這個映射列表。MHA并不限制用戶使用那種方式，只是通過master_ip_failover_script配置參數(shù)提供了一個接口。 若采用VIP的方式來實現(xiàn)，可引入第三方軟件，比如Keplived等，也可自行編寫一個VIP切換腳本。
|
