在企業(yè)環(huán)境中的停機(jī)成本迅速增加。在一項(xiàng)調(diào)查中，40% 的受訪者表示，僅僅一個(gè)小時(shí)的停機(jī)就使得他們的組織損失了 100 萬(wàn)美金以上。確保數(shù)據(jù)庫(kù)服務(wù)持續(xù)可用顯然是值得的。
它為你的組織節(jié)省了大量資金，更不用說與各種形式和規(guī)模的利益相關(guān)者的關(guān)系。
那么你如何確保持續(xù)可用性？持續(xù)可用性背后的概念被稱為 高可用性 。在本文中，我們將概述什么是高可用性以及如何為你的 MySQL 集群實(shí)現(xiàn)高可用。
我們還指出高可用性的黑暗一面，即使系統(tǒng)管理員錯(cuò)誤地依賴高可用性來執(zhí)行維護(hù)任務(wù) - 并解釋為什么這么做會(huì)破壞高可用性的目標(biāo)，使你的企業(yè)運(yùn)營(yíng)面臨風(fēng)險(xiǎn)。
1. 高可用性介紹
讓我們先來談?wù)効捎眯浴Ｈ绻粋€(gè)服務(wù)（如數(shù)據(jù)庫(kù)）在大多數(shù)時(shí)間內(nèi)對(duì)用戶是不可用的，那么運(yùn)行它就沒什么意義了。因此當(dāng)我們談?wù)摽捎眯詴r(shí)，我們是指服務(wù)的可訪問程度。
對(duì)于任何正常運(yùn)行的服務(wù)，人們有理由期待它總是在被需要時(shí)是可用的 - 但是也會(huì)有一些停機(jī)時(shí)間，一年中有一兩天，或者每月有幾個(gè)小時(shí)。
一個(gè)普遍的可用的服務(wù)對(duì)于許多用例場(chǎng)景來說可能是很好的，但是如果服務(wù)本質(zhì)上是至關(guān)重要的，或者大量用戶依賴與一個(gè)服務(wù)，僅僅依靠「可用性」是不夠的。
這就是高可用性的意義所在。在最基本的條件下，高可用性確保比通常預(yù)期的水平更高的可用性，更具體的說，在允許維護(hù)、修補(bǔ)和一般錯(cuò)誤以及故障的情況下，也能達(dá)到約定的水平。
2. 什么級(jí)別的可用性是高可用性？
對(duì)于什么是高可用性還沒有達(dá)成一致的定義，只是為了滿足特定的（更高的）可用性需求，它通常超過被護(hù)接受的「可用性」。事實(shí)上，你的組織可能會(huì)根據(jù)運(yùn)營(yíng)的需求來定義所需的可用性 - 權(quán)衡高可用性的成本與停機(jī)相關(guān)的損失的成本。
你需要的可用性水平可以通過百分比來表示。例如 99.99% 或者「4 個(gè) 9」的可用性意味著一年中最多有 52.06 分鐘的停機(jī)時(shí)間，而「6 個(gè) 9」或者 99.9999% 的可用性則限制一年有 31.56 分鐘的停機(jī)時(shí)間。
從本質(zhì)上來說，選擇權(quán)在你手上 - 但是，同樣，這也是一種權(quán)衡。維持高可用性的成本將是昂貴的 - 需要額外的物理資源和軟件許可，并耗費(fèi)你的人力資源。但是，你可能會(huì)發(fā)現(xiàn)這是一個(gè)值得付出的代價(jià)，為了避免中斷帶來的連鎖成本，或者因客戶不滿意而損失收入的風(fēng)險(xiǎn)。
3. 高可用性在實(shí)踐中是如何工作的？
你的高可用性基礎(chǔ)架構(gòu)的確切性質(zhì)取決于你的工作負(fù)載。然而，從廣義上來講，當(dāng)有容錯(cuò)性時(shí)，就可以實(shí)現(xiàn)高可用性，這樣即使一個(gè)服務(wù)或者設(shè)備出現(xiàn)故障，工作負(fù)載也不會(huì)中斷。通常情況下，這意為著沒有單點(diǎn)故障 - 所有服務(wù)和設(shè)備都在網(wǎng)絡(luò)和應(yīng)用級(jí)別是完全冗余的。
根據(jù)服務(wù)的不同，這通常可能涉及到一些節(jié)點(diǎn) - 例如，你的 MySQL 集群將多包含幾個(gè)節(jié)點(diǎn)，數(shù)據(jù)存儲(chǔ)在這上面。然后將多個(gè)節(jié)點(diǎn)和負(fù)載平衡工具結(jié)合，這樣如果一個(gè)節(jié)點(diǎn)失敗，請(qǐng)求將被引導(dǎo)發(fā)送到另一個(gè)節(jié)點(diǎn)。用戶仍然可以訪問可用的服務(wù)，即使性能稍微下降。
4. 在 MySQL 中配置高可用性
當(dāng)然，你通往高可用 MySQL 數(shù)據(jù)庫(kù)的途徑將取決于你對(duì) MySQL 的實(shí)現(xiàn)。概括的說，你需要?jiǎng)?chuàng)建具有多個(gè)節(jié)點(diǎn)的某種類型的 MySQL 集群 - 換句話說，你的數(shù)據(jù)必須是存儲(chǔ)在多個(gè) MySQL 服務(wù)器上。
接下來，你需要一個(gè)可以在這些節(jié)點(diǎn)上復(fù)制數(shù)據(jù)的服務(wù)，確保每一個(gè)節(jié)點(diǎn)都有你的數(shù)據(jù)庫(kù)中包含的數(shù)據(jù)的精確備份。最后，你需要一個(gè)負(fù)載平衡器，確保任何數(shù)據(jù)庫(kù)請(qǐng)求被均勻地引導(dǎo)到數(shù)據(jù)庫(kù)節(jié)點(diǎn) - 是的， 一個(gè)平衡負(fù)載 - 但是請(qǐng)確保即使有一個(gè)節(jié)點(diǎn)離線，請(qǐng)求也能得到滿足。
例如， MySQL 提供了一個(gè)面向高可用的商業(yè)產(chǎn)品 - Te MySQL InnoDB Cluster. 。它基于 MySQL 群組復(fù)制，這是確保 MySQL 數(shù)據(jù)庫(kù)環(huán)境中高可用性的一種流行的方式。
另一個(gè)替代的選擇是 Galera ，它多年來一直提供 MySQL 高可用性。如果你使用的是 MySQL 的 MariaDB 分支，你可以通過你用 Galera 集群運(yùn)行多個(gè)節(jié)點(diǎn)來配置 MariaDB 環(huán)境的高可用性 - 同時(shí)依靠 HAProxy 進(jìn)行負(fù)載平衡。另外，你也可以研究一下 MariaDB 自己的
MaxScale 產(chǎn)品。
5. 依賴高可用性好的理由…
企業(yè)規(guī)模的工作負(fù)載越來越多地使用高可用性原則，因?yàn)閺拈L(zhǎng)遠(yuǎn)來看，它提供了最好的結(jié)果。下面是你應(yīng)該考慮在你的操作中設(shè)置高可用性的幾個(gè)好的理由：
極其重要的應(yīng)用. 一些應(yīng)用根本無法承受任何停機(jī)時(shí)間，想一想軍事應(yīng)用或者能源網(wǎng)絡(luò)。在這些情況下，高可用性是必須的，你沒有什么選擇，只能確保極高的可用性 - 盡管你可以做風(fēng)險(xiǎn)評(píng)估，并決定你到底需要多大的高可用性保證。
連鎖效應(yīng). 如果系統(tǒng)是一個(gè)工作負(fù)載的核心，即使短暫的停機(jī)也會(huì)導(dǎo)致廣泛的問題，因?yàn)檫B接和同步的系統(tǒng)將會(huì)連帶失敗。值得考慮在幾個(gè)核心的領(lǐng)域投入高可用性 - 如數(shù)據(jù)庫(kù) - 因?yàn)榭紤]到可能很難恢復(fù)的更大連帶問題的成本，這可能是值得的。
收入損失. 高可用性，即使是數(shù)量不多的 9 ，也可以防止收入損失。對(duì)于一個(gè)主要的在線零售商來說，僅僅幾個(gè)小時(shí)的銷售損失，加上相關(guān)名譽(yù)損失，就會(huì)對(duì)底線產(chǎn)生非常重要的影響。
客戶的期望和服務(wù)水平協(xié)議. 你的業(yè)務(wù)操作可能會(huì)受到服務(wù)水平協(xié)議的約束，保證你的客戶端有一定的正常運(yùn)行時(shí)間。如果是這種情況，你需要確保你的客戶端工作負(fù)載的服務(wù)具有正常運(yùn)行時(shí)間的水平 - 你將通過高可用性來實(shí)現(xiàn)。如果做不到這一點(diǎn)會(huì)導(dǎo)致合同的終止，或者根據(jù)你的合同進(jìn)行賠償懲罰。
這是高可用性的幾個(gè)好的有效理由 - 而且，這今天這個(gè)技術(shù)至上的世界里，有許多工作負(fù)載在沒有高可用性平臺(tái)的情況下根本無法運(yùn)行。
6. … 和依賴高可用性錯(cuò)誤的理由
不幸的是，高可用的日益盛行導(dǎo)致了它的濫用。因?yàn)楦呖捎眯允沟孟到y(tǒng)變得異常健壯，技術(shù)團(tuán)隊(duì)在執(zhí)行系統(tǒng)管理任務(wù)的時(shí)候（如打補(bǔ)丁）可能會(huì)傾向走捷徑，因?yàn)槟切﹫F(tuán)隊(duì)認(rèn)為高可用性基礎(chǔ)設(shè)施將會(huì)簡(jiǎn)單承擔(dān)一臺(tái)機(jī)器脫機(jī)的負(fù)擔(dān)。
實(shí)際上，它很快就會(huì)變得更加復(fù)雜。以 MySQL 集群為例。是的，如果你重啟一臺(tái)機(jī)器給它打補(bǔ)丁，由于高可用性，你的 MySQL 集群將繼續(xù)運(yùn)行。但是，請(qǐng)記住，當(dāng)你為了打補(bǔ)丁而關(guān)閉一個(gè)節(jié)點(diǎn)，然后重新啟動(dòng)它時(shí)，會(huì)導(dǎo)致需要輸入的數(shù)據(jù)積壓。這個(gè)過程可能需要花費(fèi)長(zhǎng)時(shí)間才能完成。
不用說，每一臺(tái)數(shù)據(jù)庫(kù)主機(jī)都需要看到相同的數(shù)據(jù)。危險(xiǎn)來自于重新同步的過程：如果在你已經(jīng)關(guān)閉的一個(gè)節(jié)點(diǎn)并對(duì)其打補(bǔ)丁的情況下，另一個(gè)節(jié)點(diǎn)出現(xiàn)故障，這可能導(dǎo)致失去最終有效的法定人數(shù)。換句話說，保存關(guān)于數(shù)據(jù)「真相」的服務(wù)器數(shù)量可能低于可接受的水平。從這種狀態(tài)下恢復(fù)可能是困難和復(fù)雜的，甚至可能導(dǎo)致數(shù)據(jù)丟失。
7. 不要依賴高可用性進(jìn)行維護(hù)
高可用性是為了在出現(xiàn)故障時(shí)保證系統(tǒng)的正常運(yùn)行。這種針對(duì)故障的固有保護(hù)并不是一個(gè)免費(fèi)通行證，可以依賴高可用性的健壯，以不負(fù)責(zé)的方式執(zhí)行的系統(tǒng)維護(hù)，并沒有人會(huì)注意到它。
相反，技術(shù)團(tuán)隊(duì)?wèi)?yīng)該依靠其他解決方案 - 例如，為正在打補(bǔ)丁的系統(tǒng)設(shè)置完全的冗余，而不是簡(jiǎn)單地希望高可用性基礎(chǔ)設(shè)施能夠來抵擋壓力。或者，在可能的情況下，依靠實(shí)時(shí)打補(bǔ)丁的方式來替代，通過這樣的做來消除需要重啟服務(wù)來安裝補(bǔ)丁的效果。
盡管如此，依賴高可用性進(jìn)行維護(hù)工作的顯示出令人擔(dān)憂的跡象。仔細(xì)觀察一下，你甚至?xí)l(fā)現(xiàn)供應(yīng)商的官方指導(dǎo)，指示用戶依靠高可用性來執(zhí)行打補(bǔ)丁的任務(wù)，用戶只需希望在一個(gè)節(jié)點(diǎn)離線打補(bǔ)丁時(shí)，其他節(jié)點(diǎn)不要出現(xiàn)任何問題。
8. 結(jié)束
高可用性對(duì)于許多應(yīng)用來說都至關(guān)重要 - 對(duì)于許多其他應(yīng)用來說也是十分有益。配置正確， MySQL 數(shù)據(jù)庫(kù)可以提供幾乎完美的可用性，但這并不意味著技術(shù)團(tuán)隊(duì)可以把可用性視為理所當(dāng)然。
濫用高可用性架構(gòu)來維護(hù)走捷徑是不可取的 - 風(fēng)險(xiǎn)比乍看之下更大。
相反，系統(tǒng)管理員應(yīng)該尋找可以久經(jīng)考驗(yàn)的替代方案 - 包括冗余和實(shí)時(shí)補(bǔ)丁 - 來執(zhí)行維護(hù)操作，而不傷害高可用性解決方案的能力。
