Step By Step 搭建 MySql MHA 叢集

   MHA（Master High Availability）是一款開源的mysql高可用程式，目前在mysql高可用方面是一個相對成熟的解決方案。MHA 搭建的前提是MySQL叢集中已經搭建了MySql Replication環境，有了Master/Slave節點。MHA的主要作用就是監測到Master節點故障時會提升主從複制環境中擁有最新資料的Slave節點成為新的master節點。同時，在切換master期間，MHA會通過從其他的Slave節點來擷取額外的資訊來避免一緻性的問題，整個的切換過程對于應用程式而言是完全透明的。MHA還提供了master節點線上切換功能，即按需切換master/slave節點。

MHA 服務有兩個角色，MHA Manager 和 MHA Node 

 MHA Manager: 通常單獨部署在一台獨立機器上管理 master/slave 叢集，每個master/slave 叢集可以了解為一個application。

   MHA Node: 運作在每台mysql 伺服器(master/slave)上。它通過監控具備解析和清理logs功能來加快故障轉移。

整體上的架構如下圖所示。

   MHA 在自動切換的過程中會從宕掉的MySql master節點中儲存二進制日志，以保證資料的完整性。但是如果master節點直接當機了呢，或者網絡直接不能聯通了呢？MHA就沒有辦法擷取master的二進制日志，也就沒有辦法保證資料的完整性了。這也就是為什麼MHA應該與MySql主從複制結合起來。這樣的話，隻要有一個slave節點從master節點複制到了最新的日志，MHA就可以将最近的二進制日志應用到其他的slave節點上，這樣就可以最大限度上保證資料的完整性。

MHA 自動切換的原理可以總結為下面幾點.

從當機崩潰的master儲存二進制日志事件（binlog events）;

識别含有最新更新的slave;

應用差異的中繼日志（relay log）到其他的slave;

應用從master儲存的二進制日志事件（binlog events);

提升一個slave為新的master;

使其他的slave連接配接新的master進行複制;

MHA 提供了很多的程式元件，通過這些元件，我們 可以很友善的管理MHA叢集。

Manager節點：

masterha_check_ssh：MHA依賴的環境監測工具;

masterha_check_ssh: MySql複制環境檢測工具;

masterha_manager: MHA 服務主程式;

masterha_check_status: MHA運作狀态探測工具;

masterha_master_monitor: MySql master節點可用性檢測工具;

masterha_switch: master 節點切換工具;

masterha_conf_host: 添加或删除配置的節點;

masterha_stop: 關閉MHA服務的工具;

Node節點:

save_binary_logs:儲存和複制master節點的二進制日志;

apply_diff_relay_logs: 識别差異的中繼日志事件并應用于其他的slave;

purge_relay_logs:清除中集日志(不會阻塞SQL線程);

   在實際的生産環境中有很多的因素需要考慮，例如MHA Manager的單點問題。但是我們由于環境有限，是以就暫時不考慮這些。此次實驗中實驗環境如下。

擔任角色

主機名

位址

功能描述

對應軟體版本

MHA Manager

manager

192.168.0.20

MHA Manager,控制Master節點故障轉移

mha4mysql-manager-0.56-0.el6.noarch

MySql Master

master

192.168.0.21

MySql Master 節點

Mariadb-server-5.5.56-2.el7

MySql Slave

Slave1

192.168.0.22

Mysql Repliaction叢集中的Slave1 節點

Slave2

192.168.0.26

MySql Repliaction 叢集中的Slave2節點

   某種意義上說，Master節點不會一直充當master節點。Master節點從故障狀态中恢複之後，很有可能充當的是slave節點，是以我們在安裝插件的時候，不做差別對待。 

mysql 支援多種插件/var/lib/mysql/plugin 目錄下，需要安裝方可使用。在Master(192.168.0.21)，和Slave(192.168.0.22,192.168.0.26)節點上安裝<code>semisync_master.so</code> <code>semisync_slave.so</code> 兩個插件。

然後在三台主機上開啟下面兩個參數

到目前而言，三台主機之間沒有差别，也沒有角色上的區分。接下來我們開始設定master與slave來實作主從複制。

編輯 /etc/my.cnf.d/server.cnf 檔案，加入下面這樣一段配置

修改完配置檔案之後，重新開機Mariadb. <code>systemctl restart mariadb</code>

在master節點上進行操作

在slave節點上進行操作

上面的操作完成後，在master主機上檢視master的狀态。

在slave主機上可以檢視slave主機的狀态。

在Master節點上建立MHA監控所需要的使用者，該使用者會同步到slave端。

至此，MySql 主從複制環境就搭建好了。下面就可以開始來安裝MHA了。

注：在檢視slave節點狀态時，如果出現問題，可以檢查一下SELinux，iptables，以及其他權限問題，在實驗開始之前，最好先将這些環境設定好，避免出現問題。

   MHA 叢集中的各節點之間需要基于SSH互相通信，以實作遠端控制以及資料管理功能。簡單起見，我們以Manager節點為例，然後将生成的檔案發送到需要管理的主機上。四個節點都需要進行這個操作。

   這樣MHA Manager就實作了通過SSH免密管理其他的mysql節點

在所有節點上安裝node安裝包

在Manager節點上安裝manager安裝包

  還可以在上述網站上下載下傳源碼包，裡面有很多的例子和腳本可以直接拿來使用。 将下載下傳的源碼包解壓之後在samples/scripts下的所有腳本複制到/usr/bin目錄(因為安裝的mha manager的相關指令就在/usr/bin/目錄下，可以使用rpm -ql mha4mysql-manager-0.56-0.el6 來檢視)下。 

腳本如下：

   這裡有一點需要注意，拷貝到/usr/bin 目錄下的檔案如果沒有執行權限，要加上執行權限。

   Manager節點需要為每個監控的master/slave 叢集提供專用的配置檔案，而所有的master/slave叢集也可以共享全局配置。全局配置檔案預設在/etc/masterha_default.cnf，其為可選配置。如果僅監控一組master/slave叢集，也可以直接通過application 的配置來提供給個伺服器的預設配置資訊。而滅個application的配置檔案路徑為自定義，我們的執行個體中，隻有一個master/slave叢集，是以我們就定義一個配置檔案好了。

   編輯一下 /etc/masterha_default.cnf 檔案，添加一些全局的配置。配置檔案的内容如下。

   在master，slave1 和slave2 節點上執行下面的指令檢查一下mysqlbinlog和mysql 指令的位置。

   一定要確定 mysqlbinlog 和mysql 兩個指令在 /usr/bin 目錄下。由于我安裝的是mariadb ，是以這兩個檔案預設就在這兩個目錄，如果是其他版本的mysql，不在這兩個目錄下的話可以使用軟連接配接的方式，在這個目錄下添加兩個軟連接配接。

否則，在進行檢查的時候，會出現如下的類似錯誤。

mysqlbinlog

mysql

   在master 節點上進行操作，給ens33網卡添加一個VIP，這樣使用者通路的時候，就會可以通過VIP進行通路，并不需要關心MySQL叢集中的具體細節。同時如果master當機之後，VIP會自動進行轉移，并不會影響到使用者的通路，後端VIP漂移的過程對使用者來說完全透明。

   在MHA manager上進行操作，修改/usr/bin/master_ip_failover腳本如下，主要是VIP的修改。

   經過上述的一系列的的配置和操作，我們就順利的配置好了MySql replication 環境和MHA 環境，接下來開始驗證一下。 

在MHA manager 上進行一下下面的操作。

   在manager 節點上進行操作。

   如果想要停止MHA 可以執行如下的指令

   在manager節點檢視 manager.log 的日志，可以看到下面的切換過程

注意，故障轉移完成之後，manager會自動停止，此時使用masterha_check_status指令檢測将會是下面這種結果.

   在新的master主機slave1上進行檢視,master_id 已經進行了切換，并且少了一台slave 主機。

   在slave2主機上檢視slave 的目前狀态 。

   可以看到最新的master的IP 已經變成了之前slave1 主機的IP位址，這說明master 切換成功。

   在新的master 主機上檢視ip位址的變化,如果VIP 漂移成功說明，之前的配置沒有問題。

   在舊的master主機上檢視VIP是否已經被移除。

   如果上面兩項的檢測都沒有問題，說明在實際的使用過程中VIP 就不會産生位址沖突了。 而且位址切換過程對使用者來說，基本上沒有任何感覺，這樣就保證了mysql服務的高可用了。

   生産中mysql服務停掉可以立即監監控到，而且這基本上屬于以及故障需要立即進行排除。 

重新恢複宕掉的mysql服務比較好的思路是，将其基于最新的master節點的資料備份進行資料恢複，然後重新啟動服務，将其設定為slave節點，并加入到新的master叢集，之後重新開機MHA監控。 

備份還原過程，此處不再贅述。将啟動後的節點重新加入到新的master叢集中。過程與之前介紹的類似。

   在新的master節點上檢視最新的slave主機狀态。

   可以看到slave 主機的server_id 已經變化了。

   在manager上修改/etc/masterha/app1.cnf中secondary_check_script中的master IP值，将新的master ip修改上

   修改/etc/masterha_default.cnf 中secondary_check_script 中的IP位址

   在Manager 上啟動MHA 然後檢查MHA的狀态

   啟動MHA ，檢查MHA的狀态

至此，MySql MHA 的配置與測試基本就完成了。在實際生産中，至少也應該對MySQL主從複制進行一下驗證，并且對MySQL 故障進行了解，以便在實際生産中能夠有效的排除故障。

     本文轉自Eumenides_s 51CTO部落格，原文連結：

http://blog.51cto.com/xiaoshuaigege/2060768

，如需轉載請自行聯系原作者