MySQL 高可用之MHA（一）

前言

在 MySQL 的高可用方案中，MHA（Master High Availability）可謂是最爲成熟、使用最爲普遍的方案之一了。其做者 Yoshinori Matsunobu 現就任於 Facebook，該架構採用 perl 語言編寫，可完成秒級別的主庫故障切換，接下來詳細介紹 MHA 在銅板街的上線之路。

架構選型

在開始計劃實施 MySQL 數據庫高可用時，咱們選擇了比較流行的幾大方案，分別進行了調研。

MHA：適用於一主多從的架構體系，在故障切換過程當中，可從宕機的主庫上保存二進制日誌，最大程度的保證數據不丟失。可是須要 MHA 架構內全部的節點都必須能夠 ssh互通。

MMM：（Master-Master replication manager for MySQL） 適用於雙主架構，是一套支持雙主故障切換和平常管理的腳本程序，雖無需架構內 ssh 互通，可是沒法保存主庫的二進制日誌，因此數據一致性不如 MHA 高。

PXC：（Percona XtraDB Cluster）是 percona 公司提供的一套高可用方案，須要三個或以上 percona 版本的 DB 節點，該架構保證了數據強一致，可是同等硬件配置下，性能不如 MHA 和 MMM，尤爲木桶效應明顯，該方案還需依賴外部組件。

MGR：（MySQL Group Replication）是 MySQL 官方發佈的高可用架構，該方案依賴於 MySQL5.7 版本，適用於主從架構，可是須要相似主庫全表包含主鍵等相關依賴，成熟度不如以上方案，該方案一樣須要依賴外部組件。

綜上，在結合自身的業務場景，最終選擇 MHA 做爲 MySQL 集羣的高可用方案。如下詳細介紹 MHA 的體系結構及部署和測試的各項細節。

架構簡介

MHA 由兩個部分組成，以下圖1：管理節點（如下稱爲 manager ）和數據節點（如下稱爲 node ）組成，其中 manager 能夠單獨部署也能夠部署在 DB 節點上，爲規範，咱們將 manager 單獨部署在一臺機器上（爲節省資源，能夠部署在虛擬機上，並作好備份），node 部署在每一個 DB 上和 manager 上。

MHA 架構中，manager 會定時探測集羣中的主庫節點，通常爲每秒鐘探測一次，當主庫出現故障後，拉取主庫和最新從庫的差別日誌並應用到該從庫上，將該從庫提高爲新的主庫，而後把其餘全部的從庫從新指向新的主庫，因爲主庫採起 VIP 方式對外提供服務，整個故障轉移的過程對應用程序是徹底透明的。

爲最大程度的保證數據一致性，對於核心業務的數據庫參數 sync_binlog、

innodb_flush_log_at_trx_commit 均設置爲1，每次主庫事物提交後，都當即寫入 binlog 而且當即將緩存中的 redo 日誌寫到日誌文件，並調用操做系統 fsync 刷新 IO 緩存。主從同步上採用半同步複製，主庫的每一個事物須要等待從庫返回響應後再對外宣佈成功，最大程度的保證數據的一致性（ MySQL的半同步複製即便在 5.7 版本中也沒有作到數據的強一致）。

原理說明

因爲篇幅有限，本章將着重介紹 MHA 的工做原理，以及相關實現的細節，具體的搭建步驟，將在下一章節重點介。

如下圖 圖2爲例，總結一下 MHA 的工做原理（如下序列號和圖2序列號一一對應）。

1. manager 確認主庫宕機後，觸發 master_ip_failover 腳本，摘除 VIP。

2. manager 識別最新的從庫（同步主庫數據最多的 slave1） binlog 的位置。

3. manager 把主庫和最新從庫的差別 binlog 保存到 manager 本地。

4. manager 將本地保存的差別 binlog 複製到最新從庫上，並進行應用，應用完成後，將原主庫的 VIP 設置到該從庫上，提高該從庫爲新的主庫。

5. 將其餘全部從庫指向新的主庫。

那麼 MHA 具體是經過什麼操做的呢，其實就是一些 perl 腳本，包括 manager 和 node 工具包，具體說明以下：

MHA manager 端經常使用工具：

masterha_master_switch：控制故障轉移（經常使用，通常手動在線切換主庫使用）

masterha_check_ssh：檢查 MHA 的 SSH 配置情況 （經常使用，每次配置完 ssh 互通需測試一下）

masterha_check_repl：檢查 MySQL 複製情況 （經常使用，每次部署完 MHA 後，都須要進行檢測）

masterha_manager：啓動 MHA 使用（經常使用，主庫自動故障切換時開啓 MHA 所需命令）

masterha_secondary_check：對主庫監聽進行二次校驗

masterha_check_status：檢查當前 MHA 運行狀態

masterha_master_monitor：監測 master 是否宕機

masterha_stop：中止 MHA

manager 使用到的腳本：

master_ip_failover_script=/usr/local/bin/master_ip_failover設置自動 failover 時候使用到的切換腳本

master_ip_online_change_script=/usr/local/bin/master_ip_online_change設置手動在線切換時所使用的切換腳本

report_script=/usr/local/bin/send_report 設置切換完發送通知使用的的腳本，僅自動故障切換場景時觸發，手動在線切換時不觸發該腳本

1 secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.1.221 --user=root --master_ip=192.168.1.220複製代碼

當MHA到主庫 192.168.1.220 之間的網絡出現問題時，再經過從庫 192.168.1.221（該從庫儘可能不要選擇備主）進行登陸驗證，兩次驗證都出現問題時，MHA 認爲主庫宕機。

MHA node 端經常使用工具（這些工具由 manager 觸發，不需人工操做）：

save_binary_logs：保存和複製 master 的二進制日誌

apply_diff_relay_logs：識別差別的中繼日誌事件，並將其差別的事件應用到其餘從庫

purge_relay_logs：MHA 在切換過程當中，可能依賴從庫的 relay log，利用該腳本採用按期清除 relay log 的方式，防止其自動清除（該腳本須要手工在從庫上進行部署，具體部署方法後面文章詳細說明），該腳本在從庫上須要有數據庫的 SELECT, RELOAD, SUPER 權限才能夠執行。

部分細節說明

1. 軟件下載地址：

   強烈建議使用MHA做者的git地址下載0.56版本的tarball，其git地址：

   https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads，

   其餘地址如 Google code中的軟件包，筆者通過測試，都會有bug，Google code地址：

   https://code.google.com/p/mysql-master-ha/downloads/list，可自行測試。

2. VIP是經過腳本方式實現，分別配置在 master_ip_failover 和 master_ip_online_change中，核心代碼爲：

1 1ip addr add 192.168.1.220/32 dev eth0;arping -q -c 2 -U -I eth0 192.168.1.220
2 1ip addr del 192.168.1.220/32 dev eth0
複製代碼

以此方式下掉原故障主庫VIP，在新的主庫上添加VIP。

3. 本次 MHA 架構使用 VIP，多數公司使用域名方式鏈接 DB，可經過修改域名解析到VIP，重啓應用，便可快速完成 MHA 架構的上線。

4. 受權相關說明。因爲從庫在本地應用差別的 relay log 時，須要對全部 DB 有 all 權限，因此 MHA 的受權時，防止權限外泄，要指定全部節點（manager 和 node）的具體 IP 地址。

本章只介紹了 MHA 理論相關的方面，若有不當之處還望留言多多指教。下一次會將所有代碼貼出來，能夠直接使用進行搭建 MHA 。

參照：

1.《深刻淺出MySQL 數據庫開發、優化與管理維護（第二版）》

做者簡介

天元，銅板街DBA，2017 年 7 月加入團隊，目前主要負責公司全部業務的數據庫相關運維。

                            

                    更多精彩內容，請掃碼關注 「銅板街科技」 微信公衆號。