本文小編為大家詳細介紹“為什么不要依賴MySQL高可用性進行維護”，內(nèi)容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“為什么不要依賴MySQL高可用性進行維護”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識吧。

十年的泉港網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整泉港建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“泉港網(wǎng)站設(shè)計”,“泉港網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

1. 高可用性介紹

讓我們先來談?wù)効捎眯浴Ｈ绻粋€服務(wù)（如數(shù)據(jù)庫）在大多數(shù)時間內(nèi)對用戶是不可用的，那么運行它就沒什么意義了。因此當我們談?wù)摽捎眯詴r，我們是指服務(wù)的可訪問程度。

對于任何正常運行的服務(wù)，人們有理由期待它總是在被需要時是可用的 - 但是也會有一些停機時間，一年中有一兩天，或者每月有幾個小時。

一個普遍的可用的服務(wù)對于許多用例場景來說可能是很好的，但是如果服務(wù)本質(zhì)上是至關(guān)重要的，或者大量用戶依賴與一個服務(wù)，僅僅依靠「可用性」是不夠的。

這就是高可用性的意義所在。在最基本的條件下，高可用性確保比通常預(yù)期的水平更高的可用性，更具體的說，在允許維護、修補和一般錯誤以及故障的情況下，也能達到約定的水平。

2. 什么級別的可用性是高可用性？

對于什么是高可用性還沒有達成一致的定義，只是為了滿足特定的（更高的）可用性需求，它通常超過被護接受的「可用性」。事實上，你的組織可能會根據(jù)運營的需求來定義所需的可用性 - 權(quán)衡高可用性的成本與停機相關(guān)的損失的成本。

你需要的可用性水平可以通過百分比來表示。例如 99.99% 或者「4 個 9」的可用性意味著一年中最多有 52.06 分鐘的停機時間，而「6 個 9」或者 99.9999% 的可用性則限制一年有 31.56 分鐘的停機時間。

從本質(zhì)上來說，選擇權(quán)在你手上 - 但是，同樣，這也是一種權(quán)衡。維持高可用性的成本將是昂貴的 - 需要額外的物理資源和軟件許可，并耗費你的人力資源。但是，你可能會發(fā)現(xiàn)這是一個值得付出的代價，為了避免中斷帶來的連鎖成本，或者因客戶不滿意而損失收入的風(fēng)險。

3. 高可用性在實踐中是如何工作的？

你的高可用性基礎(chǔ)架構(gòu)的確切性質(zhì)取決于你的工作負載。然而，從廣義上來講，當有容錯性時，就可以實現(xiàn)高可用性，這樣即使一個服務(wù)或者設(shè)備出現(xiàn)故障，工作負載也不會中斷。通常情況下，這意為著沒有單點故障 - 所有服務(wù)和設(shè)備都在網(wǎng)絡(luò)和應(yīng)用級別是完全冗余的。

根據(jù)服務(wù)的不同，這通?？赡苌婕暗揭恍┕?jié)點 - 例如，你的 MySQL 集群將多包含幾個節(jié)點，數(shù)據(jù)存儲在這上面。然后將多個節(jié)點和負載平衡工具結(jié)合，這樣如果一個節(jié)點失敗，請求將被引導(dǎo)發(fā)送到另一個節(jié)點。用戶仍然可以訪問可用的服務(wù)，即使性能稍微下降。

4. 在 MySQL 中配置高可用性

當然，你通往高可用 MySQL 數(shù)據(jù)庫的途徑將取決于你對 MySQL 的實現(xiàn)。概括的說，你需要創(chuàng)建具有多個節(jié)點的某種類型的 MySQL 集群 - 換句話說，你的數(shù)據(jù)必須是存儲在多個 MySQL 服務(wù)器上。

接下來，你需要一個可以在這些節(jié)點上復(fù)制數(shù)據(jù)的服務(wù)，確保每一個節(jié)點都有你的數(shù)據(jù)庫中包含的數(shù)據(jù)的精確備份。最后，你需要一個負載平衡器，確保任何數(shù)據(jù)庫請求被均勻地引導(dǎo)到數(shù)據(jù)庫節(jié)點 - 是的， 一個平衡負載 - 但是請確保即使有一個節(jié)點離線，請求也能得到滿足。

例如， MySQL 提供了一個面向高可用的商業(yè)產(chǎn)品 - Te MySQL InnoDB Cluster. 。它基于 MySQL 群組復(fù)制，這是確保 MySQL 數(shù)據(jù)庫環(huán)境中高可用性的一種流行的方式。

另一個替代的選擇是 Galera ，它多年來一直提供 MySQL 高可用性。如果你使用的是 MySQL 的 MariaDB 分支，你可以通過你用 Galera 集群運行多個節(jié)點來配置 MariaDB 環(huán)境的高可用性  - 同時依靠 HAProxy 進行負載平衡。另外，你也可以研究一下 MariaDB 自己的
MaxScale 產(chǎn)品。

5. 依賴高可用性好的理由…

企業(yè)規(guī)模的工作負載越來越多地使用高可用性原則，因為從長遠來看，它提供了最好的結(jié)果。下面是你應(yīng)該考慮在你的操作中設(shè)置高可用性的幾個好的理由：

• 極其重要的應(yīng)用. 一些應(yīng)用根本無法承受任何停機時間，想一想軍事應(yīng)用或者能源網(wǎng)絡(luò)。在這些情況下，高可用性是必須的，你沒有什么選擇，只能確保極高的可用性 - 盡管你可以做風(fēng)險評估，并決定你到底需要多大的高可用性保證。

• 連鎖效應(yīng). 如果系統(tǒng)是一個工作負載的核心，即使短暫的停機也會導(dǎo)致廣泛的問題，因為連接和同步的系統(tǒng)將會連帶失敗。值得考慮在幾個核心的領(lǐng)域投入高可用性 - 如數(shù)據(jù)庫 - 因為考慮到可能很難恢復(fù)的更大連帶問題的成本，這可能是值得的。

• 收入損失. 高可用性，即使是數(shù)量不多的 9 ，也可以防止收入損失。對于一個主要的在線零售商來說，僅僅幾個小時的銷售損失，加上相關(guān)名譽損失，就會對底線產(chǎn)生非常重要的影響。

• 客戶的期望和服務(wù)水平協(xié)議. 你的業(yè)務(wù)操作可能會受到服務(wù)水平協(xié)議的約束，保證你的客戶端有一定的正常運行時間。如果是這種情況，你需要確保你的客戶端工作負載的服務(wù)具有正常運行時間的水平 - 你將通過高可用性來實現(xiàn)。如果做不到這一點會導(dǎo)致合同的終止，或者根據(jù)你的合同進行賠償懲罰。

這是高可用性的幾個好的有效理由 - 而且，這今天這個技術(shù)至上的世界里，有許多工作負載在沒有高可用性平臺的情況下根本無法運行。

6. … 和依賴高可用性錯誤的理由

不幸的是，高可用的日益盛行導(dǎo)致了它的濫用。因為高可用性使得系統(tǒng)變得異常健壯，技術(shù)團隊在執(zhí)行系統(tǒng)管理任務(wù)的時候（如打補?。┛赡軙A向走捷徑，因為那些團隊認為高可用性基礎(chǔ)設(shè)施將會簡單承擔(dān)一臺機器脫機的負擔(dān)。

實際上，它很快就會變得更加復(fù)雜。以 MySQL 集群為例。是的，如果你重啟一臺機器給它打補丁，由于高可用性，你的 MySQL 集群將繼續(xù)運行。但是，請記住，當你為了打補丁而關(guān)閉一個節(jié)點，然后重新啟動它時，會導(dǎo)致需要輸入的數(shù)據(jù)積壓。這個過程可能需要花費長時間才能完成。

不用說，每一臺數(shù)據(jù)庫主機都需要看到相同的數(shù)據(jù)。危險來自于重新同步的過程：如果在你已經(jīng)關(guān)閉的一個節(jié)點并對其打補丁的情況下，另一個節(jié)點出現(xiàn)故障，這可能導(dǎo)致失去最終有效的法定人數(shù)。換句話說，保存關(guān)于數(shù)據(jù)「真相」的服務(wù)器數(shù)量可能低于可接受的水平。從這種狀態(tài)下恢復(fù)可能是困難和復(fù)雜的，甚至可能導(dǎo)致數(shù)據(jù)丟失。

7. 不要依賴高可用性進行維護#

高可用性是為了在出現(xiàn)故障時保證系統(tǒng)的正常運行。這種針對故障的固有保護并不是一個免費通行證，可以依賴高可用性的健壯，以不負責(zé)的方式執(zhí)行的系統(tǒng)維護，并沒有人會注意到它。

相反，技術(shù)團隊應(yīng)該依靠其他解決方案 - 例如，為正在打補丁的系統(tǒng)設(shè)置完全的冗余，而不是簡單地希望高可用性基礎(chǔ)設(shè)施能夠來抵擋壓力。或者，在可能的情況下，依靠實時打補丁的方式來替代，通過這樣的做來消除需要重啟服務(wù)來安裝補丁的效果。

盡管如此，依賴高可用性進行維護工作的顯示出令人擔(dān)憂的跡象。仔細觀察一下，你甚至?xí)l(fā)現(xiàn)供應(yīng)商的官方指導(dǎo)，指示用戶依靠高可用性來執(zhí)行打補丁的任務(wù)，用戶只需希望在一個節(jié)點離線打補丁時，其他節(jié)點不要出現(xiàn)任何問題。

讀到這里，這篇“為什么不要依賴MySQL高可用性進行維護”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領(lǐng)會，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。