一個(gè)系統(tǒng)可能包含很多模塊，如數(shù)據(jù)庫、前端、緩存、搜索、消息隊(duì)列等，每個(gè)模塊都需要做到高可用，才能保證整個(gè)系統(tǒng)的高可用。對于數(shù)據(jù)庫服務(wù)而言，高可用的實(shí)現(xiàn)可能更加復(fù)雜，對用戶的服務(wù)可用，不僅僅是能訪問，還需要有正確性保證，因此討論數(shù)據(jù)庫的高可用方案時(shí)，在容災(zāi)之外，還要同時(shí)考慮方案中數(shù)據(jù)一致性問題。

3. 數(shù)據(jù)庫主從復(fù)制。

這種方案是較經(jīng)典的數(shù)據(jù)同步模式，系統(tǒng)采用一個(gè)主庫和多個(gè)從庫，主庫同步數(shù)據(jù)庫日志到各個(gè)從庫，從庫各自回放日志。它的好處是一個(gè)主庫可以連接多個(gè)從庫，能很方便地實(shí)現(xiàn)讀寫分離，同時(shí)，因?yàn)槊總€(gè)備庫都在啟動當(dāng)中，所以備庫當(dāng)中的數(shù)據(jù)基本上都是熱數(shù)據(jù)，容災(zāi)切換也非?？?。

3. 自動化管理平臺規(guī)劃

通過數(shù)據(jù)庫自動化管理平臺中容災(zāi)&災(zāi)備監(jiān)控管理中心可以實(shí)現(xiàn)對多個(gè)數(shù)據(jù)中心全局?jǐn)?shù)據(jù)容災(zāi)、數(shù)據(jù)災(zāi)備的情況進(jìn)行整體拓?fù)浔O(jiān)控與管理。并且

為了保證數(shù)據(jù)容災(zāi)、數(shù)據(jù)災(zāi)備有效性對數(shù)據(jù)同步延遲、數(shù)據(jù)傳輸流量根據(jù)數(shù)據(jù)中心的鏈路帶寬分配情況定制對應(yīng)的告警監(jiān)控。

自動化運(yùn)維是高可用數(shù)據(jù)庫中的難點(diǎn)，因?yàn)槠髽I(yè)業(yè)務(wù)不一定只有一個(gè)數(shù)據(jù)庫，可能需要同時(shí)管理十幾個(gè)甚至上百個(gè)數(shù)據(jù)庫，如果每一個(gè)數(shù)據(jù)庫都配置一個(gè)高可用數(shù)據(jù)庫架構(gòu)，系統(tǒng)則需要保證其中任何一個(gè)發(fā)生問題以后都可以進(jìn)行容災(zāi)，這無疑給運(yùn)維帶來了極大挑戰(zhàn)。

下面提供幾個(gè)自動化運(yùn)維方向的思路：

(1) 容災(zāi)切換自動化。

要實(shí)現(xiàn)容災(zāi)切換的自動化，首先需要考慮兩個(gè)問題：

• 第一，怎樣準(zhǔn)確判斷需要容災(zāi)。這是實(shí)現(xiàn)自動容災(zāi)的基礎(chǔ)和前提，它需要結(jié)合實(shí)際情況討論和判斷。如發(fā)生網(wǎng)絡(luò)波動時(shí)，可能有一段時(shí)間發(fā)現(xiàn)無法連上主庫，實(shí)際上幾秒鐘以后整個(gè)業(yè)務(wù)系統(tǒng)又恢復(fù)了，如果這時(shí)候數(shù)據(jù)庫做容災(zāi)的話代價(jià)比較大，且容災(zāi)后還可能會有額外的風(fēng)險(xiǎn)。所以需要在前期準(zhǔn)確判斷是否需要容災(zāi)，并保證在最需要容災(zāi)的時(shí)候及時(shí)容災(zāi);
• 第二，容災(zāi)切換時(shí)，備庫數(shù)據(jù)盡量和主庫數(shù)據(jù)保持一致，否則，就會帶來數(shù)據(jù)丟失的問題。

針對上述問題，MySQL已經(jīng)有比較常用方案供參考，老牌的如MHA，還有一種比較新的方案叫Orchestrator，如果大家自己搭建數(shù)據(jù)庫，可以考慮采用這兩種方案。

(2) 健康狀況自動檢查。

健康狀況檢查需要通過自動監(jiān)控搭配告警來做，高可用容災(zāi)中，最關(guān)心的還是高可用數(shù)據(jù)庫的主庫和備庫數(shù)據(jù)是否一致，一般情況，導(dǎo)致主從庫數(shù)據(jù)不一致的主要是兩點(diǎn)：

• 第一，復(fù)制有沒有正常進(jìn)行，如發(fā)送日志時(shí)主庫與備庫之間的連接突然斷掉，這時(shí)候需要系統(tǒng)時(shí)常掃描主備庫是否異常;
• 第二，主從延時(shí)，如果主從之間的數(shù)據(jù)延遲較大，那么切換數(shù)據(jù)庫時(shí)也會比較麻煩，這方面也可以考慮使用業(yè)內(nèi)比較常用的監(jiān)控模塊如Prometheus等工具定期采集，發(fā)現(xiàn)異常狀況后及時(shí)調(diào)整。
• 第三，異常情況自適應(yīng)調(diào)整。以主從延遲為例，一般來說可能是CPU的問題或者IO的問題等，如果是IO的問題，一種辦法是將IO調(diào)高，這是一種比較好的解決方案，如果IO調(diào)高以后發(fā)現(xiàn)還是無法降低延時(shí)，可以在從庫把日志的持久化等級暫時(shí)性調(diào)低。當(dāng)然，如果主從之間延遲過大，完全無法調(diào)整為正常水平，這時(shí)候就要考慮通過一些手段重做從庫。

4. 數(shù)據(jù)庫容災(zāi)&災(zāi)備演練規(guī)劃

規(guī)劃通過使用數(shù)據(jù)庫自動化管理平臺中的“一鍵容災(zāi)切換”-演練切換、“一鍵災(zāi)備恢復(fù)”-數(shù)據(jù)庫恢復(fù)模塊進(jìn)行恢復(fù)演練操作。

定期容災(zāi)演練很有必要。容災(zāi)演練就是在平臺上跑自己的容災(zāi)邏輯，我們需要在不同場景下做切換，看數(shù)據(jù)有沒有丟失、是否保持了數(shù)據(jù)的一致性等等，因?yàn)榫€上環(huán)境非常復(fù)雜，可能會有各種莫名其妙的問題導(dǎo)致切換邏輯在發(fā)生切換以后結(jié)果不一致，所以要通過定期演練把各種可能性降到最低。

總結(jié)

高可用架構(gòu)是數(shù)據(jù)庫運(yùn)行穩(wěn)定必不可少的一部分，設(shè)計(jì)架構(gòu)時(shí)要考慮諸多問題，如數(shù)據(jù)是否同步、高可用自動切換、自動化運(yùn)維等等。

當(dāng)前文章：閑聊數(shù)據(jù)庫高可用容災(zāi)規(guī)劃設(shè)計(jì)
轉(zhuǎn)載來源：http://aaarwkj.com/news34/99184.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、網(wǎng)頁設(shè)計(jì)公司、軟件開發(fā)、全網(wǎng)營銷推廣、動態(tài)網(wǎng)站、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)