MHA初探

一、基本描述
   MHA（mysql-master-ha）,MHA的一個主要的目標就是實現主從的自動快速切換（10-30s），並且切換過程
不會導致資料不一致問題，同時部署MHA不會導致新增加機器，不需要改變原來的部署結構，不會有效能損失
並且易於安裝.
   它同時提供了線上切換功能（計劃內): 從舊master節點安全的切換到新的master節點，只需要很短的時間
（0.5-2s），並且這個過程中只是阻塞寫，不會影響讀操作
 具體功能點：
 1、自動主庫監控和failover
    MHA具有監控複製環境的中master狀態的功能，可以發現master是否不可用，並且完成自動故障切換。在多個
 slave情況下，MHA會自動的找到跟最接近主庫（the latest）的slave的不同的relay log事件，然後把這些events
應用到其他的slave上，最終所有的slave達到資料一致。 正常情況MHA在數秒內能夠完成failover（9-12s確認master
不可用，7-10s（可選擇）關閉原master所在機器來防止腦裂, 幾秒鐘來應用不同的relay log，總時間需要10-30s）
另外，可以通過配置檔案指定一個候選master。因為MHA會完成slave之間的一致，所以你可以提升任何一個slave
為新的master，並且不會導致不一致問題
 2、互動式master failover
   可以用MHA只做failover，而不監控master。 MHA提供交換式的master failover
 3、非互動式master failover
   非互動的master failover在你已經有監控mysql master軟體的情況還是有用的，
   比如你可以用（Pacemaker）來監控 master狀態和vip接管， 然後使用MHA做failover和slave提升
 4、online switchover
   資料庫升級，伺服器硬體升級等場景

有點總結：
 1、master failover和 slave promotion操作會非常迅速。
   9-12s發現故障，可選擇的7-10s的主機power off，數秒的應用差異relay log。從新選舉新的master
   後，MHA並行恢復剩餘的slave，不管你有1臺或者10臺，對恢復時間幾乎沒影響，都能很快完成
 2、master crash掉不會導致資料不一致
   MHA處理slave間差異的中繼日誌，達到最終一致，結合半同步複製，幾乎
  可以認為資料不會丟失
 3、無需修改當前的mysql配置（MHA支援mysql5.0+）
    MHA的啟停、升級降級、安裝解除安裝都不需要停資料庫，只是replace就ok了
 4、不需要增加大量伺服器
    MHA由MHA Manager和MHA Node組成，MHA Node在mysql伺服器上部署執行，
    不需要額外的服務；MHA Manager正常情況執行在專用伺服器上，但是一個
    MHA Manager 可以監控大量（100+）的master。 並且MHA Manager 也可以
    執行在slave 上，這樣根本不需要增加額外的機器
 5、無效能損失
    MHA可以在常規的非同步複製或半同步複製下工作，它預設3s會向master傳送
    ping包，沒有複雜查詢。幾乎對效能無影響
 6、支援任何儲存引擎

二、原理分析和架構

原理分析：
圖片1

slave的中繼日誌裡，master的二進位制日誌的位置被標記“end_log_pos”,通過對比
slave之間的end_log_pos值來確定哪些中繼日誌沒有被全員應用。MHA內部通過這個
原理來修復slaves之間的一致性，在這個基本原理上，MHA做了一些優化和發展， 比如
快速生成差異中繼日誌，使用 row格式的恢復方式等。

架構
圖片2

MHA結構包括兩個部分：
1、MHA Manager：監控master，控制master failover，擴充套件的script等
2、MHA Node：解析二進位制日誌和中繼日誌，確認差異中繼日誌，應用差異中繼日誌等

當MHA Manager執行failover，MHA manger 通過ssh連線MHA Node，呼叫需要的MHA Node
命令做操作

擴充套件定製
MHA有很多的擴充套件點：比如使用MHA更新master的IP（更新全域性目錄庫資訊，更新vip等）
如何處理IP有使用者自己決定，MHA沒有明確強制使用什麼方式：

目前提供的擴充套件script介面:
secondary_check_script: For checking master availability from multiple network routes
master_ip_failover_script: For updating master's ip address used from applications
shutdown_script: For forcing shutdown the master
report_script: For sending reports
init_conf_load_script: For loading initial configuration parameters
master_ip_online_change_script: For updating master ip address. This is not used for master failover, but used for online master switch

三、支援的複製架構：

【1】管理節點的部署：

 1、專用管理節點伺服器，管理多組伺服器:MHA Manager只消耗很少的CPU和記憶體，可以單個MHA
    Manager管理上百組伺服器
 2、部署到一個slave節點上,節省伺服器

【2】複製環境情況：

場景一：一主多從
      M(RW)                            M(RW), promoted from S1
         |                                             |
  +------+------+        --(master crash)--&gt     +-----+-----+
 S1(R) S2(R)   S3(R)                           S2(R)        S3(R)
最常見的架構，MHA能夠很好在這個場景下工作

場景二： 一主多從（一個slave在遠端資料中心）
        M(RW)                                M(RW), promoted from S1
         |                                                 |
  +------+---------+         --(master crash)--&gt     +-----+------+
 S1(R) S2(R)     Sr(R,no_master=1)                   S2(R)         Sr(R,no_master=1)
很多情況下，需要一個遠端備份的slave，但是並不想切換的時候被切成主庫， MHA支援
這樣的場景在配置檔案設定no_master=1這個slave就永遠不會成為master。

場景三：一主多從（一個候選master）
      M(RW)-----S0(R,candidate_master=1)   M(RW), promoted from S0
       |                                          |
  +----+----+          --(master crash)--&gt   +----+----+
 S1(R)     S2(R)                             S1(R)      S2(R)

MHA支援candidate_master=1引數來指定候選master

場景四：多主多從
      M(RW)        |                                          |
  +----+----+          --(master crash)--&gt   +----+----+
 S(R)     S2(R)                             S1(R)      S2(R)

MHA支援多主（一個讀寫，一個只讀）配置，當master不可用，切換到另一個主庫上

場景五： 三層複製
        M(RW)                                   M(RW), promoted from S1
         |                                                 |
  +------+---------+         --(master crash)--&gt     +-----+------+
 S1(R) S2(R)     Sr(R)                              S2(R)       Sr(R)
                   |                                              |
                   +                                              +
                  Sr2                                            Sr2

該場景下當Sr2的上層是Sr，MHA不能恢復Sr2。Sr正常情況下，MHA能夠處理此
場景跟之前的類似

場景六： 三層複製，多主
   M1(host1,RW)         |                                |
  +-----+--------+                       +
 S1(host3,R)    S2(host4,R)             S3(host5,R)
 
=> After failover
 
          M2(host2,RW)
                 |
  +--------------+--------------------------+
 S1(host3,R)    S2(host4,R)             S3(host5,R)

MHA支援該場景，host5是有一個三層的slave，MHA不會管理host5，但是當host1不可用的時候，
切換到host2上，host5還是可以正常複製。

[server default]
multi_tier_slave=1

[server1]
hostname=host1
candidate_master=1

[server2]
hostname=host2
candidate_master=1

[server3]
hostname=host3

[server4]
hostname=host4

[server5]
hostname=host5

【3】 master IP的管理:
 方法一：使用vip管理軟體，當資料庫掛掉，vip自動切換到從庫
 方法二：使用一個全域性目錄資料庫，當主庫切換的時候，對儲存的
         資訊做更新

【4】結合半同步複製:
    雖然MHA可以從掛掉的master節點獲取二進位制日誌，但是當master節點
無法連通的時候，MHA無法獲取這些可能只存在於master上events，這時候
的failover就會造成資料丟失
    半同步複製可以大大降低這種風險，半同步複製能夠確保至少有一個
slave獲得到了最新的二進位制日誌，這樣MHA即使無法登陸master節點也能
獲得到幾乎所有的events日誌，保證資料的不會丟失
 

四、安裝配置(host1(M), host2(S), host3(S), host4(管理節點))：
1、搭建複製環境，MHA不處理這些，需要自己搭建
2、建立節點互信，SSH免輸入密碼
3、MHA Node節點安裝：
yum install perl-DBD-MySQL

# rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
或者：
$ tar -zxf mha4mysql-node-X.Y.tar.gz
$ perl Makefile.PL
$ make
$ make install

MHA Node需要安裝在所有的mysql伺服器上（master，slaves），並且在管理
節點伺服器上也要安裝，MHA Manager 模組內部呼叫會用到 MHA Node模組
安裝完成後/usr/bin會生成三個命令：
 save_binary_logs: Saving and copying dead master's binary logs
 apply_diff_relay_logs: Identifying differential relay log events and applying all necessary log events
 purge_relay_logs: Purging relay log files

4、MHA Manager節點安裝:

yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y
如果沒有安裝的話：
rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm

rpm -ivh mha4mysql-manager-X.Y-0.noarch.rpm
or
$ tar -zxf mha4mysql-manager-X.Y.tar.gz
$ perl Makefile.PL
$ make
$ sudo make install

安裝完成後/usr/bin下生成9個命令：
masterha_check_repl
masterha_check_ssh
masterha_check_status
masterha_conf_host
masterha_manager
masterha_master_monitor
masterha_master_switch
masterha_secondary_check
masterha_stop

5、配置檔案：
manager_host$ cat /etc/app1.cnf
 
[server default]
# mysql user and password
user=root
password=mysqlpass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
 
[server1]
hostname=host1
[server2]
hostname=host2
[server3]
hostname=host3
驗證SSH聯通性：
 masterha_check_ssh --conf=/etc/app1.cnf
輸出下面資訊說明SSH配置沒有問題
Sat May 14 14:42:22 2011 - [info] All SSH connection tests passed successfully.
驗證複製環境：
manager_host$ masterha_check_repl --conf=/etc/app1.cnf
  ...
  MySQL Replication Health is OK.

5、啟動Manager：
manager_host$ nohup masterha_manager --conf=/etc/app1.cnf   --ignore_fail_on_start  --ignore_last_failover >> /var/log/manager.log 2>&1 &
 

五、擴充套件
文件只是簡單的概述了MHA的原理和優勢，以及應用場景，詳細參考：
https://code.google.com/p/mysql-master-ha/

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/20625855/viewspace-1649629/，如需轉載，請註明出處，否則將追究法律責任。