GitHubAvailabilityIssue總結(jié)_MySQL

基于這三點總結(jié)就拋出了三個問題：

1. 現(xiàn)有的HA軟件是否可靠，可信？是否在正確的時候做了正確的判斷和操作？

2. 沒有集中管理機(jī)的HA架構(gòu)（即內(nèi)部投票）是否可靠？

3. HA的Failover過程是否要考慮數(shù)據(jù)預(yù)熱？

以下是對于這三個問題的一些分析和個人看法：

問題一：現(xiàn)有的HA軟件是否可靠，可信？是否在正確的時候做了正確的判斷和操作？

GitHub團(tuán)隊認(rèn)為：The automated failover of our main production database could be described as the root cause of both of these downtime events.

而對于這個問題，我的想法和 Xaprd的觀點 一致：事故的關(guān)鍵在于現(xiàn)有的HA軟件都沒法照顧到所有可能發(fā)生的情況，以至于在某些情況下的行為是不可預(yù)測的，或者非我們所想的。

因此一味的將切換操作置成手工模式，雖然避免了風(fēng)險，但顯然沒有很好的使用HA軟件所提供的service。

個人想法是，對于一些原因明確且有明確cookbook的事故，可以讓HA去完成failover。而對于那些需要人工介入分析故障原因的事故，做手工切換，如果github遇到的timeout等。

問題二： 沒有集中管理機(jī)的HA架構(gòu)（即內(nèi)部投票）是否可靠？

從目前的流行程度來看，MMM，MHA這些使用Manager管理模式的架構(gòu)，已經(jīng)逐漸替代 Heartbeat + LVS/ Pacemaker 等投票模式的架構(gòu)。

其主要原因就是在沒有仲裁機(jī)的情況下，發(fā)生網(wǎng)絡(luò)partition會造成腦裂，從而導(dǎo)致active角色的互相爭搶，最后使整個cluster癱瘓。

Github再次用血的教訓(xùn)告訴我們腦裂是無仲裁架構(gòu)的致命缺陷。

問題三：HA的Failover過程是否要考慮數(shù)據(jù)預(yù)熱？

這個問題顯然是引起本次問題的關(guān)鍵：沒有預(yù)熱的切換才是萬惡之源。腦裂只是連鎖反應(yīng)而已。

而貌似整個社區(qū)的blog中對于這個問題的討論卻是少之又少，也許是重視程度不夠？

會造成切換后壓力劇增可能的情況，我總結(jié)為以下三種：

1. stand-by-master完全作為冗余，BufferPool 基本沒有熱點數(shù)據(jù)

2. stand-by-master提供read-only服務(wù)，但read-only 和 acitve master 的請求業(yè)務(wù)類型不同，導(dǎo)致熱點數(shù)據(jù)不同

3. 原本active的MySQL宕機(jī)后重新回歸，此時重啟后的MySQL是處于完全Cold 狀態(tài)

但目前眾多HA軟件中都沒有考慮預(yù)熱的因素，畢竟所有的failover都希望盡快的將業(yè)務(wù)轉(zhuǎn)移至stand-by master，而預(yù)熱則需要盡可能多的時間來獲取業(yè)務(wù)的請求。

也許這是一個無解命題？

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com