[[272341]]

概述

MySQL高可用，顧名思義就是當(dāng)MySQL主機(jī)或服務(wù)發(fā)生任何故障時能夠立馬有其他主機(jī)頂替其工作，并且最低要求是要保證數(shù)據(jù)一致性。因此，對于一個MySQL高可用系統(tǒng)需要達(dá)到的目標(biāo)有以下幾點(diǎn)：

• 數(shù)據(jù)一致性保證--這個是最基本的同時也是前提，如果主備的數(shù)據(jù)不一致，那么切換就無法進(jìn)行，當(dāng)然這里的一致性也是一個相對的，但是要做到最終一致性。
• 故障快速切換--當(dāng)master故障時這里可以是機(jī)器故障或者是實(shí)例故障，要確保業(yè)務(wù)能在最短時間切換到備用節(jié)點(diǎn)，使得業(yè)務(wù)受影響時間最短。
• 簡化日常維護(hù)--通過高可用平臺來自動完成高可用的部署、維護(hù)、監(jiān)控等任務(wù)，能夠最大程度的解放DBA手動操作，提高日常運(yùn)維效率。
• 統(tǒng)一管理--當(dāng)復(fù)制集很多的情況下，能夠統(tǒng)一管理高可用實(shí)例信息、監(jiān)控信息、切換信息等。
• 高可用的部署--要對現(xiàn)有的數(shù)據(jù)庫架構(gòu)無影響，如果因為部署高可用，需要更改或者調(diào)整數(shù)據(jù)庫架構(gòu)則會導(dǎo)致成本增加。

MySQL MHA

MHA是一位日本MySQL大牛用Perl寫一套MySQL故障切換方案，來保證數(shù)據(jù)庫系統(tǒng)的高可用，在宕機(jī)的事件內(nèi)(通常10-30秒)，完成故障轉(zhuǎn)意，部署MHA，可避免主從一致性問題，節(jié)約購買新服務(wù)器的費(fèi)用，不影響服務(wù)器性能，易安裝，不改變現(xiàn)有部署架構(gòu)。

MHA(Master HA)為MySQL主從復(fù)制架構(gòu)提供了automating master failover 功能。MHA在監(jiān)控到master節(jié)點(diǎn)故障時，會提升其中擁有最新數(shù)據(jù)的slave節(jié)點(diǎn)成為新的master節(jié)點(diǎn)，在此期間，MHA會通過與其它從節(jié)點(diǎn)獲取額外信息來避免一致性方面的問題。MHA還提供了master節(jié)點(diǎn)的在線切換功能，即按需切換master/slave節(jié)點(diǎn)。

相較于其它HA軟件，MHA的目的在于維持MySQL Replication中Master庫的高可用性，其最大特點(diǎn)是可以修復(fù)多個Slave之間的差異日志，最終使所有Slave保持?jǐn)?shù)據(jù)一致，然后從中選擇一個充當(dāng)新的Master，并將其它Slave指向它。

應(yīng)用場景

一主多從的環(huán)境下，MySQL的主從復(fù)制是異步或是半同步。

Master發(fā)生故障的時候，有可能一部分(或者全部)的Slave未能獲取到最新的binlog，造成Slave之間的binlog轉(zhuǎn)發(fā)發(fā)生偏差。

如下圖所示，Master宕機(jī)之后，id=102的binlog未能被發(fā)送到任何一個Slave上，id=101的binlog只有save2上有，slave3上未能收到id=100和id=101的binlog

如果想要正確恢復(fù)：

• Master必須發(fā)出的ID=102的binlog
• 還要消除各個Slave之間的差異性

而MHA可以全自動的處理以上這些問題。

MHA架構(gòu)

MHA架構(gòu)如下：

可實(shí)現(xiàn)master工作狀態(tài)的監(jiān)控以及宕機(jī)時的故障轉(zhuǎn)移

MHA原理

MHA原理如下圖：

• 1、等待SQL線程執(zhí)行完畢
• 2、解析最新的Slave上的中繼日志(relay log)的日志頭(log Header)，為其他各個服務(wù)器確定出差異位置
• 3、將i1-->i2-->X 全部組成一個二進(jìn)制日志

MHA的主要特性

• 從master的監(jiān)控到故障轉(zhuǎn)移全部都能自動完成，故障轉(zhuǎn)移也可手動執(zhí)行
• 可在秒級單位內(nèi)實(shí)現(xiàn)故障轉(zhuǎn)移
• 可將任意Slave提升至master
• 具備在多個點(diǎn)上調(diào)用外部腳本(擴(kuò)展)的技能，可以用在電源OFF或者IP地址的故障轉(zhuǎn)移上。
• 安裝和卸載不用停止當(dāng)前的mysql進(jìn)程
• MHA 自身不會增加服務(wù)器負(fù)擔(dān)，不會降低性能，不用追加服務(wù)器
• 不依賴Storage Engine
• 不依賴二進(jìn)制文件的格式(不論是statement模式還是Row模式)

MHA組件

1、 Manager工具:

– masterha_check_ssh : 檢查MHA的SSH配置。

– masterha_check_repl : 檢查MySQL復(fù)制。

– masterha_manager : 啟動MHA。

– masterha_check_status : 檢測當(dāng)前MHA運(yùn)行狀態(tài)。

– masterha_master_monitor : 監(jiān)測master是否宕機(jī)。

– masterha_master_switch : 控制故障轉(zhuǎn)移(自動或手動)。

– masterha_conf_host : 添加或刪除配置的server信息。

2、 Node工具(這些工具通常由MHAManager的腳本觸發(fā),無需人手操作)。

– save_binary_logs : 保存和復(fù)制master的二進(jìn)制日志。

– apply_diff_relay_logs : 識別差異的中繼日志事件并應(yīng)用于其它slave。

– filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用這個工具)。

– purge_relay_logs : 清除中繼日志(不會阻塞SQL線程)。

3、自定義擴(kuò)展：

-secondary_check_script：通過多條網(wǎng)絡(luò)路由檢測master的可用性;

-master_ip_failover_script：更新application使用的masterip; (需要修改)

-shutdown_script：強(qiáng)制關(guān)閉master節(jié)點(diǎn);

-report_script：發(fā)送報告;

-init_conf_load_script：加載初始配置參數(shù);

-master_ip_online_change：更新master節(jié)點(diǎn)ip地址;(需要修改)

總結(jié)

目前MySQL高可用方案可以一定程度上實(shí)現(xiàn)數(shù)據(jù)庫的高可用，比如MMM，heartbeat+drbd，NDB Cluster等。還有MariaDB的Galera Cluster，以及MySQL 5.7.17 Group Replication等。這些高可用軟件各有優(yōu)劣。在進(jìn)行高可用方案選擇時，主要是看業(yè)務(wù)對數(shù)據(jù)一致性方面的要求。不過出于對數(shù)據(jù)庫的高可用和高可靠的要求，個人比較推薦使用MHA架構(gòu)。