數(shù)據(jù)庫容災(zāi)技術(shù)與數(shù)據(jù)庫的容災(zāi)架構(gòu)緊密相關(guān)，在設(shè)計數(shù)據(jù)庫容災(zāi)技術(shù)時，除了要考慮數(shù)據(jù)庫容災(zāi)架構(gòu)還要對數(shù)據(jù)的備份、恢復(fù)、傳輸?shù)染唧w操作的實現(xiàn)細(xì)節(jié)。一套完整的數(shù)據(jù)庫容災(zāi)技術(shù)既要有采用數(shù)據(jù)備份保護和恢復(fù)數(shù)據(jù)的功能，也要有保證數(shù)據(jù)安全、正確、高效傳輸?shù)墓δ?，同時還要有強大的應(yīng)激防護能力。

來源：全棧云技術(shù)架構(gòu)

全文下載：

金融級數(shù)據(jù)庫容災(zāi)技術(shù)報告（2021）

數(shù)據(jù)備份是以容災(zāi)為目的，為防止故障導(dǎo)致的數(shù)據(jù)丟失，而將全部或者部分?jǐn)?shù)據(jù)復(fù)制到其他存儲介質(zhì)的過程。備份過的數(shù)據(jù)往往通過壓縮打包保存，提升存儲效率。備份數(shù)據(jù)一般不能直接提供數(shù)據(jù)庫服務(wù)，需要一套數(shù)據(jù)恢復(fù)操作流程進行備份逆操作，在現(xiàn)有數(shù)據(jù)庫實例或基于空閑資源搭建新實例，覆蓋原有數(shù)據(jù)，才能再次通過該數(shù)據(jù)庫實例進行訪問。所以數(shù)據(jù)備份也稱為數(shù)據(jù)冷備。

數(shù)據(jù)庫的備份技術(shù)從備份機制可分為物理備份和邏輯備份兩種。物理備份是針對數(shù)據(jù)庫的數(shù)據(jù)文件進行備份的方式。物理備份往往是將數(shù)據(jù)庫的數(shù)據(jù)文件連同備份時間窗口內(nèi)的重做日志一同進行備份。備份完成后，備份程序會重新執(zhí)行重做日志，保持?jǐn)?shù)據(jù)文件中數(shù)據(jù)的一致性。由于物理備份主要備份內(nèi)容是復(fù)制數(shù)據(jù)庫數(shù)據(jù)文件，能最大程度利用IO，備份效率很高。邏輯備份是針對數(shù)據(jù)庫的數(shù)據(jù)內(nèi)容進行備份的方式。

全量備份是基于時間點的數(shù)據(jù)庫鏡像，而增量備份是將此時間點擴展到持續(xù)的時間窗口。通過全量備份和增量備份，數(shù)據(jù)庫可以恢復(fù)備份覆蓋的時間范圍內(nèi)任意時間點的數(shù)據(jù)狀態(tài)。同時數(shù)據(jù)恢復(fù)也可指定恢復(fù)目標(biāo)，將恢復(fù)范圍限制為部分庫表，可大幅降低恢復(fù)時間開銷。

按照監(jiān)管要求，核心業(yè)務(wù)系統(tǒng)生產(chǎn)中心的數(shù)據(jù)庫數(shù)據(jù)能實時同步傳輸?shù)疆惖氐臑?zāi)備中心。下面以MySQL數(shù)據(jù)庫場景為例，介紹幾種不同的同步傳輸技術(shù)，供數(shù)據(jù)庫容災(zāi)架構(gòu)規(guī)劃參考。

MySQL主從復(fù)制6是一個異步的復(fù)制過程，主庫發(fā)送更新事件到從庫，從庫讀取更新記錄，并執(zhí)行更新記錄，使得從庫的內(nèi)容與主庫保持一致。

每一組主從復(fù)制的連接，都由三個獨立的線程協(xié)作實現(xiàn)。在主庫上為每一個連接到主庫的從庫創(chuàng)建一個二進制日志(以下簡稱“binlog”)輸出線程。每一個發(fā)送給從庫的SQL事件或者數(shù)據(jù)變更事件，都會基于binlog傳輸給從庫。而每一個從庫都會為同步創(chuàng)建一個I/O線程和一個SQL線程。I/O線程連接到主庫并請求主庫發(fā)送binlog事件到從庫，讀取到的binlog會更新到本地中繼日志（以下簡稱“relay-log”）文件。而SQL線程讀取到I/O線程寫到relay-log的更新事件后，在數(shù)據(jù)庫中進行執(zhí)行，從而完成數(shù)據(jù)從主庫到從庫的同步。

半同步復(fù)制是MySQL 5.5版本引入的機制7。半同步復(fù)制出現(xiàn)前，雖然異步復(fù)制可以滿足主從實例之間的數(shù)據(jù)同步要求，但如果主庫崩潰，將從庫提升為主庫時，原來的主庫上可能有一部分已經(jīng)提交的數(shù)據(jù)還沒有來得及被從庫接收，主從不一致將導(dǎo)致切換后的新主庫丟失這一部分?jǐn)?shù)據(jù)。

半同步復(fù)制改進了事務(wù)提交的邏輯。客戶端在主庫上寫入一個事務(wù)時，需要等待從庫接收到主庫相關(guān)的binlog數(shù)據(jù)，且主庫接收到從庫的應(yīng)答之后，客戶端才能收到事務(wù)成功提交的消息。

早期的半同步復(fù)制存在一些缺陷。主庫在等待應(yīng)答的過程中，存儲引擎內(nèi)部已經(jīng)提交的事務(wù)，只是阻塞返回客戶端消息而已，此時如果有其他會話對該會話事務(wù)修改數(shù)據(jù)進行查詢會查詢到數(shù)據(jù)。如果此時出現(xiàn)主庫故障轉(zhuǎn)移，非發(fā)起數(shù)據(jù)庫提交的客戶端可能會出現(xiàn)幻讀。所以MySQL 5.7版本對半同步進行了優(yōu)化，稱為增強半同步復(fù)制。優(yōu)化后一個事務(wù)在存儲引擎內(nèi)部提交之前，必須要先收到從庫的應(yīng)答確認(rèn)，否則不進行事務(wù)的最后提交，從而解決上述提到的幻讀問題。

MySQL在5.7版本正式推出組復(fù)制（MySQL Group Replication8，以下簡稱“MGR”）機制。MGR集群由若干個節(jié)點共同組成一個復(fù)制組，一個事務(wù)的提交，必須經(jīng)過組內(nèi)大多數(shù)節(jié)點決議并通過才能得以提交。

引入組復(fù)制，主要是為了解決異步主從復(fù)制和半同步復(fù)制可能產(chǎn)生數(shù)據(jù)不一致的問題。組復(fù)制依靠分布式一致性協(xié)議實現(xiàn)了分布式架構(gòu)下數(shù)據(jù)的最終一致性，提供了MySQL集群的多主寫入方案。

MGR技術(shù)與Oracle RAC類似，對集群網(wǎng)絡(luò)的要求非常高。網(wǎng)絡(luò)延時和不穩(wěn)定會嚴(yán)重影響MGR集群的正常工作，所以多用在單數(shù)據(jù)中心的內(nèi)網(wǎng)環(huán)境中，對于主備和多活容災(zāi)架構(gòu)下異地同步的場景，存在一定的短板。

半同步復(fù)制機制保障了主庫故障切換時事務(wù)數(shù)據(jù)能夠在至少一個從庫中持久化存儲，保證切換過程不丟失最新數(shù)據(jù)。隨著數(shù)據(jù)庫集群規(guī)模逐漸增大，同城和異地多機房災(zāi)備架構(gòu)對同步的要求也愈發(fā)提高。當(dāng)跨多機房部署的集群出現(xiàn)大規(guī)模故障，例如機房故障或?qū)＞€故障時，主庫和完成接收binlog數(shù)據(jù)的從庫節(jié)點可能同時出現(xiàn)故障。因此在半同步的基礎(chǔ)上，出現(xiàn)了分組強同步機制。

分組強同步機制能夠保證在跨機房的場景下仍然保持高可用和強同步的能力。任何一個集群的從庫可以分成若干組，在每一組中，只要有一個從庫返回成功，則認(rèn)為該組復(fù)制成功。當(dāng)所有的組都復(fù)制成功，主庫的事務(wù)才能完成提交。

分組強同步復(fù)制算法可以保證已經(jīng)提交成功事務(wù)的數(shù)據(jù)不丟失，修復(fù)了MySQL原生半同步可能丟失數(shù)據(jù)的隱患，確保在主庫發(fā)生故障情況下，不會因為二進制日志丟失導(dǎo)致從庫丟失數(shù)據(jù)，進一步提升了數(shù)據(jù)的可靠性。

為了與數(shù)據(jù)庫產(chǎn)品配套，云平臺供應(yīng)商和數(shù)據(jù)庫廠商推出數(shù)據(jù)傳輸服務(wù)（DTS），該服務(wù)用于在異構(gòu)數(shù)據(jù)庫之間進行數(shù)據(jù)遷移、數(shù)據(jù)同步和數(shù)據(jù)訂閱。DTS 支持在業(yè)務(wù)不影響源數(shù)據(jù)庫服務(wù)的前提下進行數(shù)據(jù)庫遷移，利用實時同步通道構(gòu)建異地容災(zāi)的高可用數(shù)據(jù)庫架構(gòu)。DTS 往往支持在主流數(shù)據(jù)庫之間進行結(jié)構(gòu)遷移、全量數(shù)據(jù)遷移和實時增量數(shù)據(jù)同步，其遷移同步任務(wù)還可按照同步范圍并行進行同步。

數(shù)據(jù)傳輸服務(wù)在異地災(zāi)備場景下也被作為異步同步的重要方案。

當(dāng)分布式數(shù)據(jù)庫各類節(jié)點出現(xiàn)故障時，其監(jiān)控系統(tǒng)應(yīng)該能實時感知到故障種類和范圍，包括各類節(jié)點的進程故障、服務(wù)器故障、磁盤故障和網(wǎng)絡(luò)故障等，都可以依據(jù)預(yù)案配置，自動進行故障切換。

主備容災(zāi)架構(gòu)下，容災(zāi)機房內(nèi)會建設(shè)一套與生產(chǎn)機房相同規(guī)模的服務(wù)。如果生產(chǎn)中心出現(xiàn)災(zāi)難而不可用，數(shù)據(jù)庫管理系統(tǒng)應(yīng)該能自動將數(shù)據(jù)庫服務(wù)切換至災(zāi)備中心。在異地容災(zāi)架構(gòu)下，數(shù)據(jù)庫甚至能夠抵御地理級災(zāi)難，如地震洪水等。該類災(zāi)難可能會影響整個城市區(qū)域，使得同城機房均不可用，從而將服務(wù)切換至異地容災(zāi)中心。

以SQL Server數(shù)據(jù)庫為例，介紹集中式架構(gòu)數(shù)據(jù)庫的典型故障切換技術(shù)。SQL Server采用SQL Server Always On可用性組來支持對一組分散的數(shù)據(jù)庫實施故障轉(zhuǎn)移。一個可用性組支持一組讀寫主數(shù)據(jù)庫，以及一至八組對應(yīng)的輔助數(shù)據(jù)庫(包括一個主副本和最多四個同步提交輔助副本)，每個副本承載一組輔助數(shù)據(jù)庫，同時也是可用性組的潛在故障轉(zhuǎn)移目標(biāo)。發(fā)生故障轉(zhuǎn)移時，數(shù)據(jù)庫通過一組獨立的服務(wù)器故障轉(zhuǎn)移群集服務(wù)，將實例的資源所有權(quán)轉(zhuǎn)移到指定的故障轉(zhuǎn)移節(jié)點。然后SQL Server實例在故障轉(zhuǎn)移節(jié)點上重新啟動，使數(shù)據(jù)庫恢復(fù)如常。無論在任何時刻，故障轉(zhuǎn)移群集中只有一個節(jié)點可以承載故障轉(zhuǎn)移群集實例和基礎(chǔ)資源。

Always On可用性組主副本將每個主數(shù)據(jù)庫的事務(wù)日志記錄發(fā)送到每個輔助數(shù)據(jù)庫，每個次要副本則緩存事務(wù)日志記錄，然后將日志記錄應(yīng)用到相應(yīng)的輔助數(shù)據(jù)庫。主數(shù)據(jù)庫與每個連接的輔助數(shù)據(jù)庫獨立進行數(shù)據(jù)同步。因此一個輔助數(shù)據(jù)庫可以掛起或失敗，但不會影響其他輔助數(shù)據(jù)庫，一個主數(shù)據(jù)庫也可以掛起或失敗，也不會影響其他主數(shù)據(jù)庫。

分布式數(shù)據(jù)庫架構(gòu)由于進程、磁盤和服務(wù)器等故障，往往導(dǎo)致集群的少量節(jié)點實例不可用，應(yīng)對措施主要是通過冗余和副本節(jié)點進行替換止損，替換過程中可能出現(xiàn)主備切換或主從切換；對于交換機、路由器等網(wǎng)絡(luò)設(shè)備發(fā)生故障，除了導(dǎo)致部分節(jié)點實例不可用外，還可能出現(xiàn)集群分裂情況，因此分布式數(shù)據(jù)庫需要建立應(yīng)付各種類型和規(guī)模故障的容災(zāi)能力。

當(dāng)其中一個計算節(jié)點出現(xiàn)故障，流量以秒級切換至其他計算節(jié)點。整個切換過程對用戶透明，應(yīng)用代碼無需變更，應(yīng)用進程無需重啟。

計算節(jié)點自愈分為故障感知和故障處理兩部分。故障感知是指通過節(jié)點代理的定時任務(wù)定期執(zhí)行自愈監(jiān)控項采集任務(wù)，對計算節(jié)點的監(jiān)控指標(biāo)進行采集，并上報至服務(wù)自愈模塊，該模塊對節(jié)點的監(jiān)控數(shù)據(jù)進行分析，對可能的故障信息進行定位和二次檢測，若確定為故障則發(fā)起故障處理任務(wù)。故障處理是指服務(wù)自愈模塊檢測到故障節(jié)點，任務(wù)調(diào)度模塊創(chuàng)建自愈任務(wù)，自動對故障節(jié)點進行恢復(fù)處理，處理完成后故障節(jié)點重新上線恢復(fù)正常服務(wù)。

分布式數(shù)據(jù)庫采用多副本保存數(shù)據(jù)，存儲節(jié)點通過多副本方式構(gòu)成集群。最常見的集群模式是主從集群，即一個主節(jié)點負(fù)責(zé)寫入，并基于一定的一致性算法同步至其他從庫。當(dāng)對外提供數(shù)據(jù)庫服務(wù)時，主庫承擔(dān)讀寫服務(wù)，從庫提供只讀服務(wù)。當(dāng)主庫節(jié)點故障時，系統(tǒng)會自動發(fā)現(xiàn)并嘗試恢復(fù)主庫，如果主庫無法恢復(fù)則發(fā)起主從切換。

切換協(xié)調(diào)模塊為切換核心模塊，負(fù)責(zé)存儲節(jié)點健康診斷、切換仲裁與協(xié)調(diào)，并變更集群的拓?fù)湫畔?。如上圖所示，數(shù)據(jù)庫實例的三個節(jié)點代理構(gòu)成了切換的協(xié)調(diào)者。節(jié)點代理通過與決策集群通信獲取其托管的集群元信息，并借助集群取得集群中其它節(jié)點代理的通訊方式。

金融類業(yè)務(wù)數(shù)據(jù)模型復(fù)雜度較高，往往需要多維度進行數(shù)據(jù)處理和分析。進行業(yè)務(wù)系統(tǒng)分布式改造時，分片策略往往無法避免一個事務(wù)可能跨越多個數(shù)據(jù)分片的情況，需要通過分布式事務(wù)保證數(shù)據(jù)的強一致性。為保障分布式事務(wù)在跨節(jié)點處理時事務(wù)的原子性和一致性，一般使用分布式協(xié)議處理。常用兩階段提交、三階段提交協(xié)議保障事務(wù)的原子性；使用Paxos、Raft等協(xié)議同步數(shù)據(jù)庫的事務(wù)日志從而保障事務(wù)的一致性。支持分布式事務(wù)是金融級分布式數(shù)據(jù)庫產(chǎn)品的核心特性，分布式事務(wù)的容災(zāi)能力是分布式系統(tǒng)容災(zāi)能力的重要考量指標(biāo)。

百度分布式數(shù)據(jù)庫GaiaDB-X采用基于優(yōu)化的XA協(xié)議及兩階段提交算法實現(xiàn)分布式事務(wù)機制。其優(yōu)勢有：1）自研DMVCC11算法，解決分布式全局讀一致性問題；2）解決MySQL原生XA在事務(wù)一致性和持久性上的缺陷；3）在宕機等故障場景下，能夠基于持久化的全局事務(wù)狀態(tài)對懸掛事務(wù)進行提交或回滾，保證分布式事務(wù)的容災(zāi)恢復(fù)能力；4）支持備份恢復(fù)的事務(wù)一致性、死鎖檢測等高級功能。

上圖為GaiaDB-X的分布式事務(wù)架構(gòu)，其中分布式事務(wù)處理器（Distributed Transaction Manager，以下簡稱“DTM”）負(fù)責(zé)SQL路由并管理分布式事務(wù)，是業(yè)務(wù)端訪問數(shù)據(jù)庫服務(wù)的入口。DTM使用Redis存儲多版本的讀視圖基線并存儲數(shù)據(jù)節(jié)點的分布式事務(wù)狀態(tài)信息。

在宕機等故障場景下，全局事務(wù)狀態(tài)持久化在高可用Redis集群中，故障自愈后，新節(jié)點能通過Redis恢復(fù)懸掛的事務(wù)，決定事務(wù)應(yīng)該提交或回滾，保障分布式事務(wù)的高可用能力。

當(dāng)分布式表進行備份和恢復(fù)時，如何保證恢復(fù)數(shù)據(jù)的一致性也是考驗分布式數(shù)據(jù)庫的難題。GaiaDB-X實現(xiàn)了基于全局事務(wù)點的備份恢復(fù)機制。

所有分片同時通過備庫上定時任務(wù)啟動備份任務(wù)獨立進行備份，根據(jù)備份結(jié)果獲取全局事務(wù)標(biāo)識（簡稱“GTID”），并從主庫日志中解析得到備份快照點及對應(yīng)分片的全局事務(wù)信息，與備份數(shù)據(jù)一同備份。這樣基于快照點與全局事務(wù)信息的對應(yīng)關(guān)系，即可在備份恢復(fù)時保證各分片的全局事務(wù)一致性。

為了保障數(shù)據(jù)庫服務(wù)不受業(yè)務(wù)系統(tǒng)突發(fā)過量壓力影響，導(dǎo)致系統(tǒng)穩(wěn)定性下降，數(shù)據(jù)庫需要提供對請求流量進行控制的功能，保障數(shù)據(jù)庫服務(wù)在極端應(yīng)用負(fù)載情況下仍能穩(wěn)定運行。當(dāng)監(jiān)測到連接可用性下降時，會觸發(fā)進入限流模式，基于實時查詢量對主庫和從庫的訪問量進行限制。限制策略有連接數(shù)限制、查詢量限制和處理時間限制等。

SQL入侵防御是對用戶發(fā)送的SQL進行語法解析，過濾非法SQL的一種安全能力。數(shù)據(jù)庫產(chǎn)品一般通過中間件或基于計算節(jié)點集成防火墻功能，對非法SQL進行過濾、阻斷和報警，有效的預(yù)防SQL注入或惡意非法攻擊。對于不同SQL，防火墻采用攔截模式或告警模式進行處理：攔截模式是指當(dāng)發(fā)現(xiàn)非法SQL時，防火墻會自動阻斷其執(zhí)行，并發(fā)送報警通知；告警模式是指當(dāng)發(fā)現(xiàn)非法SQL時，防火墻會允許其繼續(xù)執(zhí)行，但會發(fā)送告警通知。

基于SQL入侵防御技術(shù)，數(shù)據(jù)庫可以有效識別和攔截外部的SQL攻擊行為，并記錄日志，供事后追查。例如各類SQL注入攻擊模式，包括脫庫、高危SQL等，SQL防火墻都能實現(xiàn)有效攔截。

在存儲限額范圍內(nèi)，數(shù)據(jù)庫將刪除的數(shù)據(jù)庫表移動到數(shù)據(jù)回收站保存。對于誤操作或者需要恢復(fù)刪除的情況，可以對數(shù)據(jù)庫表進行DROP操作后進行快速“閃回”。數(shù)據(jù)回收站的數(shù)據(jù)會自動按照清理策略進行清除，不會影響正常數(shù)據(jù)庫服務(wù)。

當(dāng)集群的處理能力不足的時候，分布式數(shù)據(jù)庫支持在線增加計算節(jié)點，擴展服務(wù)能力。同時，當(dāng)集群的計算節(jié)點資源利用率較低時，支持降低集群規(guī)模，減少計算節(jié)點數(shù)量，降低服務(wù)能力，提供服務(wù)能力彈性擴展能力。

由于在分布式數(shù)據(jù)庫系統(tǒng)中計算節(jié)點往往被設(shè)計為無狀態(tài)，通過新增或減少計算節(jié)點數(shù)量，并在配置節(jié)點中進行相關(guān)元數(shù)據(jù)的更新即可完成計算節(jié)點的調(diào)整。

存儲節(jié)點水平擴展通過增加存儲節(jié)點線性提升集群整體容量和吞吐性能，分布式數(shù)據(jù)庫的控制臺可以發(fā)起擴容操作。以百度分布式數(shù)據(jù)庫為例，該操作主要分成四個步驟：1）創(chuàng)建新的存儲節(jié)點；2）重新分布數(shù)據(jù)，并保持新節(jié)點和原節(jié)點數(shù)據(jù)實時同步；3）變更計算節(jié)點拓?fù)?，切換流量到新節(jié)點；4）清理原節(jié)點上的數(shù)據(jù)。

在整體擴容過程中，第三步會對業(yè)務(wù)有秒級的連接閃斷（一般應(yīng)用層具有重連機制），因此分布式數(shù)據(jù)庫往往提供手動觸發(fā)第三步切換操作，運維人員可選擇業(yè)務(wù)低峰期完成切換。

來源：全棧云技術(shù)架構(gòu)

下載地址：

金融級數(shù)據(jù)庫容災(zāi)技術(shù)報告（2021）

分布式數(shù)據(jù)庫原理和架構(gòu)設(shè)計

轉(zhuǎn)載申明：轉(zhuǎn)載本號文章請注明作者和來源，本號發(fā)布文章若存在版權(quán)等問題，請留言聯(lián)系處理，謝謝。

推薦閱讀

更多架構(gòu)相關(guān)技術(shù)知識總結(jié)請參考“架構(gòu)師全店鋪技術(shù)資料打包”相關(guān)電子書(37本技術(shù)資料打包匯總詳情可通過“閱讀原文”獲取)。

全店內(nèi)容持續(xù)更新，現(xiàn)下單“全店鋪技術(shù)資料打包(全)”，后續(xù)可享全店內(nèi)容更新“免費”贈閱，價格僅收198元(原總價350元)。

溫馨提示：

掃描二維碼關(guān)注公眾號，點擊閱讀原文鏈接獲取“架構(gòu)師技術(shù)全店資料打包匯總(全)”電子書資料詳情。