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

一、高可用數據庫概述

1. 什么是高可用數據庫?

高可用數據庫是由一系列數據庫構成的總體系統，在任何時刻，至少有一個節點可以接受用戶的請求并提供數據庫服務。大多數數據庫架構中，有一個主節點處理主要請求，還有若干備用節點用于容災切換，當主節點不能提供服務時，備用節點成為主節點繼續提供服務，用以保證整個系統的可用和穩定。

2. 高可用數據庫有很多優點：

• 第一，方便讀寫分離。數據庫請求當中，一般讀操作的請求次數遠大于寫操作，高可用數據庫可以通過將寫操作放在主數據庫節點上進行，將讀操作分擔到若干從庫上，來提升讀操作吞吐量，進而提升讀寫效率;
• 第二，變更不停服。當整個高可用數據庫架構或者主節點升級時，可以讓高可用數據庫先進行主庫切換，讓備用節點替換原主節點提供數據庫服務，當主節點升級完畢后，再將主從庫服務切換回來，這樣能有效避免系統升級或變更時對用戶服務質量產生影響;
• 第三，備份不影響服務性能。高可用數據庫架構包含多個從庫，在不影響主節點服務性能的情況下，能非常方便地實現數據的容災備份。

3. 高可用數據庫設計

一般，高可用數據庫架構設計時，也需要考慮三個問題：

• 第一，如何同步各數據庫之間的節點數據?同步需要保證切換后的數據庫是最新數據，以及在切換過程中數據不會丟失，同時還要考慮同步過程對主庫和備庫的影響。
• 第二，高可用數據庫的容災切換如何進行?架構不同容災切換的復雜度也不一樣，且切換以后需要保證主、從庫數據的一致性，這可能需要開發者在設計之初就盡量優化和簡化容災切換邏輯。
• 第三，如何提高高可用的運維效率?

二、業界高可用架構方案

業界典型的高可用架構可以劃分為四種：

1. 共享存儲。

共享存儲是指若干DB服務使用同一份存儲，一個主DB，其他的為備用DB，若主服務崩潰，則系統啟動備用DB，成為新的主DB，繼續提供服務。一般共享存儲采用比較多的是SAN/NAS方案，這種方案的優點是沒有數據同步的問題，缺點是對網絡性能要求比較高。

2. 操作系統實時數據塊復制。

這種方案的典型場景是DRBD。如下圖所示，左邊數據庫寫入數據以后立即同步到右邊的存儲設備當中。如果左邊數據庫崩潰，系統直接將右邊的數據庫存儲設備激活，完成數據庫的容災切換。這個方案同樣有一些問題，如系統只能有一個數據副本提供服務，無法實現讀寫分離;另外，系統崩潰后需要的容災恢復時間較長。

3. 數據庫主從復制。

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

4. 數據庫高可用集群。

前面三種是通過復制日志的模式實現高可用，第四種方案是基于一致性算法來做數據同步。數據庫提供一種多節點的一致性同步機制，然后利用該機制構建多節點同步集群，這是業界近年來比較流行的高可用集群的方案。

三、數據庫容災規劃

一般數據容災會實現兩地兩個數據中心，1 主 2 從數據容災架構，并建立數據庫日常數據災備體系。但為了提高 IT 服務管理水平，企業用戶需要構建新一代多活系統規劃設計總體目標：實現數據 0 丟失，同時滿足在任何災難情況下實現 30 分鐘恢復對外數據服務。主要結合當前主流容災、災備技術與企業未來 5 年內，多地數據中心建設進行整體容災與災備建設規劃、容災演練、自動化監控與管理規劃。

1. 服務連續性規劃

衡量連續性水平主要指標是恢復時間目標(RTO)和恢復點目標(RPO)。

• 恢復時間目標(RTO)：企業可容許服務中斷的時長;
• 恢復點目標(RPO)：指當服務恢復后，恢復得來的數據所對應時間點。

結合當前 XXX 實際現狀目前規劃 2 個級別連續性等級規劃：

2. 技術選型規劃

3. 自動化管理平臺規劃

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

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

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

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

(1) 容災切換自動化。

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

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

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

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

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

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

4. 數據庫容災&災備演練規劃

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

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

總結

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