MySQL高可用系統(tǒng)
MySQL高可用阴绢，顧名思義就是當(dāng)MySQL主機(jī)或服務(wù)發(fā)生任何故障時能夠立馬有其他主機(jī)頂替其工作，并且最低要求是要保證數(shù)據(jù)一致性翎朱。因此拇勃，對于一個MySQL高可用系統(tǒng)需要達(dá)到的目標(biāo)有以下幾點(diǎn)：
（1）、數(shù)據(jù)一致性保證這個是最基本的同時也是前提已骇，如果主備的數(shù)據(jù)不一致离钝，那么切換就無法進(jìn)行，當(dāng)然這里的一致性也是一個相對的褪储，但是要做到最終一致性卵渴。
（2）、故障快速切換鲤竹，當(dāng)master故障時這里可以是機(jī)器故障或者是實例故障浪读，要確保業(yè)務(wù)能在最短時間切換到備用節(jié)點(diǎn)昔榴，使得業(yè)務(wù)受影響時間最短。
（3）碘橘、簡化日常維護(hù)互订，通過高可用平臺來自動完成高可用的部署、維護(hù)痘拆、監(jiān)控等任務(wù)仰禽，能夠最大程度的解放DBA手動操作，提高日常運(yùn)維效率纺蛆。
（4）吐葵、統(tǒng)一管理，當(dāng)復(fù)制集很多的情況下桥氏，能夠統(tǒng)一管理高可用實例信息温峭、監(jiān)控信息、切換信息等字支。
（5）凤藏、高可用的部署要對現(xiàn)有的數(shù)據(jù)庫架構(gòu)無影響，如果因為部署高可用堕伪，需要更改或者調(diào)整數(shù)據(jù)庫架構(gòu)則會導(dǎo)致成本增加揖庄。
目前MySQL高可用方案可以一定程度上實現(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)桂塞，因為MySQL GP還不能在生產(chǎn)使用凹蜂，但是相信以后慢慢就會被用到生產(chǎn)環(huán)境的。
MHA技術(shù)介紹
MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案阁危，它由日本DeNA公司youshimaton（現(xiàn)就職于Facebook公司）開發(fā)玛痊，是一套優(yōu)秀的作為MySQL高可用性環(huán)境下故障切換和主從提升的高可用軟件。在MySQL故障切換過程中狂打，MHA能做到在0~30秒之內(nèi)自動完成數(shù)據(jù)庫的故障切換操作擂煞，并且在進(jìn)行故障切換的過程中，MHA能在最大程度上保證數(shù)據(jù)的一致性趴乡，以達(dá)到真正意義上的高可用对省。除了failover之外蝗拿，MHA還支持在線master切換，非常安全和高效蒿涎，大概只需要（0.5 ~ 2秒）的阻塞寫時間哀托。
該軟件由兩部分組成：MHA Manager（管理節(jié)點(diǎn)）和MHA Node（數(shù)據(jù)節(jié)點(diǎn)）。MHA Manager可以單獨(dú)部署在一臺獨(dú)立的機(jī)器上管理多個master-slave集群劳秋，也可以部署在一臺slave節(jié)點(diǎn)上仓手。MHA Node運(yùn)行在每臺MySQL服務(wù)器上，MHA Manager會定時探測集群中的master節(jié)點(diǎn)俗批，當(dāng)master出現(xiàn)故障時俗或，它可以自動將最新數(shù)據(jù)的slave提升為新的master市怎，然后將所有其他的slave重新指向新的master岁忘。整個故障轉(zhuǎn)移過程對應(yīng)用程序完全透明。
目前MHA主要支持一主多從的架構(gòu)区匠，要搭建MHA干像，要求一個復(fù)制集群中必須最少有三臺數(shù)據(jù)庫服務(wù)器，一主二從驰弄，即一臺充當(dāng)master麻汰，一臺充當(dāng)備用master，另外一臺充當(dāng)slave戚篙。當(dāng)然五鲫，如果你處于成本考慮，也可以使用兩個節(jié)點(diǎn)的MHA岔擂，一主一從（實測過的）位喂。
總結(jié)一下，MHA提供了如下功能：
（1）master自動監(jiān)控乱灵，故障轉(zhuǎn)移一體化(Automated master monitoring and failover)
（2）MHA可以在一個復(fù)制組中監(jiān)控master的狀態(tài)塑崖，如果掛了，就可以自動的做failover痛倚。
（3）MHA通過所有slave的差異relay-log來保證數(shù)據(jù)的一致性规婆。
（4）MHA在做故障轉(zhuǎn)移，日志補(bǔ)償這些動作的時候蝉稳，通常只需要10~30秒抒蚜。
（5）通常情況下，MHA會選擇最新的slave作為new master耘戚，但是你也可以指定哪些是候選maser嗡髓，那么新master選舉的時候，就從這些host里面挑毕莱。
（6）導(dǎo)致復(fù)制環(huán)境中斷的一致性問題器贩，在MHA中是不會發(fā)生的颅夺，請放心使用。
在MHA自動故障切換過程中蛹稍，MHA試圖從宕機(jī)的主服務(wù)器上保存二進(jìn)制日志吧黄，最大程度的保證數(shù)據(jù)的不丟失，但這并不總是可行的唆姐。例如拗慨，如果主服務(wù)器硬件故障或無法通過ssh訪問，MHA沒法保存二進(jìn)制日志奉芦，只進(jìn)行故障轉(zhuǎn)移而丟失了最新的數(shù)據(jù)赵抢。使用MySQL 5.5及以上版本的半同步復(fù)制，可以大大降低數(shù)據(jù)丟失的風(fēng)險声功。MHA可以與半同步復(fù)制結(jié)合起來烦却。如果只有一個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）
非交互式摩渺，自動的故障轉(zhuǎn)移，不提供監(jiān)控master狀態(tài)功能剂邮，監(jiān)控可以交給其他組件做（如：Pacemaker heartbeat）摇幻。
（9）在線master切換 （Online switching master to a different host）
如果你有更快，更好的master挥萌，計劃要將老master替換成新的master绰姻，那么這個功能特別適合這樣的場景。
這不是master真的掛掉了瑞眼，只是我們有很多需求要進(jìn)行master例行維護(hù)龙宏。
MHA的優(yōu)點(diǎn)
1. master failover和slave promotion非常快速伤疙。
- 自動探測银酗，多重檢測，切換過程中支持調(diào)用其他腳本的接口徒像。
3. master crash不會導(dǎo)致數(shù)據(jù)不一致黍特，自動補(bǔ)齊數(shù)據(jù)，維護(hù)數(shù)據(jù)一致性锯蛀。
4. 不需要修改復(fù)制的任何設(shè)置灭衷，簡單易部署，對現(xiàn)有架構(gòu)無影響旁涤。
5. 不需要增加很多額外的機(jī)器來部署MHA翔曲，支持多實例集中管理迫像。
6. 沒有任何性能影響。
7. 支持在線切換瞳遍。
8. 跨存儲引擎闻妓，支持任何引擎。
官方介紹：https://code.google.com/p/mysql-master-ha
MHA工作流程
下圖展示了如何通過MHA Manager管理多組主從復(fù)制掠械，可以將MHA工作原理總結(jié)為如下：
1由缆、MHA如何監(jiān)控master和故障轉(zhuǎn)移？
1.1 驗證復(fù)制設(shè)置以及確認(rèn)當(dāng)前master狀態(tài)
連接所有hosts猾蒂，MHA自動來確認(rèn)當(dāng)前master是哪個均唉，配置文件中無需指定哪個是master。
如果其中有任何一個slave掛了肚菠，腳本立即退出舔箭，停止監(jiān)控。
如果有一些必要的腳本沒有在MHA Node節(jié)點(diǎn)安裝案糙，那么MHA在這個階段終止限嫌，且停止監(jiān)控靴庆。
1.2 監(jiān)控master
監(jiān)控master时捌，直到master掛了。
這個階段炉抒，MHA不會監(jiān)控slave奢讨，Stopping/Restarting/Adding/Removing操作在slave上，不會影響當(dāng)前的MHA監(jiān)控進(jìn)程焰薄。當(dāng)你添加或者刪除slave的時候拿诸，請更新好配置文件，最好重啟MHA塞茅。
1.3 檢測master是否失敗
如果MHA Manger三次間隔時間都沒辦法連接master server亩码，就會進(jìn)入這個階段。
如果你設(shè)置了secondary_check_script 野瘦，那么MHA會調(diào)用腳本做二次檢測來判斷master是否是真的掛了描沟。
接下來的步驟，就是masterha_master_switch的工作流程了鞭光。
1.4 再次驗證slave的配置
如果發(fā)現(xiàn)任何不合法的復(fù)制配置（有些slave的master不是同一個）吏廉，那么MHA會停止監(jiān)控，且報錯惰许∠玻可以設(shè)置ignore_fail忽略。
這一步是處于安全考慮汹买，很有可能佩伤，復(fù)制的配置文件已經(jīng)被改掉了聊倔，所以double check是比較推薦的做法。
檢查最后一次failover（故障轉(zhuǎn)移）的狀態(tài)
如果上一次的failover報錯生巡，或者上一次的failover結(jié)束的太近（默認(rèn)3天）方库，MHA停止監(jiān)控，停止failover障斋，那么在masterha_manager命令中設(shè)置ignore_last_failover纵潦，wait_on_failover_error來改變這一檢測。這么做垃环，也是出于安全考慮邀层。頻繁的failover，檢查下是否網(wǎng)絡(luò)出問題遂庄，或者其他錯誤呢寥院？
1.5 關(guān)掉失敗的master的服務(wù)器（可選）
如果在配置文件中定義了master_ip_failover_script and/or shutdown_script ，MHA會調(diào)用這些的腳本涛目。
關(guān)閉dead master秸谢，避免腦裂（值得商榷）。
1.6 恢復(fù)一臺新master
從crashed master服務(wù)器上保存binlog到Manager（如果可以的話
如果dead master可以SSH的話霹肝，拷貝binary logs從最新的slave上的end_log_pos(Read_Master_Log_Pos)位置開始拷貝估蹄。
選舉新master
一般根據(jù)配置文件的設(shè)置來決定選舉誰，如果想設(shè)置一些候選master沫换，設(shè)置candidate_master=1臭蚁；如果想設(shè)置一些host，永遠(yuǎn)都不會選舉讯赏，設(shè)置no_master=1垮兑；確認(rèn)最新的slave （這臺slave擁有最新的relay-log）。
恢復(fù)和提升新master
根據(jù)老master binlog生成差異日志漱挎，應(yīng)用日志到new master系枪，如果這一步發(fā)生錯誤（如：duplicate key error），MHA停止恢復(fù)磕谅，并且其余的slave也停止恢復(fù)私爷。
2）MHA如何在線快速切換master？
下面的步驟怜庸，就是masterha_master_switch—master_state=alive做的事情当犯。
2.1 驗證復(fù)制設(shè)置以及確認(rèn)當(dāng)前master狀態(tài)
連接配置文件中列出的所有hosts，MHA自動來確認(rèn)當(dāng)前master是哪個割疾，配置文件中無需指定哪個是master嚎卫。
執(zhí)行 flush tables 命令在master上（可選）. 這樣可以縮短FLUSH TABLES WITH READ LOCK的時間。
既不監(jiān)控master，也不會failover拓诸。
檢查下面的條件是否滿足侵佃。
A. IO線程是否在所有slave上都是running。
B. SQL線程是否在所有slave上都是running奠支。
C. Seconds_Behind_Master 是否低于2秒（—running_updates_limit=N）馋辈。
D. master上是否沒有長的更新語句大于2秒。
2.2 確認(rèn)新master
新master需要設(shè)置： –new_master_host參數(shù)倍谜。
原來的master和新的master必須要有同樣的復(fù)制過濾條件（binlog-do-db and binlog-ignore-db）迈螟。
2.3 當(dāng)前master停寫
如果你在配置中定義了master_ip_online_change_script，MHA會調(diào)用它尔崔〈鸷粒可以通過設(shè)置SET GLOBAL read_only=1來完美的阻止寫入。
在老master上執(zhí)行FLUSH TABLES WITH READ LOCK來阻止所有的寫（–skip_lock_all_tables可以忽略這一步）季春。
2.4 等待其他slave追上當(dāng)前master洗搂，同步無延遲
調(diào)用這個函數(shù)MASTER_LOG_POS()。
2.5 確保新master可寫
執(zhí)行SHOW MASTER STATUS來確定新master的binary log文件名和position载弄。
如果設(shè)置了master_ip_online_change_script耘拇，會調(diào)用它∮罟ィ可以創(chuàng)建寫權(quán)限的用戶惫叛，SET GLOBAL read_only=0。
2.6 讓其他slave指向新master
并行執(zhí)行CHANGE MASTER, START SLAVE尺碰。
MHA組件介紹
MHA軟件由兩部分組成挣棕，Manager工具包和Node工具包，具體的說明如下亲桥。
Manager工具包主要包括以下幾個工具：
（1）masterha_check_ssh #檢查MHA的SSH配置狀況;
（2）masterha_check_repl #檢查MySQL復(fù)制狀況;
（3）masterha_manger #啟動MHA;
（4）masterha_check_status #檢測當(dāng)前MHA運(yùn)行狀態(tài);
（5）masterha_master_monitor #檢測master是否宕機(jī);
（6）masterha_master_switch #控制故障轉(zhuǎn)移(自動或者手動);
（7）masterha_conf_host #添加或刪除配置的server信息;
Node工具包（這些工具通常由MHA Manager的腳本觸發(fā)，無需人為操作）主要包括以下幾個工具：
（1）save_binary_logs #保存和復(fù)制master的二進(jìn)制日志;
（2）apply_diff_relay_logs #識別差異的中繼日志事件并將其差異的事件應(yīng)用于其他的slave;
（3）purge_relay_logs #清除中繼日志（不會阻塞SQL線程）;
注意：為了盡可能的減少主庫硬件損壞宕機(jī)造成的數(shù)據(jù)丟失固耘，因此在配置MHA的同時建議配置成MySQL半同步復(fù)制题篷。關(guān)于半同步復(fù)制原理各位自己進(jìn)行查閱（不是必須）。
