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

3. 數據庫主從復制。

這種方案是較經典的數據同步模式，系統采用一個主庫和多個從庫，主庫同步數據庫日志到各個從庫，從庫各自回放日志。它的好處是一個主庫可以連接多個從庫，能很方便地實現讀寫分離，同時，因為每個備庫都在啟動當中，所以備庫當中的數據基本上都是熱數據，容災切換也非?？臁?/p>

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

通過數據庫自動化管理平臺中容災&災備監(jiān)控管理中心可以實現對多個數據中心全局數據容災、數據災備的情況進行整體拓撲監(jiān)控與管理。并且

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

自動化運維是高可用數據庫中的難點，因為企業(yè)業(yè)務不一定只有一個數據庫，可能需要同時管理十幾個甚至上百個數據庫，如果每一個數據庫都配置一個高可用數據庫架構，系統則需要保證其中任何一個發(fā)生問題以后都可以進行容災，這無疑給運維帶來了極大挑戰(zhàn)。

下面提供幾個自動化運維方向的思路：

(1) 容災切換自動化。

要實現容災切換的自動化，首先需要考慮兩個問題：

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

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

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

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

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

4. 數據庫容災&災備演練規(guī)劃

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

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

總結

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

當前文章：閑聊數據庫高可用容災規(guī)劃設計
轉載來源：http://chinadenli.net/news34/99184.html

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

廣告

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