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

本文將通過介紹一些業(yè)界主流的數(shù)據(jù)庫高可用架構(gòu)、每種方案的特性和優(yōu)缺點，以及數(shù)據(jù)庫高可用架構(gòu)的自動化運維實現(xiàn)，講講數(shù)據(jù)庫高可用容災(zāi)方案設(shè)計與實現(xiàn)，希望拋磚引玉，和大家一起討論。

一、高可用數(shù)據(jù)庫概述

什么是高可用數(shù)據(jù)庫?

高可用數(shù)據(jù)庫是由一系列數(shù)據(jù)庫構(gòu)成的總體系統(tǒng)，在任何時刻，至少有一個節(jié)點可以接受用戶的請求并提供數(shù)據(jù)庫服務(wù)。大多數(shù)數(shù)據(jù)庫架構(gòu)中，有一個主節(jié)點處理主要請求，還有若干備用節(jié)點用于容災(zāi)切換，當主節(jié)點不能提供服務(wù)時，備用節(jié)點成為主節(jié)點繼續(xù)提供服務(wù)，用以保證整個系統(tǒng)的可用和穩(wěn)定。

高可用數(shù)據(jù)庫有很多優(yōu)點：

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

一般，高可用數(shù)據(jù)庫地架構(gòu)設(shè)計時，也需要考慮三個問題：

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

二、業(yè)界典型高可用數(shù)據(jù)庫架構(gòu)

按照數(shù)據(jù)同步方式，我們可以將業(yè)界主流的高可用架構(gòu)劃分成四種：***種，共享存儲方案;第二種，操作系統(tǒng)實時數(shù)據(jù)塊復(fù)制;第三種，數(shù)據(jù)庫級別的主從復(fù)制;第四種，高可用數(shù)據(jù)庫集群。每一種數(shù)據(jù)同步方式可以衍生出不同的架構(gòu)。

方案一：共享存儲

共享存儲指若干DB服務(wù)使用同一份存儲，一個為主DB，其他的為備用DB，若主服務(wù)崩潰，則系統(tǒng)啟動備用DB，成為新的主DB，繼續(xù)提供服務(wù)。一般共享存儲采用比較多的是SAN/NAS方案。

這種方案的優(yōu)點是沒有數(shù)據(jù)同步的問題，但也有一些限制，如對于共享存儲的實時性和網(wǎng)絡(luò)性能有較高要求。因為共享存儲一般是通過網(wǎng)絡(luò)來訪問存儲當中的數(shù)據(jù)，在網(wǎng)絡(luò)性能較差的情況下，數(shù)據(jù)庫的性能也無法達到令人滿意的效果。不過，隨著硬件性能的不斷提升，將計算存儲分離、和DB深度結(jié)合的共享存儲亦是高可用數(shù)據(jù)庫未來發(fā)展的趨勢之一。

方案二：操作系統(tǒng)實時數(shù)據(jù)塊復(fù)制

這個方案的典型場景是DRBD，可以把它理解為遠程的RAID1，如下圖所示，左側(cè)數(shù)據(jù)庫寫入數(shù)據(jù)以后立即同步到右側(cè)的存儲設(shè)備當中。如果左邊數(shù)據(jù)庫崩潰，系統(tǒng)可以直接激活右邊的數(shù)據(jù)庫存儲設(shè)備，啟動新的數(shù)據(jù)庫服務(wù)，實現(xiàn)容災(zāi)切換。

這個方案同樣有一些問題，如系統(tǒng)只能有一個數(shù)據(jù)副本提供服務(wù)，無法實現(xiàn)讀寫分離;另外，如果系統(tǒng)崩潰，主庫進程中斷，容災(zāi)切換后需要在掛掉的數(shù)據(jù)庫上做數(shù)據(jù)庫崩潰恢復(fù)，系統(tǒng)需要的容災(zāi)恢復(fù)時間較長。

方案三：數(shù)據(jù)庫主從復(fù)制

這種方案我認為是最經(jīng)典的數(shù)據(jù)同步模式，系統(tǒng)采用一個主庫和多個從庫方式，其實現(xiàn)原理主要是基于日志的主從復(fù)制，主庫操作以日志的形式發(fā)送給各個從庫，從庫接收到日志后進行數(shù)據(jù)備份。這種方式的好處是一個主庫可以連接多個從庫，能很方便地實現(xiàn)讀寫分離，同時，因為每個備庫都在運行中，所以備庫里面的數(shù)據(jù)基本上都是熱數(shù)據(jù)，容災(zāi)切換也非?？?。

不過，這個方案也并非***無缺，如容災(zāi)切換時，從庫一定要同步完***數(shù)據(jù)以后才能升級為主庫，否則極有可能發(fā)生數(shù)據(jù)丟失的情況。針對傳統(tǒng)主從架構(gòu)的一些問題，業(yè)界也逐漸研發(fā)出對應(yīng)的改進技術(shù)。

改進技術(shù)一：雙主架構(gòu)

問題：經(jīng)典主從架構(gòu)里面，原主庫崩潰恢復(fù)的過程中，新的數(shù)據(jù)無法及時同步到該數(shù)據(jù)庫當中，原主庫恢復(fù)后，需要重新設(shè)置為從庫，并將容災(zāi)過程中的數(shù)據(jù)重新同步進行。

改進措施：為了保證容災(zāi)后的數(shù)據(jù)一致性，業(yè)界對這種架構(gòu)做了一些改進，其中一種改進措施就叫雙主架構(gòu)，如下圖所示，雙主架構(gòu)一般會選擇兩個DB做一對主庫，這兩個DB之間互相為對方的從庫，無論往哪個DB寫入數(shù)據(jù)，另一個都會自動同步。容災(zāi)時系統(tǒng)只需要把流量從左邊切換到右邊，容災(zāi)后數(shù)據(jù)同步依舊自動進行，這樣，就保證了容災(zāi)后原主庫的數(shù)據(jù)一致性。

改進技術(shù)二：日志自動尋址

問題：容災(zāi)備份時，當某一從庫提升為主庫后，其他備庫需要自動定位新主庫的日志同步點，同步新主庫的日志。早期數(shù)據(jù)庫日志中，MySQL是通過文件名加上文件的偏移量進行尋址，因此，主庫的自動定位并不好實現(xiàn)。

改進措施：為了解決此問題，MySQL提供了一種叫做GTID的全局事務(wù)標志技術(shù)，一個事務(wù)對應(yīng)一個ID，所有的日志都帶有唯一的標識符，主從庫切換后，其余從庫只要根據(jù)新主庫的日志ID，就可以辨別新的日志同步點，然后根據(jù)這個日志同步數(shù)據(jù)，這對于搭建一主庫多從庫的架構(gòu)來說尋址非常便捷。

改進技術(shù)三：異步復(fù)制改進

問題：默認情況下，MySQL的復(fù)制是異步的，主庫將新生成的日志發(fā)送給各從庫后，無需等待從庫的ack回復(fù)(從庫將接收到的日志寫進relay log后，才會回復(fù)ack)，直接就認為這次DDL/DML成功了。但在極端情況下，如主庫剛提交日志，其他從庫還沒有接收到相關(guān)日志時，數(shù)據(jù)庫發(fā)生故障，此時，該日志的內(nèi)容就會全部丟失。

改進措施：半同步復(fù)制機制。半同步復(fù)制是指主庫在將新生成的日志發(fā)送給各從庫前，需發(fā)送日志到一個(默認)從庫，等待從庫返回ack信息后，主庫再提交日志發(fā)送給各從庫,這就防止了上述情況下的數(shù)據(jù)丟失。半同步復(fù)制是一種提升數(shù)據(jù)一致性的有效方式，也是比較關(guān)鍵的技術(shù)。

方案四：數(shù)據(jù)庫高可用集群

前面三種方案主要是通過日志的復(fù)制模式實現(xiàn)高可用，第四種方案則是基于一致性算法來做數(shù)據(jù)的同步，數(shù)據(jù)庫提供多節(jié)點一致性同步機制，利用該機制構(gòu)建多節(jié)點同步集群。這種方式比較經(jīng)典的案例包括MGR(MySQL Group Replication)和Galera等，最近業(yè)內(nèi)也有一些類似的嘗試，如使用一致性協(xié)議算法，自研高可用數(shù)據(jù)庫的架構(gòu)等。

以上示意圖有五個節(jié)點，他們之間是構(gòu)建成了一個一致性的同步集群，客戶端可以讀寫其中的任何一個節(jié)點，任意一節(jié)點寫入，其他節(jié)點都能夠?qū)?shù)據(jù)進行同步，因此，理論上每個節(jié)點都可以進行讀寫操作。這種方式的容災(zāi)實現(xiàn)也比較簡單，假設(shè)第二個節(jié)點出現(xiàn)故障，系統(tǒng)只需要斷開客戶端對第二個節(jié)點的訪問路徑，其他節(jié)點照常訪問就可以了，這也是業(yè)界近年來比較流行的高可用集群方案。

UCloud高可用數(shù)據(jù)庫解決方案UDB

UCloud對比了業(yè)內(nèi)的各解決方案的優(yōu)劣點，綜合了原生MySQL兼容，不同版本、不同應(yīng)用場景的覆蓋等多種因素，最終選擇采用基于數(shù)據(jù)庫主從復(fù)制的方式實現(xiàn)高可用架構(gòu)，并在原架構(gòu)基礎(chǔ)上，使用雙主架構(gòu)、半同步復(fù)制、采用GTID等措施進行了系列優(yōu)化，保證數(shù)據(jù)一致性的同時，實現(xiàn)日志的自動尋址。

如上圖所示，***層為數(shù)據(jù)層，使用了雙主架構(gòu)，主庫與備主庫之間通過半同步的方式實現(xiàn)數(shù)據(jù)同步，整個數(shù)據(jù)層是雙主架構(gòu)+半同步架構(gòu)的模式。中間層有一個代理服務(wù)器Proxy，Proxy將流量導(dǎo)入到雙主數(shù)據(jù)庫的主節(jié)點，架構(gòu)使用了GTID的模式，方便從庫自動尋址。

系統(tǒng)的容災(zāi)切換也非常簡單，數(shù)據(jù)庫崩潰前，Proxy將流量導(dǎo)到主DB上，發(fā)生容災(zāi)以后，只需要把Proxy從左邊Master導(dǎo)到右邊的Slave，即可快速完成切換。

三、高可用數(shù)據(jù)庫的自動化運維

自動化運維的重點方向

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

那么，如何同時管理大量高可用數(shù)據(jù)庫，讓他們都可以進行容災(zāi)呢?這里有一些自動化運維方向的思路：1、容災(zāi)切換自動化;2、高可用數(shù)據(jù)庫運行狀況監(jiān)控;3、健康狀況自動檢查和問題修復(fù)。

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

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

第二，容災(zāi)切換時，備庫數(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ù)不一致的主要是兩點：

***，復(fù)制有沒有正常進行，如發(fā)送日志時主庫與備庫之間的連接突然斷掉，這時候需要系統(tǒng)時常掃描主備庫是否異常;

第二，主從延時，如果主從之間的數(shù)據(jù)延遲較大，那么切換數(shù)據(jù)庫時也會比較麻煩，這方面也可以考慮使用業(yè)內(nèi)比較常用的監(jiān)控模塊如Prometheus等工具定期采集，發(fā)現(xiàn)異常狀況后及時調(diào)整。

第三，異常情況自適應(yīng)調(diào)整。以主從延遲為例，一般來說可能是CPU的問題或者IO的問題等，如果是IO的問題，一種辦法是將IO調(diào)高，這是一種比較好的解決方案，如果IO調(diào)高以后發(fā)現(xiàn)還是無法降低延時，可以在從庫把日志的持久化等級暫時性調(diào)低。當然，如果主從之間延遲過大，完全無法調(diào)整為正常水平，這時候就要考慮通過一些手段重做從庫。

UDB：海量高可用數(shù)據(jù)庫自動化運維

UDB擁有海量的高可用數(shù)據(jù)庫，在自動化運維和管理方面，UDB采用的是高可用容災(zāi)集中式自動化管理的方式，通過自研的自動容災(zāi)邏輯，進行大規(guī)模、高并發(fā)的DB自動化容災(zāi)。同時，UDB的運維體系還可以做到自動化的問題探測以及問題修復(fù)，如自動拉起DB、恢復(fù)服務(wù)，自動恢復(fù)數(shù)據(jù)同步，自適應(yīng)流量控制等。此外，UDB還會配合一些高效運維工具和巡檢工具做更深層次的問題的發(fā)現(xiàn)和解決。

在UDB高可用運維當中，有幾點經(jīng)驗可以跟大家分享：

• ***，日常需要做例行巡檢，保證高可用數(shù)據(jù)庫的健康。主從延時是導(dǎo)致高可用數(shù)據(jù)庫無法容災(zāi)的關(guān)鍵原因之一，這一點一定要在日常運維工作中重視起來;
• 第二，定期容災(zāi)演練很有必要。容災(zāi)演練就是在平臺上跑自己的容災(zāi)邏輯，我們需要在不同場景下做切換，看數(shù)據(jù)有沒有丟失、是否保持了數(shù)據(jù)的一致性等等，因為線上環(huán)境非常復(fù)雜，可能會有各種莫名其妙的問題導(dǎo)致切換邏輯在發(fā)生切換以后結(jié)果不一致，所以要通過定期演練把各種可能性降到***;
• 第三，高可用切換需要記錄日志，并且在切換失敗的時候馬上告警。切換日志可以做事后復(fù)盤分析，看這個DB是什么時候崩潰做的容災(zāi)。進入告警后可以保證***時間介入并解決，縮短整個DB崩潰對用戶的影響時間。

四、總結(jié)

高可用架構(gòu)是數(shù)據(jù)庫運行穩(wěn)定必不可少的一部分，設(shè)計架構(gòu)時要考慮諸多問題，如數(shù)據(jù)是否同步、高可用自動切換、自動化運維等等。前面講解了四種基于數(shù)據(jù)庫同步的數(shù)據(jù)庫高可用架構(gòu)，如果是在云環(huán)境下，推薦使用UDB云數(shù)據(jù)庫這樣的產(chǎn)品一鍵完成上述配置，幫助減輕業(yè)務(wù)的運維壓力。

作者介紹

丁順，UCloud資深存儲研發(fā)工程師，在云產(chǎn)品、大規(guī)模海量存儲方面具有豐富的經(jīng)驗，擅長于分布式系統(tǒng)、面向服務(wù)、容器化、高可用等方面的架構(gòu)和軟件設(shè)計。