萬盛學電腦網

浏覽器 windows 10 wps office 殺毒軟件 數據庫 excel教程 文件管理 word教程 網頁制作 裝機必備軟件 linux教程

萬盛學電腦網 >> 數據庫 >> mysql教程 >> MHA輕松實現MySQL高可用配置詳解

MHA輕松實現MySQL高可用配置詳解

MHA是一位日本MySQL大牛用Perl寫的一套MySQL故障切換方案，來保證數據庫系統的高可用.在宕機的時間內（通常10—30秒內），完成故障切換，部署MHA，可避免主從一致性問題，節約購買新服務器的費用，不影響服務器性能，易安裝，不改變現有部署。

還支持在線切換，從當前運行master切換到一個新的master上面，只需要很短的時間（0.5-2秒內），此時僅僅阻塞寫操作，並不影響讀操作，便於主機硬件維護。

2MHA架構

MHA由MHA Manager和MHA Node組成。

1.png

3MHA Manager

運行一些工具，比如masterha_manager工具實現自動監控MySQL Master和實現master故障切換，其它工具實現手動實現master故障切換、在線mater轉移、連接檢查等等。一個Manager可以管理多個master-slave集群。

4MHA Node

部署在所有運行MySQL的服務器上，無論是master還是slave。主要作用有三個。

Ⅰ、保存二進制日志
如果能夠訪問故障master，會拷貝master的二進制日志

II、應用差異中繼日志
從擁有最新數據的slave上生成差異中繼日志，然後應用差異日志。

III、清除中繼日志
在不停止SQL線程的情況下刪除中繼日志

5MHA工作原理

2.png

當master出現故障時，通過對比slave之間I/O線程讀取masterbinlog的位置，選取最接近的slave做為latestslave。其它slave通過與latest slave對比生成差異中繼日志。在latest slave上應用從master保存的binlog，同時將latest slave提升為master。最後在其它slave上應用相應的差異中繼日志並開始從新的master開始復制。

在MHA實現Master故障切換過程中，MHA Node會試圖訪問故障的master（通過SSH），如果可以訪問（不是硬件故障，比如InnoDB數據文件損壞等），會保存二進制文件，以最大程度保證數據不丟失。MHA和半同步復制一起使用會大大降低數據丟失的危險。

6當前高可用方案

Heartbeat+DRBD
開銷：需要額外添加處於被動狀態的master server（並不處理應用流量）
性能：為了實現DRBD復制環境的高可用，innodb-flush-log-at-trx-commit和sync-binlog必須設置為1，這樣會導致寫性能下降。

一致性：在master上必要的binlog時間可能會丟失，這樣slave就無法進行復制，導致產生數據一致性問題。

MySQL Cluster
MySQL Cluster真正實現了高可用，但是使用的是NDB存儲引擎，並且SQL節點有單點故障問題。

半同步復制(5.5+)
半同步復制大大減少了“binlog events只存在故障master上”的問題。

在提交時，保證至少一個slave（並不是所有的）接收到binlog，因此一些slave可能沒有接收到binlog。

全局事務ID
在二進制文件中添加全局事務ID（global transaction id）需要更改binlog格式，在5.1/5.5版本中不支持。

在應用方面有很多方法可以直線全局事務ID，但是仍避免不了復雜度、性能、數據丟失或者一致性的問題。

PXC
PXC實現了服務高可用，數據同步時是並發復制。但是僅支持InnoDB引擎，所有的表都要有主鍵。鎖沖突、死鎖問題相對較多等等問題。

7MHA的優勢

1、故障切換快

在主從復制集群中，只要從庫在復制上沒有延遲，MHA通常可以在數秒內實現故障切換。9-10秒內檢查到master故障，可以選擇在7-10秒關閉master以避免出現裂腦，幾秒鐘內，將差異中繼日志（relay log）應用到新的master上，因此總的宕機時間通常為10-30秒。恢復新的master後，MHA並行的恢復其余的slave。即使在有數萬台slave，也不會影響master的恢復時間。

DeNA在超過150個MySQL（主要5.0/5.1版本）主從環境下使用了MHA。當mater故障後，MHA在4秒內就完成了故障切換。在傳統的主動/被動集群解決方案中，4秒內完成故障切換是不可能的。

2、master故障不會導致數據不一致

當目前的master出現故障是，MHA自動識別slave之間中繼日志（relay log）的不同，並應用到所有的slave中。這樣所有的salve能夠保持同步，只要所有的slave處於存活狀態。和Semi-Synchronous Replication一起使用，（幾乎）可以保證沒有數據丟失。

3、無需修改當前的MySQL設置

MHA的設計的重要原則之一就是盡可能地簡單易用。MHA工作在傳統的MySQL版本5.0和之後版本的主從復制環境中。和其它高可用解決方法比，MHA並不需要改變MySQL的部署環境。MHA適用於異步和半同步的主從復制。

啟動/停止/升級/降級/安裝/卸載MHA不需要改變（包擴啟動/停止）MySQL復制。當需要升級MHA到新的版本，不需要停止MySQL，僅僅替換到新版本的MHA，然後重啟MHA　Manager就好了。

MHA運行在MySQL 5.0開始的原生版本上。一些其它的MySQL高可用解決方案需要特定的版本（比如MySQL集群、帶全局事務ID的MySQL等等），但並不僅僅為了master的高可用才遷移應用的。在大多數情況下，已經部署了比較舊MySQL應用，並且不想僅僅為了實現Master的高可用，花太多的時間遷移到不同的存儲引擎或更新的前沿發行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上，所以並不需要遷移。

4、無需增加大量的服務器

MHA由MHA Manager和MHA Node組成。MHA Node運行在需要故障切換/恢復的MySQL服務器上，因此並不需要額外增加服務器。MHA Manager運行在特定的服務器上，因此需要增加一台（實現高可用需要2台），但是MHA Manager可以監控大量（甚至上百台）單獨的master，因此，並不需要增加大量的服務器。即使在一台slave上運行MHA Manager也是可以的。綜上，實現MHA並沒用額外增加大量的服務。

5、無性能下降

MHA適用與異步或半同步的MySQL復制。監控master時，MHA僅僅是每隔幾秒（默認是3秒）發送一個ping包，並不發送重查詢。可以得到像原生MySQL復制一樣快的性能。

6、適用於任何存儲引擎

MHA可以運行在只要MySQL復制運行的存儲引擎上，並不僅限制於InnoDB，即使在不易遷移的傳統的MyISAM引擎環境，一樣可以使用MHA。

#cat /etc/redhat-release

CentOSrelease 6.6 (Final)

#uname -rm

2.6.32-504.el6.x86_64x86_64

創建MHA用戶

在主從環境的主上執行

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

創建軟連接

如果MySQL服務不是yum安裝，要在所有MySQLServer上，無論主從都要執行如下兩個命令。

# ln-s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog

# ln-s /application/mysql/bin/mysql /usr/bin/mysql

配置SSH公鑰認證

幾台服務器進行相同操作，僅分發到的服務不同而已，這裡僅列出一台。

###

添加統一用戶

在生產環境下使用root用戶不安全，也不規范。並且環境統一也比較方便管理，因此可以創建統一的普通用戶來進行。

#####

創建密鑰對

[root@mha-manager ~]#ssh-keygen -t dsa

將公鑰分發到各個主機上

驗證

配置hosts

部署MHANode

在所有運行MySQL服務的服務器上運行MHA Node，無論是master還是slave。由於MHA　Manager需要MHA　Node，因此在運行MHA　Manager的服務器上也需要安裝MHA　Node。當然也可以在任意一個slave上運行MHA　Manager。因為部署步驟相同，所以就列出一個安裝步驟（在mha-manager服務器上）

創建目錄

[root@mha-manager ~]# mkdir /softs

安裝MHA Node