******** 摘要********

MySQL是目前主流的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，目前在全球被廣泛地應用。由于其開源、體積小、速度快、成本低、安全性高，因此許多網(wǎng)站選擇MySQL作為數(shù)據(jù)庫進行存儲數(shù)據(jù)。

****以前在運維數(shù)據(jù)庫過程中經(jīng)常會遇到這樣的困擾：沒有工具快速切換集群主庫，如果切換主庫，需要DBA手動修改從庫指向，修改元信息等。所以今天給大家介紹一款工具MHA，可以實現(xiàn)需求快速上線，不影響當前架構(gòu)，整個切換全部自動化處理，方便DBA使用，例如檢查，操作，展示等。

在 MySQL（5.5 及以下）傳統(tǒng)復制的時代，MHA（Master High Availability）在 MySQL 高可用應用中非常成熟。在 MySQL（5.6）及 GTID 時代開啟以后，MHA 沒有隨之進行進一步的更新，但是很多互聯(lián)網(wǎng)公司依然在沿用這個技術(shù)。因此本文給出了MHA的簡單介紹。

2

MHA簡介

【 什么是MHA 】

****MHA目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton開發(fā)，是一套優(yōu)秀的作為MySQL高可用性環(huán)境下故障切換和主從提升的高可用軟件。在MySQL故障切換過程中，MHA能做到在0~30秒之內(nèi)自動完成數(shù)據(jù)庫的故障切換操作，并且在進行故障切換的過程中，MHA能在最大程度上保證數(shù)據(jù)的一致性，以達到真正意義上的高可用。

目前MHA主要支持一主多從的架構(gòu)，在搭建MHA時至少要有一個Master主庫和兩個Slave從庫，MHA架構(gòu)支持任何存儲引擎。

****該軟件由兩部分組成：MHA Manager（管理節(jié)點）和MHA Node（數(shù)據(jù)節(jié)點）。MHA Manager可以單獨部署在一臺獨立的機器上管理多個master-slave集群，也可以部署在一臺slave節(jié)點上。MHA Node運行在每臺MySQL服務器上，MHA Manager會定時探測集群中的master節(jié)點，當master出現(xiàn)故障時，它可以自動將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master。整個故障轉(zhuǎn)移過程對應用程序完全透明。

【 MHA優(yōu)勢 】

• 不影響服務器性能，易安裝，不改變現(xiàn)有部署
• 故障切換（實現(xiàn)自動故障檢測和故障轉(zhuǎn)移，通常在30秒以內(nèi)）
• 數(shù)據(jù)一致性保證
• 不需要對當前mysql環(huán)境做重大修改
• 不需要添加額外的服務器(僅一臺manager就可管理上百個replication)
• ****性能優(yōu)秀，可工作在半同步復制和異步復制，當監(jiān)控mysql狀態(tài)時，僅需要每隔N秒向master發(fā)送ping包(默認3秒)，所以對性能無影響。你可以理解為MHA的性能和簡單的主從復制框架性能一樣
• ****只要replication支持的存儲引擎mha都支持

【 MHA組成 】

MHA軟件由兩部分組成，Manager工具包和Node工具包，具體的說明如下。

Manager工具包主要包括以下幾個工具：

• masterha_check_ssh 檢查MHA的SSH配置狀況
• masterha_check_repl 檢查MySQL復制狀況
• masterha_manger 啟動MHA
• masterha_check_status 檢測當前MHA運行狀態(tài)
• masterha_master_monitor 檢測master是否宕機
• masterha_master_switch 控制故障轉(zhuǎn)移（自動或者手動）
• masterha_conf_host 添加或刪除配置的server信息

Node工具包（這些工具通常由MHA Manager的腳本觸發(fā)，無需人為操作）主要包括以下幾個工具：

• save_binary_logs 保存和復制master的二進制日志
• apply_diff_relay_logs 識別差異的中繼日志事件并將其差異的事件應用于其他的slave
• filter_mysqlbinlog 去除不必要的ROLLBACK事件
• purge_relay_logs 清除中繼日志（不會阻塞SQL線程）

【 MHA版本選擇 】

從MHA的0.56版本開始，也支持基于GTID的故障切換。MHA會自動檢測mysqld是否在GTID運行，如果GTID開啟，MHA就實現(xiàn)帶GTID的故障切換，如果沒有啟用，MHA就使用基于relay log的故障切換。

3MHA實現(xiàn)

【 工作流程 】

1. 從宕機崩潰的master保存二進制日志事件（binlog events）;
2. 識別含有最新更新的slave；
3. 應用差異的中繼日志（relay log）到其他的slave；
4. 應用從master保存的二進制日志事件（binlog events）；
5. 提升一個slave為新的master；
6. 使其他的slave連接新的master進行復制。

【 MHA架構(gòu) 】

中控機管理工具，用于管理mha部署、主從切換等；****

****mha管理工具，支持部署、更新配置文件、目錄等開關(guān)。manager收集切換日志、集群互信、檢查ssh、repl狀態(tài)、配置文件一致性等。

【 核心腳本工作原理介紹 】

1) masterha_manager

mha啟動腳本為masterha_manager，可選參數(shù)為remove_dead_master_conf、manger_log、ignore_last_failover。

masterha_manager主要流程為：

1．調(diào)用MasterMonitor，監(jiān)控MySQL master狀態(tài)；

2．發(fā)現(xiàn)master狀態(tài)異常后，調(diào)用MasterFailover進行切換；

3．manager通過monitor監(jiān)測master狀態(tài)，一旦獲得返回值，則表明monitor狀態(tài)異常。通過判斷exit_code確定是否應切換。

4．檢測通過后，調(diào)用MasterFailover進執(zhí)行切換操作。

具體流程如下：

2) MasterMonitor

MasterHA_Manager調(diào)用MasterMonitor的main方法對MySQL進行監(jiān)控。

具體流程圖如下：

核心方法是一個死循環(huán)，不斷調(diào)用wait_until_master_is_dead方法監(jiān)測主庫狀態(tài)。wait_until_master_is_dead方法的返回值中，exit_code有的值有四種，分別是0、1、20、retry。其中只有當exit_code=MHA::ManagerConst::MASTER_DEAD_RC，也就是20時，后續(xù)才會調(diào)用failover方法。

wait_until_master_is_dead方法中，核心方法是調(diào)用wait_until_master_is_unreachable方法并處理其返回值。邏輯關(guān)系如下：

拿到wait_until_master_is_unreachable的返回值后，會再次根據(jù)配置文件探活，確認主庫連接失敗后，根據(jù)配置文件檢測slave狀態(tài)和數(shù)量，有合適新主庫后，exit_code返回20，否則返回0或者1。

wait_until_master_is_unreachable方法的返回值有三個，分別是ret、dead_master和ssh_reachable。該方法的邏輯如下：

wait_until_master_is_unreachable調(diào)用MHA::ServerManager對主庫進行實時檢測，包括deadservers、aliveservers、aliveslaves等。如果啟用GTID，則檢查binlog server，否則進行ssh和slave版本檢測。

后續(xù)使用MHA::HealthCheck對主庫進行ping檢查。檢查確認主庫的確不可達后，返回func_rc, current_master, ssh_reachable。

4

總結(jié)

MHA 由日本 DeNA 公司 youshimaton 開發(fā)，他認為在 GTID 環(huán)境下MHA 存在的價值不大，MHA 最近一次發(fā)版是 2018 年。現(xiàn)如今使用 MySQL 已離不開 GTID ，無論是從功能、性能角度，還是從維護角度，GTID 能具備更優(yōu)異的表現(xiàn)。但是無論是什么技術(shù)，他的核心原理都是可以自動將最新數(shù)據(jù)的Slave提升為新的 Master，然后將所有其他的Slave重新指向新的Master。整個故障轉(zhuǎn)移過程對應用程序是完全透明的，因此MHA的時代是值得被大家了解和記憶的。