MySQL高可用系統(tǒng)
MySQL高可用，顧名思義就是當(dāng)MySQL主機(jī)或服務(wù)發(fā)生任何故障時(shí)能夠立馬有其他主機(jī)頂替其工作，并且最低要求是要保證數(shù)據(jù)一致性。因此，對(duì)于一個(gè)MySQL高可用系統(tǒng)需要達(dá)到的目標(biāo)有以下幾點(diǎn)：
（1）、數(shù)據(jù)一致性保證這個(gè)是最基本的同時(shí)也是前提，如果主備的數(shù)據(jù)不一致，那么切換就無(wú)法進(jìn)行，當(dāng)然這里的一致性也是一個(gè)相對(duì)的，但是要做到最終一致性。
（2）、故障快速切換，當(dāng)master故障時(shí)這里可以是機(jī)器故障或者是實(shí)例故障，要確保業(yè)務(wù)能在最短時(shí)間切換到備用節(jié)點(diǎn)，使得業(yè)務(wù)受影響時(shí)間最短。
（3）、簡(jiǎn)化日常維護(hù)，通過(guò)高可用平臺(tái)來(lái)自動(dòng)完成高可用的部署、維護(hù)、監(jiān)控等任務(wù)，能夠最大程度的解放DBA手動(dòng)操作，提高日常運(yùn)維效率。
（4）、統(tǒng)一管理，當(dāng)復(fù)制集很多的情況下，能夠統(tǒng)一管理高可用實(shí)例信息、監(jiān)控信息、切換信息等。
（5）、高可用的部署要對(duì)現(xiàn)有的數(shù)據(jù)庫(kù)架構(gòu)無(wú)影響，如果因?yàn)椴渴鸶呖捎?，需要更改或者調(diào)整數(shù)據(jù)庫(kù)架構(gòu)則會(huì)導(dǎo)致成本增加。
目前MySQL高可用方案可以一定程度上實(shí)現(xiàn)數(shù)據(jù)庫(kù)的高可用，比如MMM，heartbeat+drbd，NDB Cluster等。還有MariaDB的Galera Cluster，以及MySQL 5.7.17 Group Replication等。這些高可用軟件各有優(yōu)劣。在進(jìn)行高可用方案選擇時(shí)，主要是看業(yè)務(wù)對(duì)數(shù)據(jù)一致性方面的要求。最后出于對(duì)數(shù)據(jù)庫(kù)的高可用和高可靠的要求，目前推薦使用MHA架構(gòu)，因?yàn)镸ySQL GP還不能在生產(chǎn)使用，但是相信以后慢慢就會(huì)被用到生產(chǎn)環(huán)境的。
MHA技術(shù)介紹
MHA（Master High Availability）目前在MySQL高可用方面是一個(gè)相對(duì)成熟的解決方案，它由日本DeNA公司youshimaton（現(xiàn)就職于Facebook公司）開(kāi)發(fā)，是一套優(yōu)秀的作為MySQL高可用性環(huán)境下故障切換和主從提升的高可用軟件。在MySQL故障切換過(guò)程中，MHA能做到在0~30秒之內(nèi)自動(dòng)完成數(shù)據(jù)庫(kù)的故障切換操作，并且在進(jìn)行故障切換的過(guò)程中，MHA能在最大程度上保證數(shù)據(jù)的一致性，以達(dá)到真正意義上的高可用。除了failover之外，MHA還支持在線master切換，非常安全和高效，大概只需要（0.5 ~ 2秒）的阻塞寫(xiě)時(shí)間。
該軟件由兩部分組成：MHA Manager（管理節(jié)點(diǎn)）和MHA Node（數(shù)據(jù)節(jié)點(diǎn)）。MHA Manager可以單獨(dú)部署在一臺(tái)獨(dú)立的機(jī)器上管理多個(gè)master-slave集群，也可以部署在一臺(tái)slave節(jié)點(diǎn)上。MHA Node運(yùn)行在每臺(tái)MySQL服務(wù)器上，MHA Manager會(huì)定時(shí)探測(cè)集群中的master節(jié)點(diǎn)，當(dāng)master出現(xiàn)故障時(shí)，它可以自動(dòng)將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master。整個(gè)故障轉(zhuǎn)移過(guò)程對(duì)應(yīng)用程序完全透明。
目前MHA主要支持一主多從的架構(gòu)，要搭建MHA，要求一個(gè)復(fù)制集群中必須最少有三臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，一主二從，即一臺(tái)充當(dāng)master，一臺(tái)充當(dāng)備用master，另外一臺(tái)充當(dāng)slave。當(dāng)然，如果你處于成本考慮，也可以使用兩個(gè)節(jié)點(diǎn)的MHA，一主一從（實(shí)測(cè)過(guò)的）。
總結(jié)一下，MHA提供了如下功能：
（1）master自動(dòng)監(jiān)控，故障轉(zhuǎn)移一體化(Automated master monitoring and failover)
（2）MHA可以在一個(gè)復(fù)制組中監(jiān)控master的狀態(tài)，如果掛了，就可以自動(dòng)的做failover。
（3）MHA通過(guò)所有slave的差異relay-log來(lái)保證數(shù)據(jù)的一致性。
（4）MHA在做故障轉(zhuǎn)移，日志補(bǔ)償這些動(dòng)作的時(shí)候，通常只需要10~30秒。
（5）通常情況下，MHA會(huì)選擇最新的slave作為new master，但是你也可以指定哪些是候選maser，那么新master選舉的時(shí)候，就從這些host里面挑。
（6）導(dǎo)致復(fù)制環(huán)境中斷的一致性問(wèn)題，在MHA中是不會(huì)發(fā)生的，請(qǐng)放心使用。
在MHA自動(dòng)故障切換過(guò)程中，MHA試圖從宕機(jī)的主服務(wù)器上保存二進(jìn)制日志，最大程度的保證數(shù)據(jù)的不丟失，但這并不總是可行的。例如，如果主服務(wù)器硬件故障或無(wú)法通過(guò)ssh訪問(wèn)，MHA沒(méi)法保存二進(jìn)制日志，只進(jìn)行故障轉(zhuǎn)移而丟失了最新的數(shù)據(jù)。使用MySQL 5.5及以上版本的半同步復(fù)制，可以大大降低數(shù)據(jù)丟失的風(fēng)險(xiǎn)。MHA可以與半同步復(fù)制結(jié)合起來(lái)。如果只有一個(gè)slave已經(jīng)收到了最新的二進(jìn)制日志，MHA可以將最新的二進(jìn)制日志應(yīng)用于其他所有的slave服務(wù)器上，因此可以保證所有節(jié)點(diǎn)的數(shù)據(jù)一致性。
（7）手工-交互式master故障轉(zhuǎn)移（Interactive manually initiated Master Failover）
MHA可以配置成手工-交互式方式進(jìn)行故障轉(zhuǎn)移，不支持監(jiān)控master的狀態(tài)。
（8）非交互式master故障轉(zhuǎn)移 （Non-interactive master failover）
非交互式，自動(dòng)的故障轉(zhuǎn)移，不提供監(jiān)控master狀態(tài)功能，監(jiān)控可以交給其他組件做（如：Pacemaker heartbeat）。
（9）在線master切換 （Online switching master to a different host）
如果你有更快，更好的master，計(jì)劃要將老master替換成新的master，那么這個(gè)功能特別適合這樣的場(chǎng)景。
這不是master真的掛掉了，只是我們有很多需求要進(jìn)行master例行維護(hù)。
MHA的優(yōu)點(diǎn)
1. master failover和slave promotion非常快速。
- 自動(dòng)探測(cè)，多重檢測(cè)，切換過(guò)程中支持調(diào)用其他腳本的接口。
3. master crash不會(huì)導(dǎo)致數(shù)據(jù)不一致，自動(dòng)補(bǔ)齊數(shù)據(jù)，維護(hù)數(shù)據(jù)一致性。
4. 不需要修改復(fù)制的任何設(shè)置，簡(jiǎn)單易部署，對(duì)現(xiàn)有架構(gòu)無(wú)影響。
5. 不需要增加很多額外的機(jī)器來(lái)部署MHA，支持多實(shí)例集中管理。
6. 沒(méi)有任何性能影響。
7. 支持在線切換。
8. 跨存儲(chǔ)引擎，支持任何引擎。
官方介紹：https://code.google.com/p/mysql-master-ha
MHA工作流程
下圖展示了如何通過(guò)MHA Manager管理多組主從復(fù)制，可以將MHA工作原理總結(jié)為如下：
1、MHA如何監(jiān)控master和故障轉(zhuǎn)移？
1.1 驗(yàn)證復(fù)制設(shè)置以及確認(rèn)當(dāng)前master狀態(tài)
連接所有hosts，MHA自動(dòng)來(lái)確認(rèn)當(dāng)前master是哪個(gè)，配置文件中無(wú)需指定哪個(gè)是master。
如果其中有任何一個(gè)slave掛了，腳本立即退出，停止監(jiān)控。
如果有一些必要的腳本沒(méi)有在MHA Node節(jié)點(diǎn)安裝，那么MHA在這個(gè)階段終止，且停止監(jiān)控。
1.2 監(jiān)控master
監(jiān)控master，直到master掛了。
這個(gè)階段，MHA不會(huì)監(jiān)控slave，Stopping/Restarting/Adding/Removing操作在slave上，不會(huì)影響當(dāng)前的MHA監(jiān)控進(jìn)程。當(dāng)你添加或者刪除slave的時(shí)候，請(qǐng)更新好配置文件，最好重啟MHA。
1.3 檢測(cè)master是否失敗
如果MHA Manger三次間隔時(shí)間都沒(méi)辦法連接master server，就會(huì)進(jìn)入這個(gè)階段。
如果你設(shè)置了secondary_check_script ，那么MHA會(huì)調(diào)用腳本做二次檢測(cè)來(lái)判斷master是否是真的掛了。
接下來(lái)的步驟，就是masterha_master_switch的工作流程了。
1.4 再次驗(yàn)證slave的配置
如果發(fā)現(xiàn)任何不合法的復(fù)制配置（有些slave的master不是同一個(gè)），那么MHA會(huì)停止監(jiān)控，且報(bào)錯(cuò)。可以設(shè)置ignore_fail忽略。
這一步是處于安全考慮，很有可能，復(fù)制的配置文件已經(jīng)被改掉了，所以double check是比較推薦的做法。
檢查最后一次failover（故障轉(zhuǎn)移）的狀態(tài)
如果上一次的failover報(bào)錯(cuò)，或者上一次的failover結(jié)束的太近（默認(rèn)3天），MHA停止監(jiān)控，停止failover，那么在masterha_manager命令中設(shè)置ignore_last_failover，wait_on_failover_error來(lái)改變這一檢測(cè)。這么做，也是出于安全考慮。頻繁的failover，檢查下是否網(wǎng)絡(luò)出問(wèn)題，或者其他錯(cuò)誤呢？
1.5 關(guān)掉失敗的master的服務(wù)器（可選）
如果在配置文件中定義了master_ip_failover_script and/or shutdown_script ，MHA會(huì)調(diào)用這些的腳本。
關(guān)閉dead master，避免腦裂（值得商榷）。
1.6 恢復(fù)一臺(tái)新master
從crashed master服務(wù)器上保存binlog到Manager（如果可以的話
如果dead master可以SSH的話，拷貝binary logs從最新的slave上的end_log_pos(Read_Master_Log_Pos)位置開(kāi)始拷貝。
選舉新master
一般根據(jù)配置文件的設(shè)置來(lái)決定選舉誰(shuí)，如果想設(shè)置一些候選master，設(shè)置candidate_master=1；如果想設(shè)置一些host，永遠(yuǎn)都不會(huì)選舉，設(shè)置no_master=1；確認(rèn)最新的slave （這臺(tái)slave擁有最新的relay-log）。
恢復(fù)和提升新master
根據(jù)老master binlog生成差異日志，應(yīng)用日志到new master，如果這一步發(fā)生錯(cuò)誤（如：duplicate key error），MHA停止恢復(fù)，并且其余的slave也停止恢復(fù)。
2）MHA如何在線快速切換master？
下面的步驟，就是masterha_master_switch—master_state=alive做的事情。
2.1 驗(yàn)證復(fù)制設(shè)置以及確認(rèn)當(dāng)前master狀態(tài)
連接配置文件中列出的所有hosts，MHA自動(dòng)來(lái)確認(rèn)當(dāng)前master是哪個(gè)，配置文件中無(wú)需指定哪個(gè)是master。
執(zhí)行 flush tables 命令在master上（可選）. 這樣可以縮短FLUSH TABLES WITH READ LOCK的時(shí)間。
既不監(jiān)控master，也不會(huì)failover。
檢查下面的條件是否滿足。
A. IO線程是否在所有slave上都是running。
B. SQL線程是否在所有slave上都是running。
C. Seconds_Behind_Master 是否低于2秒（—running_updates_limit=N）。
D. master上是否沒(méi)有長(zhǎng)的更新語(yǔ)句大于2秒。
2.2 確認(rèn)新master
新master需要設(shè)置： –new_master_host參數(shù)。
原來(lái)的master和新的master必須要有同樣的復(fù)制過(guò)濾條件（binlog-do-db and binlog-ignore-db）。
2.3 當(dāng)前master停寫(xiě)
如果你在配置中定義了master_ip_online_change_script，MHA會(huì)調(diào)用它。可以通過(guò)設(shè)置SET GLOBAL read_only=1來(lái)完美的阻止寫(xiě)入。
在老master上執(zhí)行FLUSH TABLES WITH READ LOCK來(lái)阻止所有的寫(xiě)（–skip_lock_all_tables可以忽略這一步）。
2.4 等待其他slave追上當(dāng)前master，同步無(wú)延遲
調(diào)用這個(gè)函數(shù)MASTER_LOG_POS()。
2.5 確保新master可寫(xiě)
執(zhí)行SHOW MASTER STATUS來(lái)確定新master的binary log文件名和position。
如果設(shè)置了master_ip_online_change_script，會(huì)調(diào)用它。可以創(chuàng)建寫(xiě)權(quán)限的用戶，SET GLOBAL read_only=0。
2.6 讓其他slave指向新master
并行執(zhí)行CHANGE MASTER, START SLAVE。
MHA組件介紹
MHA軟件由兩部分組成，Manager工具包和Node工具包，具體的說(shuō)明如下。
Manager工具包主要包括以下幾個(gè)工具：
（1）masterha_check_ssh #檢查MHA的SSH配置狀況;
（2）masterha_check_repl #檢查MySQL復(fù)制狀況;
（3）masterha_manger #啟動(dòng)MHA;
（4）masterha_check_status #檢測(cè)當(dāng)前MHA運(yùn)行狀態(tài);
（5）masterha_master_monitor #檢測(cè)master是否宕機(jī);
（6）masterha_master_switch #控制故障轉(zhuǎn)移(自動(dòng)或者手動(dòng));
（7）masterha_conf_host #添加或刪除配置的server信息;
Node工具包（這些工具通常由MHA Manager的腳本觸發(fā)，無(wú)需人為操作）主要包括以下幾個(gè)工具：
（1）save_binary_logs #保存和復(fù)制master的二進(jìn)制日志;
（2）apply_diff_relay_logs #識(shí)別差異的中繼日志事件并將其差異的事件應(yīng)用于其他的slave;
（3）purge_relay_logs #清除中繼日志（不會(huì)阻塞SQL線程）;
注意：為了盡可能的減少主庫(kù)硬件損壞宕機(jī)造成的數(shù)據(jù)丟失，因此在配置MHA的同時(shí)建議配置成MySQL半同步復(fù)制。關(guān)于半同步復(fù)制原理各位自己進(jìn)行查閱（不是必須）。
