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

1、金融級數(shù)據(jù)庫容災(zāi)技術(shù)報告目錄 HYPERLINK l _bookmark0 一、容災(zāi)備份概述1 HYPERLINK l _bookmark1 (一) 容災(zāi)備份基礎(chǔ)介紹1 HYPERLINK l _bookmark6 (二) 金融機(jī)構(gòu)災(zāi)備現(xiàn)狀與要求7 HYPERLINK l _bookmark8 (三) 災(zāi)備市場與行業(yè)趨勢9 HYPERLINK l _bookmark11 二、分布式數(shù)據(jù)庫容災(zāi)架構(gòu)10 HYPERLINK l _bookmark12 (一) 單中心容災(zāi)10 HYPERLINK l _bookmark15 (二) 同城互備11 HYPERLINK l _bookmark17 (三)

2、 同城雙活13 HYPERLINK l _bookmark20 (四) 兩地三中心容災(zāi)14 HYPERLINK l _bookmark22 三、數(shù)據(jù)庫容災(zāi)技術(shù)15 HYPERLINK l _bookmark23 (一) 數(shù)據(jù)備份與恢復(fù)15 HYPERLINK l _bookmark24 (二) 數(shù)據(jù)同步與傳輸16 HYPERLINK l _bookmark29 (三) 故障自動切換20 HYPERLINK l _bookmark34 (四) 分布式事務(wù)容災(zāi)23 HYPERLINK l _bookmark38 (五) 應(yīng)用應(yīng)激防護(hù)26 HYPERLINK l _bookmark41 四、分布式數(shù)

3、據(jù)庫容災(zāi)方案28 HYPERLINK l _bookmark42 (一) 節(jié)點故障29 HYPERLINK l _bookmark46 (二) 網(wǎng)絡(luò)故障32 HYPERLINK l _bookmark47 (三) 同城雙活生產(chǎn)中心災(zāi)難33 HYPERLINK l _bookmark50 (四) 兩地三中心主區(qū)域災(zāi)難38 HYPERLINK l _bookmark52 五、總結(jié)與展望39 HYPERLINK l _bookmark53 (一) 混合業(yè)務(wù)負(fù)載降低容災(zāi)復(fù)雜度39 HYPERLINK l _bookmark54 (二) 人工智能改善容災(zāi)處置靈活性39 HYPERLINK l _book

4、mark55 (三) 云原生實現(xiàn)容災(zāi)過程可編排40 HYPERLINK l _bookmark56 (四) 混沌工程提升容災(zāi)架構(gòu)韌性40 HYPERLINK l _bookmark57 參考文獻(xiàn)42圖 目 錄 HYPERLINK l _bookmark9 圖 1 2010-2022 中國災(zāi)備行業(yè)市場規(guī)模9 HYPERLINK l _bookmark14 圖 2 單中心容災(zāi)部署架構(gòu)示意圖11 HYPERLINK l _bookmark16 圖 3 異地互備容災(zāi)部署架構(gòu)示意圖12 HYPERLINK l _bookmark18 圖 4 同城雙活容災(zāi)部署架構(gòu)示意圖13 HYPERLINK l _bo

5、okmark19 圖 5 基于多個數(shù)據(jù)中心的數(shù)據(jù)分片示意圖14 HYPERLINK l _bookmark21 圖 6 兩地三中心容災(zāi)部署架構(gòu)示意圖15 HYPERLINK l _bookmark28 圖 7 數(shù)據(jù)傳輸服務(wù)架構(gòu)示意圖20 HYPERLINK l _bookmark32 圖 8 計算節(jié)點故障切換示意圖22 HYPERLINK l _bookmark33 圖 9 存儲節(jié)點故障切換示意圖23 HYPERLINK l _bookmark35 圖 10 GaiaDB-X 分布式事務(wù)機(jī)制示意圖24 HYPERLINK l _bookmark37 圖 11 基于全局事務(wù)點的備份恢復(fù)機(jī)制示意圖

6、25 HYPERLINK l _bookmark39 圖 12 SQL 防火墻示意圖27 HYPERLINK l _bookmark40 圖 13 存儲節(jié)點水平擴(kuò)展示意圖28 HYPERLINK l _bookmark43 圖 14 計算節(jié)點故障轉(zhuǎn)移切換示意圖30 HYPERLINK l _bookmark44 圖 15 主庫節(jié)點故障轉(zhuǎn)移切換示意圖31 HYPERLINK l _bookmark45 圖 16 從庫節(jié)點故障轉(zhuǎn)移切換示意圖32 HYPERLINK l _bookmark48 圖 17 同城雙活生產(chǎn)中心故障轉(zhuǎn)移切換示意圖34 HYPERLINK l _bookmark49 圖 18

7、 主從切換后分片拓?fù)湔{(diào)整示意圖34 HYPERLINK l _bookmark51 圖 19 兩地三中心容災(zāi)切換示意圖38表 目 錄 HYPERLINK l _bookmark2 表 1 信息災(zāi)備發(fā)生方式2 HYPERLINK l _bookmark4 表 2 備份類型及差異5金融級數(shù)據(jù)庫容災(zāi)技術(shù)報告（2021 年） PAGE 7一、容災(zāi)備份概述容災(zāi)備份簡稱“災(zāi)備”，是指利用科學(xué)的技術(shù)手段和方法，提前建立系統(tǒng)化的數(shù)據(jù)應(yīng)急方式，以應(yīng)對災(zāi)難的發(fā)生。容災(zāi)與備份是兩個獨立的概念，容災(zāi)是為了在遭遇災(zāi)害時保證信息系統(tǒng)能正常運行，幫助企業(yè)實現(xiàn)業(yè)務(wù)連續(xù)性的目標(biāo)，備份是為了應(yīng)對災(zāi)難來臨時造成的數(shù)據(jù)丟失問題。(一

8、)容災(zāi)備份基礎(chǔ)介紹災(zāi)備由來及定義災(zāi)備行業(yè)起源于20世紀(jì)70年代的美國費城。1979年，SunGard公司在費城建立了全世界第一個災(zāi)備中心，當(dāng)時人們關(guān)注的重點是企業(yè)的數(shù)據(jù)備份和系統(tǒng)備份。后來，IT備份發(fā)展到了災(zāi)難恢復(fù)規(guī)劃（DRP），在IT備份中加入了災(zāi)難恢復(fù)預(yù)案、資源需求、災(zāi)備中心管理，形成了對生產(chǎn)運行中心的保障概念。再后來，人們把災(zāi)難恢復(fù)從IT角度逐漸轉(zhuǎn)向了業(yè)務(wù)的角度，用業(yè)務(wù)來衡量災(zāi)備目標(biāo)，即哪些業(yè)務(wù)最重要，哪些業(yè)務(wù)可容忍的恢復(fù)時間最短。隨著企業(yè)規(guī)模擴(kuò)展及信息系統(tǒng)的應(yīng)用范圍日益擴(kuò)大，信息系統(tǒng)在企業(yè)運營過程中的角色愈發(fā)重要，為防范因為各種因素企業(yè)數(shù)據(jù)遭到毀壞，如地震、火災(zāi)、恐怖襲擊等，異地災(zāi)備建

9、設(shè)的需求應(yīng)運而生。災(zāi)備發(fā)生方式根據(jù)已經(jīng)發(fā)生的災(zāi)備事件總結(jié)分析，通常情況下災(zāi)難發(fā)生的原因有以下幾種方式：表 1 信息災(zāi)備發(fā)生方式災(zāi)難原因具體方式典型事件IT系統(tǒng)問題服務(wù)器、應(yīng)用程序、數(shù)據(jù)庫等故障2017 年 1 月 Gitlab 遭受DDoS攻擊，導(dǎo)致數(shù)據(jù)庫寫入鎖定，網(wǎng)站出現(xiàn)不穩(wěn)定和宕機(jī)。信息安全管理問題升級失敗、權(quán)限管理混亂2018年4月，英國TSB銀行系統(tǒng)升級嚴(yán)重混亂。災(zāi)害類事件地震、洪災(zāi)、火災(zāi)2014年4月，三星位于首爾郊區(qū)的果川的數(shù)據(jù)中心發(fā)生火災(zāi)，導(dǎo)致三星服務(wù)宕機(jī)。來源：公開資料整理根據(jù)研究表明 HYPERLINK l _bookmark3 1，在以上各種導(dǎo)致系統(tǒng)故障的原因中，其占比分

10、別為：約40%的系統(tǒng)故障由操作人員失誤引起，約40%的系統(tǒng)故障由 應(yīng)用軟件的問題所引起，約20%的系統(tǒng)故障由設(shè)備的物理原因引起， 如硬件失效、掉電等。綜上，系統(tǒng)故障導(dǎo)致業(yè)務(wù)下線的主要原因在于 人為操作失誤或應(yīng)用軟件問題，而自然災(zāi)難引發(fā)的業(yè)務(wù)下線概率較小。容災(zāi)定義及分類容災(zāi)，即災(zāi)難發(fā)生時，在保證生產(chǎn)系統(tǒng)數(shù)據(jù)盡量少丟失的情況下， 保持生產(chǎn)系統(tǒng)業(yè)務(wù)的不間斷運行。容災(zāi)技術(shù)是信息系統(tǒng)的高可用性技術(shù)的一個組成部分。容災(zāi)方式根據(jù)容災(zāi)距離和保護(hù)等級存在兩種分類方式。按容災(zāi)距離劃分按照容災(zāi)距離分類，容災(zāi)可分為本地容災(zāi)和異地容災(zāi)。本地容災(zāi)一般指主機(jī)集群，當(dāng)某臺主機(jī)發(fā)生故障，其它主機(jī)可以12021 中國災(zāi)備行業(yè)白皮

11、書，英方研究院。代替該主機(jī)，繼續(xù)正常對外提供服務(wù)。通?？梢酝ㄟ^共享存儲或雙機(jī) 雙柜的方式實現(xiàn)本地容災(zāi)，其中多以共享存儲為主。共享存儲由活動 主節(jié)點、不活動備節(jié)點和共享存儲三部分組成。其中兩臺計算資源節(jié) 點提供主備角色服務(wù)，通過SAN網(wǎng)絡(luò)附加型存儲作為數(shù)據(jù)存儲的介質(zhì)。主備節(jié)點共享一份存儲，一旦主節(jié)點宕機(jī)，備節(jié)點可基于共享存儲實 現(xiàn)業(yè)務(wù)的接管。共享存儲的短板在于遠(yuǎn)距離高可用接管成本較高，存 在較大存儲故障風(fēng)險，且只支持一對一架構(gòu)。異地容災(zāi)是指在與生產(chǎn)機(jī)房一定距離的異地建立與生產(chǎn)機(jī)房類 似的備份中心，并采用特定的技術(shù)將生產(chǎn)中心的數(shù)據(jù)傳輸?shù)絺浞葜行摹鹘y(tǒng)異地容災(zāi)通過磁盤或磁帶備份手段，對本地關(guān)鍵數(shù)據(jù)進(jìn)

12、行備份， 然后運輸至生產(chǎn)中心之外的地方進(jìn)行保存，災(zāi)難發(fā)生后，可通過磁盤 或磁帶實現(xiàn)系統(tǒng)和數(shù)據(jù)的恢復(fù)。這種手段成本低、易操作，但是當(dāng)存 儲數(shù)據(jù)大規(guī)模增加時，存儲介質(zhì)管理將成為難以解決的問題?，F(xiàn)多采 用網(wǎng)絡(luò)傳輸?shù)姆绞竭M(jìn)行異地容災(zāi)。按保護(hù)級別劃分按照保護(hù)級別，容災(zāi)系統(tǒng)可分為數(shù)據(jù)級容災(zāi)、應(yīng)用級容災(zāi)和業(yè)務(wù)級容災(zāi)。數(shù)據(jù)級容災(zāi)是最基礎(chǔ)的手段，指通過建立異地容災(zāi)中心，進(jìn)行數(shù)據(jù)的遠(yuǎn)程備份，發(fā)生災(zāi)難時應(yīng)用會中斷。這種級別的容災(zāi)方案實施相對簡單、資源投入和后期運維成本低，但系統(tǒng)恢復(fù)速度較慢，業(yè)務(wù)恢復(fù)難度高。應(yīng)用級容災(zāi)主要針對關(guān)鍵應(yīng)用進(jìn)行的容災(zāi)方案，應(yīng)用級容災(zāi)是建立在數(shù)據(jù)級容災(zāi)基礎(chǔ)上，對應(yīng)用系統(tǒng)進(jìn)行實時復(fù)制，即在備份

13、站點構(gòu)建一套相同的應(yīng)用系統(tǒng)，通過同步或異步復(fù)制技術(shù)，保障關(guān)鍵應(yīng)用在允許的時間范圍內(nèi)恢復(fù)運行。應(yīng)用級容災(zāi)實施難度高、資源投入和后期運維成本較高，需要更多的軟件實現(xiàn)，但是系統(tǒng)恢復(fù)速度較快，業(yè)務(wù)恢復(fù)難度較低。業(yè)務(wù)級容災(zāi)是最高級別的容災(zāi)手段，它包括除了保障IT系統(tǒng)業(yè)務(wù)連續(xù)性外也提供非IT系統(tǒng)保障，業(yè)務(wù)級容災(zāi)是在數(shù)據(jù)級容災(zāi)和應(yīng)用級容災(zāi)基礎(chǔ)之上，還需要考慮IT系統(tǒng)之外的業(yè)務(wù)因素。如發(fā)生重大災(zāi)難時，用戶的辦公場所可能會被損壞，除了恢復(fù)原來的數(shù)據(jù)外，還需要工作人員在備份的工作場所能夠正常地開展業(yè)務(wù)。備份定義及分類備份是指數(shù)據(jù)或系統(tǒng)的備份，它是容災(zāi)的基礎(chǔ)，是指為防止系統(tǒng)出現(xiàn)操作失誤或故障導(dǎo)致的數(shù)據(jù)丟失，而將全部

14、或部分?jǐn)?shù)據(jù)集合從應(yīng)用主機(jī)的硬盤或陣列復(fù)制到其它存儲介質(zhì)的過程，數(shù)據(jù)庫的備份與恢復(fù)通?；跀?shù)據(jù)庫日志文件進(jìn)行操作。備份方式根據(jù)備份數(shù)據(jù)量、備份頻率和備份對象等多種分類方式。按照備份數(shù)據(jù)量，備份可分為全量備份、增量備份和差異備份。全量備份是指用存儲介質(zhì)對整個數(shù)據(jù)及系統(tǒng)進(jìn)行完全備份。這種備份方式易理解、易恢復(fù)；短板是在備份數(shù)據(jù)中有大量的重復(fù)數(shù)據(jù)， 由于需要備份的數(shù)據(jù)量相當(dāng)大，因此備份時間較長。增量備份是指備份自上一次備份（包含全量備份、差異備份、增量備份）之后有變化的數(shù)據(jù)。增量備份過程中，只備份有標(biāo)記的選中的文件和文件夾。這種備份的優(yōu)點是重復(fù)數(shù)據(jù)少，即節(jié)省存儲空間又縮短了備份時間。差異備份是指備份上

15、一次全量備份之后有變化的數(shù)據(jù)，差異備份后不標(biāo)記為已備份文件，進(jìn)行恢復(fù)時，只需對第一次全量備份和最后一次差異備份進(jìn)行恢復(fù)。增量備份與差異備份的差異是，增量備份判斷數(shù)據(jù)更新標(biāo)準(zhǔn)是依據(jù)上一次備份檢查點，而差異備份一定是依據(jù)全量備份檢查點。如沒有全量備份，就沒有差異備份。差異備份的主要目的是限制完全恢復(fù)時使用的介質(zhì)數(shù)量。表 2 備份類型及差異備份類型原理優(yōu)點缺點全量備份對備份集合所有數(shù)據(jù)進(jìn)行備份完全恢復(fù)系統(tǒng)需要的時間最短費時，如果文件不頻繁更改，備份內(nèi)容幾乎完全相同增量備份對上次備份后改變的數(shù)據(jù)進(jìn)行備份存儲的數(shù)據(jù)最少，備份速度最快完全恢復(fù)系統(tǒng)需要時間比全量或差異備份長差異備份對自上次全量備份后改變的數(shù)

16、據(jù)進(jìn)行備份恢復(fù)時僅需要最新全量備份和相應(yīng)的差異備份，速度比全量備份快完全恢復(fù)系統(tǒng)需要時間比全量備份長，如果大量數(shù)據(jù)發(fā)生變化，備份所需時間長于增量備份來源：2021中國災(zāi)備行業(yè)白皮書，英方研究院按照備份頻率，備份可以分為定時備份和實時備份。定時備份是指有時間間隔的數(shù)據(jù)備份方式，比如一小時一次，一天一次，定時備份無法保證數(shù)據(jù)零丟失。實時備份是指無時間間隔的數(shù)據(jù)備份方式， 通過實時數(shù)據(jù)復(fù)制，保證主備兩端的數(shù)據(jù)讀寫一致，確保數(shù)據(jù)零丟失。按照備份對象，備份可以分為字節(jié)級備份、塊級備份和文件級備份。字節(jié)級備份是指以字節(jié)級變量為基本單位，通過捕獲生產(chǎn)系統(tǒng)數(shù)據(jù)的變化，并將變化數(shù)據(jù)實時傳輸?shù)絺涠?。塊級備份是指以

17、磁盤塊為基本單位，將數(shù)據(jù)從源端復(fù)制到備端，即每次備份數(shù)據(jù)以一個扇區(qū)或 多個連續(xù)扇區(qū)為單位來進(jìn)行備份。文件級備份是指以文件為單位，將 數(shù)據(jù)以文件的形式讀出，通過文件系統(tǒng)接口調(diào)用備份到另一個介質(zhì)上。此外，根據(jù)數(shù)據(jù)備份時服務(wù)器是否停機(jī)可分為冷備和熱備，按照數(shù)據(jù) 存儲介質(zhì)之間的距離又分為本地備份和異地備份。容災(zāi)與備份的區(qū)別備份是容災(zāi)的基石，其目的是為了系統(tǒng)數(shù)據(jù)崩潰時能夠恢復(fù)數(shù)據(jù)。容災(zāi)不能替換備份，容災(zāi)系統(tǒng)會完整地將生產(chǎn)系統(tǒng)的任何變化復(fù)制到 容災(zāi)端，比如誤將計費系統(tǒng)內(nèi)的用戶信息表刪除，容災(zāi)端的用戶信息 表也會被完整刪除。如果是同步容災(zāi)，容災(zāi)端的相關(guān)數(shù)據(jù)同時被刪除 了；如果是異步容災(zāi)，容災(zāi)端的相關(guān)數(shù)據(jù)在數(shù)

18、據(jù)異步復(fù)制的間隔內(nèi)會 被刪除。這時需要從備份系統(tǒng)中取出最新備份，從而恢復(fù)被錯誤刪除 的信息。因此，容災(zāi)系統(tǒng)的建設(shè)不能替代備份系統(tǒng)的建設(shè)。災(zāi)難恢復(fù)衡量指標(biāo)評估一個災(zāi)備系統(tǒng)可靠性的兩個重要指標(biāo)為恢復(fù)時間目標(biāo)（Recovery Time Objective，以下簡稱“RTO”）與恢復(fù)點目標(biāo)（Recovery Point Objective，以下簡稱“RPO”）。RTO是恢復(fù)時間目標(biāo)，指災(zāi)難發(fā)生后，從系統(tǒng)宕機(jī)導(dǎo)致業(yè)務(wù)停頓開始，到系統(tǒng)恢復(fù)至可以支持業(yè)務(wù)部門運作，業(yè)務(wù)恢復(fù)運營之時，此兩點之間的時間，RTO可簡單地描述為企業(yè)能容忍的恢復(fù)時間。根據(jù)金融行業(yè)標(biāo)準(zhǔn)規(guī)定 HYPERLINK l _bookmark5

19、 2，金融領(lǐng)域分布式事務(wù)數(shù)據(jù)庫災(zāi)難恢復(fù)能力應(yīng)至2 JR/T 0205-2020分布式數(shù)據(jù)庫技術(shù)金融應(yīng)用規(guī)范 災(zāi)難恢復(fù)要求，中國人民銀行。金融級數(shù)據(jù)庫容災(zāi)技術(shù)報告（2021 年） PAGE 9少達(dá)到該標(biāo)準(zhǔn)中規(guī)定的4級以上，其中4級RTO30分鐘、5級15分鐘，6級1分鐘。RPO是恢復(fù)點目標(biāo)，指災(zāi)難發(fā)生后，業(yè)務(wù)系統(tǒng)所能容忍的最大數(shù)據(jù)丟失量，它是衡量企業(yè)在發(fā)生災(zāi)難后會丟失多少生產(chǎn)數(shù)據(jù)的指標(biāo)。根據(jù)上述金融行業(yè)標(biāo)準(zhǔn)，應(yīng)用于金融領(lǐng)域的分布式事務(wù)數(shù)據(jù)庫RPO要求均為0。RTO與RPO的確定必須在進(jìn)行風(fēng)險分析和業(yè)務(wù)影響分析后根據(jù)不同的業(yè)務(wù)需求確定，不同企業(yè)統(tǒng)一業(yè)務(wù)，需求也會有所不同。最理想的情況是兩個指標(biāo)都為

20、零。(二)金融機(jī)構(gòu)災(zāi)備現(xiàn)狀與要求金融機(jī)構(gòu)災(zāi)備現(xiàn)狀與需求金融機(jī)構(gòu)對數(shù)據(jù)零丟失和業(yè)務(wù)連續(xù)性要求在各行各業(yè)要求最高。以銀行為例，銀行信息系統(tǒng)架構(gòu)最為嚴(yán)格，要求采用兩地三中心或主備等多種模式構(gòu)建災(zāi)備系統(tǒng)，通過裸光纖或密集型光波復(fù)用（DWDN） 技術(shù)實現(xiàn)數(shù)據(jù)中心與各個營業(yè)網(wǎng)點的數(shù)據(jù)同步。以證券公司為例，各大券商的災(zāi)備中心的架構(gòu)通常采用虛擬化技術(shù)，實現(xiàn)生產(chǎn)端物理機(jī)與虛擬機(jī)并存，災(zāi)備端以虛擬機(jī)為主的配置 HYPERLINK l _bookmark7 3。綜合各類金融機(jī)構(gòu)，主要需求包括但不限于：1）海量數(shù)據(jù)備份、實時復(fù)制；2）數(shù)據(jù)庫數(shù)據(jù)跨平臺遷移和讀寫分離；3）主備業(yè)務(wù)系統(tǒng)應(yīng)用高可用；4）提升災(zāi)備中心智能運維

21、水平；5）大規(guī)模災(zāi)備系統(tǒng)可用性驗證的自動化能力等。32021 中國災(zāi)備行業(yè)白皮書，英方研究院。金融機(jī)構(gòu)容災(zāi)要求金融機(jī)構(gòu)分類較多，不同行業(yè)發(fā)布的法律法規(guī)各不相同，以要求最為嚴(yán)格的銀行和證券行業(yè)為代表，以下列舉相關(guān)重要的現(xiàn)行標(biāo)準(zhǔn)規(guī)范：證券期貨業(yè)數(shù)據(jù)分類分級指引自2018年9月27日同日公布實施，數(shù)據(jù)分類是按照GB/T 10113-2003 中的線分類法和GB/T 22240-2008中的定級方法為基礎(chǔ)進(jìn)行分類的。目的是在數(shù)據(jù)分類的基礎(chǔ)上，對已分類數(shù)據(jù)按照數(shù)據(jù)泄露或損壞造成的影響進(jìn)行分級，形成統(tǒng)一的分類分級方法。同時，在數(shù)據(jù)用語的使用過程中，也強(qiáng)調(diào)予以統(tǒng)一。除上述監(jiān)管要求外，證券行業(yè)信息安全監(jiān)管還有

22、包括但不限于：證券期貨業(yè)信息安全保障管理辦法；證券期貨業(yè)信息安全事件報告與調(diào)查處理方法；證券期貨經(jīng)營機(jī)構(gòu)信息系統(tǒng)備份能力標(biāo)準(zhǔn)等。銀行業(yè)信息系統(tǒng)災(zāi)難恢復(fù)管理規(guī)范（JR/T 0044-2008）第八章災(zāi)難備份系統(tǒng)建設(shè)時明確：根據(jù)災(zāi)難恢復(fù)策略制定災(zāi)難備份系統(tǒng)技術(shù)方案，包含數(shù)據(jù)備份系統(tǒng)、備用數(shù)據(jù)處理系統(tǒng)和備用網(wǎng)絡(luò)系統(tǒng)；其次， 為滿足災(zāi)難恢復(fù)策略的要求，應(yīng)對技術(shù)方案中關(guān)鍵技術(shù)應(yīng)用的可行性進(jìn)行驗證測試，并記錄和保存驗證測試的結(jié)果；最后，應(yīng)制定災(zāi)難備份系統(tǒng)集成與測試計劃并組織實施，通過技術(shù)和業(yè)務(wù)測試，確認(rèn)災(zāi)難備份系統(tǒng)的功能和性能達(dá)到設(shè)計指標(biāo)要求。銀行業(yè)信息安全監(jiān)管還有包括但不限于：商業(yè)銀行業(yè)數(shù)據(jù)中心監(jiān)管指引

23、；網(wǎng)上銀行業(yè)務(wù)連續(xù)性監(jiān)控指引；關(guān)于進(jìn)一步加強(qiáng)銀行業(yè)金融機(jī)構(gòu)信息安全保障工作的指導(dǎo)意見等。金融領(lǐng)域確保業(yè)務(wù)連續(xù)性是重中之重，它關(guān)系到廣大投資者和用戶日常的投資行為和經(jīng)濟(jì)消費行為，任何由于數(shù)據(jù)庫導(dǎo)致的非計劃性停機(jī)，都可能引發(fā)巨大的經(jīng)濟(jì)損失和非經(jīng)濟(jì)性影響。2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021E 2022E時間（年）50060.355.149.888.773.9100106.5127.8150151.8177.4200207.8240.5250280.3300350329.1市場（億人民幣）(三)災(zāi)備市場與行業(yè)趨勢數(shù)據(jù)來

24、源：2021中國災(zāi)備行業(yè)白皮書，英方研究院圖 12010-2022 中國災(zāi)備行業(yè)市場規(guī)模智研咨詢報告 HYPERLINK l _bookmark10 4顯示，中國災(zāi)備行業(yè)市場規(guī)模從2010年的49.8億人民幣，增長至2018年近180億人民幣，預(yù)計至2022年中國災(zāi)備行業(yè)市場規(guī)?？蛇_(dá)300億以上。前瞻產(chǎn)業(yè)研究院的報告重點提到云災(zāi)備將成為未來趨勢，云災(zāi)備市場規(guī)模從2013年的1億元，快速增長到201842017-2022 年中國災(zāi)備行業(yè)深度研究及市場前景預(yù)測報告金融級數(shù)據(jù)庫容災(zāi)技術(shù)報告（2021 年） PAGE 42年的10億元，預(yù)計到2022年規(guī)模達(dá)70億元。Gartner預(yù)計到2021年，

25、使用備份而非歸檔方式來管理企業(yè)長期的比例將由2017年的30%升至50%。國際災(zāi)備市場發(fā)展同樣強(qiáng)勁，根據(jù)DataCore的2018年報告 HYPERLINK l _bookmark13 5顯示，有20%的用戶計劃將存儲預(yù)算的25%用于災(zāi)備方面。Marketsand Markets的相關(guān)數(shù)據(jù)也顯示，全球備份和恢復(fù)市場總額將從2017年的71.3億美元上升到2022年的115.9億美元。隨著IT技術(shù)產(chǎn)品不斷迭代，災(zāi)備應(yīng)用場景從同機(jī)房本地備份容災(zāi)，向同城、異地及云端等更宏大的場景延伸；災(zāi)備技術(shù)從傳統(tǒng)的存儲復(fù)制技術(shù)，延伸到基于主機(jī)、操作系統(tǒng)、數(shù)據(jù)庫、文件和網(wǎng)絡(luò)等五大數(shù)據(jù)復(fù)制技術(shù)。災(zāi)備產(chǎn)品也正在不斷拓展

26、邊界，涵蓋傳統(tǒng)系統(tǒng)備份、容災(zāi)和恢復(fù)；數(shù)據(jù)同步、分發(fā)、脫敏、副本管理；大數(shù)據(jù)管理與應(yīng)用；數(shù)據(jù)庫讀寫分離與容災(zāi)等。其中，數(shù)據(jù)庫容災(zāi)架構(gòu)在信息系統(tǒng)容災(zāi)架構(gòu)中發(fā)揮至關(guān)重要的作用。二、分布式數(shù)據(jù)庫容災(zāi)架構(gòu)不同應(yīng)用場景和業(yè)務(wù)需求下，分布式數(shù)據(jù)庫的部署方式應(yīng)該選擇合理容災(zāi)架構(gòu)，常見的分布式數(shù)據(jù)庫容災(zāi)架構(gòu)包括單中心容災(zāi)、同城互備、同城雙活、兩地三中心等。(一)單中心容災(zāi)對于容災(zāi)要求不高的一些內(nèi)部業(yè)務(wù)系統(tǒng)，可以只在單一的生產(chǎn)中心內(nèi)部署。在這種模式下，數(shù)據(jù)庫通過在該生產(chǎn)中心的多個不同可用區(qū)多實例部署，實現(xiàn)數(shù)據(jù)庫服務(wù)高可用。不同可用區(qū)的數(shù)據(jù)庫均能向5The State of Software-Defined Sto

27、rage, Hyperconverged and Cloud Storage應(yīng)用系統(tǒng)提供數(shù)據(jù)庫訪問服務(wù)。來源：北京百度網(wǎng)訊科技有限公司圖 2 單中心容災(zāi)部署架構(gòu)示意圖基于數(shù)據(jù)庫的高可用機(jī)制，可以抵御部分節(jié)點甚至機(jī)房可用區(qū)整體故障，仍然保持?jǐn)?shù)據(jù)庫服務(wù)正常服務(wù)。但如果遇到數(shù)據(jù)中心級的災(zāi)難，則無法保持可用。(二)同城互備同城互備模式需要在災(zāi)備中心內(nèi)部署與生產(chǎn)中心業(yè)務(wù)系統(tǒng)相同資源配置，包括應(yīng)用和數(shù)據(jù)庫在內(nèi)的完整業(yè)務(wù)系統(tǒng)。生產(chǎn)中心和災(zāi)備中心均能承載全流量業(yè)務(wù)壓力。數(shù)據(jù)庫系統(tǒng)在生產(chǎn)中心和災(zāi)備中心都需要冗余部署滿足系統(tǒng)正常運行的全部組件，并配備滿足全量數(shù)據(jù)存儲和訪問壓力的存儲和計算資源。正常情況下，只有生產(chǎn)

28、中心投入運行，災(zāi)備中心處于在線待機(jī)狀態(tài)。當(dāng)數(shù)據(jù)中心發(fā)生災(zāi)難時，災(zāi)備中心可以在短時間內(nèi)切換并提供服務(wù)，快速實現(xiàn)業(yè)務(wù)止損。異地互備模式部署架構(gòu)圖如下：來源：北京百度網(wǎng)訊科技有限公司圖 3 異地互備容災(zāi)部署架構(gòu)示意圖為了一定程度提高資源利用率，針對不同的核心業(yè)務(wù)系統(tǒng)，可交替設(shè)置主備中心。主備中心數(shù)據(jù)同步方式，可以采用強(qiáng)同步機(jī)制或異步同步機(jī)制。這取決于根據(jù)業(yè)務(wù)對數(shù)據(jù)一致性的要求，同時也受到數(shù)據(jù)中心距離帶來的網(wǎng)絡(luò)延時限制。當(dāng)數(shù)據(jù)中心和災(zāi)備中心在同城距離較近，網(wǎng)絡(luò)延時較小，通常選擇強(qiáng)同步，可稱為同城互備；當(dāng)數(shù)據(jù)中心間距離較遠(yuǎn)，跨地區(qū)進(jìn)行傳輸?shù)木W(wǎng)絡(luò)延時較大，可稱為異地互備。(三)同城雙活同城雙活是雙活技術(shù)與

29、同城災(zāi)備中心模式結(jié)合的一種主流容災(zāi)架構(gòu)。業(yè)務(wù)系統(tǒng)可以同時通過生產(chǎn)中心和災(zāi)備中心進(jìn)行訪問，無需指定特定的訪問規(guī)則。數(shù)據(jù)庫架構(gòu)同時兼?zhèn)洚惖鼗淠Ｊ降呢?fù)載均衡和故障自動切換能力，且由于處于同城較近距離，兩個數(shù)據(jù)中心的存儲節(jié)點可以保持?jǐn)?shù)據(jù)強(qiáng)一致。當(dāng)其中一個中心發(fā)生災(zāi)難時，通過接入前端的負(fù)載均衡調(diào)整，可將全流量輸入對等的災(zāi)備中心；數(shù)據(jù)庫同時自動進(jìn)行切換，災(zāi)備中心的數(shù)據(jù)庫集群承載全部查詢請求。同城雙活的部署示意圖如下：來源：北京百度網(wǎng)訊科技有限公司圖 4 同城雙活容災(zāi)部署架構(gòu)示意圖基于數(shù)據(jù)分布式架構(gòu)可以對應(yīng)用層提供透明的雙活能力。以一個四分片的數(shù)據(jù)表為例，分片數(shù)據(jù)可以均勻分布在兩個中心的數(shù)據(jù)庫存儲節(jié)點中：

30、來源：北京百度網(wǎng)訊科技有限公司圖 5 基于多個數(shù)據(jù)中心的數(shù)據(jù)分片示意圖在同城雙活容災(zāi)架構(gòu)下，數(shù)據(jù)庫系統(tǒng)在生產(chǎn)中心和災(zāi)備中心也同樣都需要冗余部署滿足系統(tǒng)正常運行的全部組件，每一個計算中心都需要配備滿足全量業(yè)務(wù)訪問要求的存儲和計算資源。(四)兩地三中心容災(zāi)在同城雙活或者同城互備的架構(gòu)下，再增加一個遠(yuǎn)距離的容災(zāi)中心，可實現(xiàn)兩地三中心的容災(zāi)架構(gòu)。該架構(gòu)在同城容災(zāi)方案的基礎(chǔ)上，獲得了對地震、颶風(fēng)等區(qū)域級災(zāi)難的抵御能力。由于異地災(zāi)備中心距離較遠(yuǎn)，所以數(shù)據(jù)同步一般考慮使用異步模式，可基于數(shù)據(jù)庫異步同步功能實現(xiàn)，或者在應(yīng)用層使用消息隊列等組件進(jìn)行業(yè)務(wù)數(shù)據(jù)異步同步，進(jìn)而實現(xiàn)遠(yuǎn)距離異地機(jī)房的數(shù)據(jù)最終一致性。來源：

31、北京百度網(wǎng)訊科技有限公司圖 6 兩地三中心容災(zāi)部署架構(gòu)示意圖三、數(shù)據(jù)庫容災(zāi)技術(shù)數(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ù)備份保護(hù)和恢復(fù)數(shù)據(jù)的功能，也要有保證數(shù)據(jù)安全、正確、高效傳輸?shù)墓δ?，同時還要有強(qiáng)大的應(yīng)激防護(hù)能力。(一)數(shù)據(jù)備份與恢復(fù)數(shù)據(jù)備份是以容災(zāi)為目的，為防止故障導(dǎo)致的數(shù)據(jù)丟失，而將全部或者部分?jǐn)?shù)據(jù)復(fù)制到其他存儲介質(zhì)的過程。備份過的數(shù)據(jù)往往通過壓縮打包保存，提升存儲效率。備份數(shù)據(jù)一般不能直接提供數(shù)據(jù)庫服務(wù)，需要一套數(shù)據(jù)恢復(fù)操作流程進(jìn)行備份逆操作，在現(xiàn)有

32、數(shù)據(jù)庫實例或基于空閑資源搭建新實例，覆蓋原有數(shù)據(jù)，才能再次通過該數(shù)據(jù)庫實例進(jìn)行訪問。所以數(shù)據(jù)備份也稱為數(shù)據(jù)冷備。數(shù)據(jù)備份數(shù)據(jù)庫的備份技術(shù)從備份機(jī)制可分為物理備份和邏輯備份兩種。物理備份是針對數(shù)據(jù)庫的數(shù)據(jù)文件進(jìn)行備份的方式。物理備份往往是將數(shù)據(jù)庫的數(shù)據(jù)文件連同備份時間窗口內(nèi)的重做日志一同進(jìn)行備份。備份完成后，備份程序會重新執(zhí)行重做日志，保持?jǐn)?shù)據(jù)文件中數(shù)據(jù)的一致性。由于物理備份主要備份內(nèi)容是復(fù)制數(shù)據(jù)庫數(shù)據(jù)文件，能最大程度利用IO，備份效率很高。邏輯備份是針對數(shù)據(jù)庫的數(shù)據(jù)內(nèi)容進(jìn)行備份的方式。這種模式的優(yōu)點是能靈活地選擇備份范圍，即可以選擇指定的庫表進(jìn)行備份，還可以通過條件篩選備份內(nèi)容。邏輯備份的模式

33、下往往通過讀取數(shù)據(jù)轉(zhuǎn)換為“insert into table ”一類SQL語句，需要額外的解析和轉(zhuǎn)換， 同時還涉及大事務(wù)通過事務(wù)隔離性保障數(shù)據(jù)一致性，所以導(dǎo)致效率相對較低。數(shù)據(jù)恢復(fù)全量備份是基于時間點的數(shù)據(jù)庫鏡像，而增量備份是將此時間點擴(kuò)展到持續(xù)的時間窗口。通過全量備份和增量備份，數(shù)據(jù)庫可以恢復(fù)備份覆蓋的時間范圍內(nèi)任意時間點的數(shù)據(jù)狀態(tài)。同時數(shù)據(jù)恢復(fù)也可指定恢復(fù)目標(biāo)，將恢復(fù)范圍限制為部分庫表，可大幅降低恢復(fù)時間開銷。(二)數(shù)據(jù)同步與傳輸按照監(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ī)劃參考

34、。主從復(fù)制MySQL主從復(fù)制 HYPERLINK l _bookmark25 6是一個異步的復(fù)制過程，主庫發(fā)送更新事件到從庫，從庫讀取更新記錄，并執(zhí)行更新記錄，使得從庫的內(nèi)容與主庫保持一致。每一組主從復(fù)制的連接，都由三個獨立的線程協(xié)作實現(xiàn)。在主庫上為每一個連接到主庫的從庫創(chuàng)建一個二進(jìn)制日志( 以下簡稱“binlog”)輸出線程。每一個發(fā)送給從庫的SQL事件或者數(shù)據(jù)變更事件，都會基于binlog傳輸給從庫。而每一個從庫都會為同步創(chuàng)建一個I/O線程和一個SQL線程。I/O線程連接到主庫并請求主庫發(fā)送binlog 事件到從庫，讀取到的binlog會更新到本地中繼日志（以下簡稱“relay-log”）

35、文件。而SQL線程讀取到I/O線程寫到relay-log的更新事件后，在數(shù)據(jù)庫中進(jìn)行執(zhí)行，從而完成數(shù)據(jù)從主庫到從庫的同步。半同步復(fù)制半同步復(fù)制是MySQL 5.5版本引入的機(jī)制 HYPERLINK l _bookmark26 7。半同步復(fù)制出現(xiàn)前， 雖然異步復(fù)制可以滿足主從實例之間的數(shù)據(jù)同步要求，但如果主庫崩潰，將從庫提升為主庫時，原來的主庫上可能有一部分已經(jīng)提交的數(shù)據(jù)還沒有來得及被從庫接收，主從不一致將導(dǎo)致切換后的新主庫丟失這一部分?jǐn)?shù)據(jù)。半同步復(fù)制改進(jìn)了事務(wù)提交的邏輯?？蛻舳嗽谥鲙焐蠈懭胍粋€事6MySQL 官方手冊：Replication7MySQL 官方手冊：Semisynchronous

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

37、制（MySQL Group Replication HYPERLINK l _bookmark27 8， 以下簡稱“MGR”）機(jī)制。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)下異地同步的場景，存在一

38、定的短板。8MySQL 官方手冊：Group Replication分組強(qiáng)同步半同步復(fù)制機(jī)制保障了主庫故障切換時事務(wù)數(shù)據(jù)能夠在至少一個從庫中持久化存儲，保證切換過程不丟失最新數(shù)據(jù)。隨著數(shù)據(jù)庫集群規(guī)模逐漸增大，同城和異地多機(jī)房災(zāi)備架構(gòu)對同步的要求也愈發(fā)提高。當(dāng)跨多機(jī)房部署的集群出現(xiàn)大規(guī)模故障，例如機(jī)房故障或?qū)＞€故障時，主庫和完成接收binlog數(shù)據(jù)的從庫節(jié)點可能同時出現(xiàn)故障。因此在半同步的基礎(chǔ)上，出現(xiàn)了分組強(qiáng)同步機(jī)制。分組強(qiáng)同步機(jī)制能夠保證在跨機(jī)房的場景下仍然保持高可用和強(qiáng)同步的能力。任何一個集群的從庫可以分成若干組，在每一組中， 只要有一個從庫返回成功，則認(rèn)為該組復(fù)制成功。當(dāng)所有的組都復(fù)制成功

39、，主庫的事務(wù)才能完成提交。分組強(qiáng)同步復(fù)制算法可以保證已經(jīng)提交成功事務(wù)的數(shù)據(jù)不丟失， 修復(fù)了MySQL原生半同步可能丟失數(shù)據(jù)的隱患，確保在主庫發(fā)生故障情況下，不會因為二進(jìn)制日志丟失導(dǎo)致從庫丟失數(shù)據(jù)，進(jìn)一步提升了數(shù)據(jù)的可靠性。云數(shù)據(jù)庫數(shù)據(jù)同步服務(wù)為了與數(shù)據(jù)庫產(chǎn)品配套，云平臺供應(yīng)商和數(shù)據(jù)庫廠商推出數(shù)據(jù)傳輸服務(wù)（Data Transmission Service，以下簡稱“DTS”），該服務(wù)用于在異構(gòu)數(shù)據(jù)庫之間進(jìn)行數(shù)據(jù)遷移、數(shù)據(jù)同步和數(shù)據(jù)訂閱。DTS 支持在業(yè)務(wù)不影響源數(shù)據(jù)庫服務(wù)的前提下進(jìn)行數(shù)據(jù)庫遷移，利用實時同步通道構(gòu)建異地容災(zāi)的高可用數(shù)據(jù)庫架構(gòu)。DTS 往往支持在主流數(shù)據(jù)庫之間進(jìn)行結(jié)構(gòu)遷移、全量數(shù)

40、據(jù)遷移和實時增量數(shù)據(jù)同步，其遷移同步任務(wù)還可按照同步范圍并行進(jìn)行同步。數(shù)據(jù)傳輸服務(wù)在異地災(zāi)備場景下也被作為異步同步的重要方案。來源：北京百度網(wǎng)訊科技有限公司圖 7 數(shù)據(jù)傳輸服務(wù)架構(gòu)示意圖(三)故障自動切換當(dāng)分布式數(shù)據(jù)庫各類節(jié)點出現(xiàn)故障時，其監(jiān)控系統(tǒng)應(yīng)該能實時感知到故障種類和范圍，包括各類節(jié)點的進(jìn)程故障、服務(wù)器故障、磁盤故障和網(wǎng)絡(luò)故障等，都可以依據(jù)預(yù)案配置，自動進(jìn)行故障切換。主備容災(zāi)架構(gòu)下，容災(zāi)機(jī)房內(nèi)會建設(shè)一套與生產(chǎn)機(jī)房相同規(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)難可能會影響

41、整個城市區(qū)域， 使得同城機(jī)房均不可用，從而將服務(wù)切換至異地容災(zāi)中心。集中式架構(gòu)以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é)點上重新啟動，

42、使數(shù)據(jù)庫恢復(fù)如常。無論在任何時刻，故障轉(zhuǎn)移群集中只有一個節(jié)點可以承載故障轉(zhuǎn)移群 集實例和基礎(chǔ)資源 HYPERLINK l _bookmark30 9。Always On可用性組主副本將每個主數(shù)據(jù)庫的事務(wù)日志記錄發(fā)送到每個輔助數(shù)據(jù)庫，每個次要副本則緩存事務(wù)日志記錄，然后將日志記錄應(yīng)用到相應(yīng)的輔助數(shù)據(jù)庫。主數(shù)據(jù)庫與每個連接的輔助數(shù)據(jù)庫獨立進(jìn)行數(shù)據(jù)同步。因此一個輔助數(shù)據(jù)庫可以掛起或失敗，但不會影響其他輔助數(shù)據(jù)庫，一個主數(shù)據(jù)庫也可以掛起或失敗，也不會影響其他主數(shù)據(jù)庫 HYPERLINK l _bookmark31 10。分布式架構(gòu)分布式數(shù)據(jù)庫架構(gòu)由于進(jìn)程、磁盤和服務(wù)器等故障，往往導(dǎo)致集群的少量節(jié)點實例

43、不可用，應(yīng)對措施主要是通過冗余和副本節(jié)點進(jìn)行替換止損，替換過程中可能出現(xiàn)主備切換或主從切換；對于交換機(jī)、路由器等網(wǎng)絡(luò)設(shè)備發(fā)生故障，除了導(dǎo)致部分節(jié)點實例不可用外，還可能出現(xiàn)集群分裂情況，因此分布式數(shù)據(jù)庫需要建立應(yīng)付各種類型和規(guī)9SQL Server 官方文檔Windows Server 故障轉(zhuǎn)移群集與 SQL Server10SQL Server 官方文檔什么是 Always On 可用性組？模故障的容災(zāi)能力。計算節(jié)點故障切換當(dāng)其中一個計算節(jié)點出現(xiàn)故障，流量以秒級切換至其他計算節(jié)點。整個切換過程對用戶透明，應(yīng)用代碼無需變更，應(yīng)用進(jìn)程無需重啟。來源：北京百度網(wǎng)訊科技有限公司圖 8 計算節(jié)點故障切換

44、示意圖計算節(jié)點自愈分為故障感知和故障處理兩部分。故障感知是指通過節(jié)點代理的定時任務(wù)定期執(zhí)行自愈監(jiān)控項采集任務(wù)，對計算節(jié)點的監(jiān)控指標(biāo)進(jìn)行采集，并上報至服務(wù)自愈模塊，該模塊對節(jié)點的監(jiān)控數(shù)據(jù)進(jìn)行分析，對可能的故障信息進(jìn)行定位和二次檢測，若確定為故障則發(fā)起故障處理任務(wù)。故障處理是指服務(wù)自愈模塊檢測到故障節(jié)點， 任務(wù)調(diào)度模塊創(chuàng)建自愈任務(wù)，自動對故障節(jié)點進(jìn)行恢復(fù)處理，處理完成后故障節(jié)點重新上線恢復(fù)正常服務(wù)。存儲節(jié)點故障切換分布式數(shù)據(jù)庫采用多副本保存數(shù)據(jù)，存儲節(jié)點通過多副本方式構(gòu)成集群。最常見的集群模式是主從集群，即一個主節(jié)點負(fù)責(zé)寫入，并基于一定的一致性算法同步至其他從庫。當(dāng)對外提供數(shù)據(jù)庫服務(wù)時， 主庫承擔(dān)

45、讀寫服務(wù)，從庫提供只讀服務(wù)。當(dāng)主庫節(jié)點故障時，系統(tǒng)會自動發(fā)現(xiàn)并嘗試恢復(fù)主庫，如果主庫無法恢復(fù)則發(fā)起主從切換。來源：北京百度網(wǎng)訊科技有限公司圖 9 存儲節(jié)點故障切換示意圖切換協(xié)調(diào)模塊為切換核心模塊，負(fù)責(zé)存儲節(jié)點健康診斷、切換仲 裁與協(xié)調(diào)，并變更集群的拓?fù)湫畔?。如上圖所示，數(shù)據(jù)庫實例的三個 節(jié)點代理構(gòu)成了切換的協(xié)調(diào)者。節(jié)點代理通過與決策集群通信獲取其 托管的集群元信息，并借助集群取得集群中其它節(jié)點代理的通訊方式。(四)分布式事務(wù)容災(zāi)金融類業(yè)務(wù)數(shù)據(jù)模型復(fù)雜度較高，往往需要多維度進(jìn)行數(shù)據(jù)處理和分析。進(jìn)行業(yè)務(wù)系統(tǒng)分布式改造時，分片策略往往無法避免一個事務(wù)可能跨越多個數(shù)據(jù)分片的情況，需要通過分布式事務(wù)保證

46、數(shù)據(jù)的強(qiáng)一致性。為保障分布式事務(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ù)機(jī)制。其優(yōu)勢有：1）自研DMVCC HYPERLINK l _bookmark36 11算法， 解決分布式全局讀一致性問題；2）解決MySQL原生XA在事務(wù)一致性和持久性上的缺陷；3）在宕機(jī)等故障

47、場景下，能夠基于持久化的全局事務(wù)狀態(tài)對懸掛事務(wù)進(jìn)行提交或回滾，保證分布式事務(wù)的容災(zāi)恢復(fù)能力；4）支持備份恢復(fù)的事務(wù)一致性、死鎖檢測等高級功能。來源：北京百度網(wǎng)訊科技有限公司圖 10GaiaDB-X 分布式事務(wù)機(jī)制示意圖11*DMVCC：Shao J, Yin B, Chen B, et al. Read Consistency in Distributed Database Based on DMVCCC IEEE, International Conference on High PERFORMANCE Computing. IEEE, 2017:142-151.上圖為GaiaDB-X的分布

48、式事務(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)信息。在宕機(jī)等故障場景下，全局事務(wù)狀態(tài)持久化在高可用Redis集群中，故障自愈后，新節(jié)點能通過Redis恢復(fù)懸掛的事務(wù)，決定事務(wù)應(yīng)該提交或回滾，保障分布式事務(wù)的高可用能力。當(dāng)分布式表進(jìn)行備份和恢復(fù)時，如何保證恢復(fù)數(shù)據(jù)的一致性也是考驗分布式數(shù)據(jù)庫的難題。GaiaDB-X實現(xiàn)了基于全局事務(wù)點的備份恢復(fù)機(jī)制。來源：北京百度網(wǎng)訊科技有限公司圖 11 基

49、于全局事務(wù)點的備份恢復(fù)機(jī)制示意圖所有分片同時通過備庫上定時任務(wù)啟動備份任務(wù)獨立進(jìn)行備份， 根據(jù)備份結(jié)果獲取全局事務(wù)標(biāo)識（Global Transaction ID，以下簡稱“GTID”），并從主庫日志中解析得到備份快照點及對應(yīng)分片的全局事務(wù)信息，與備份數(shù)據(jù)一同備份。這樣基于快照點與全局事務(wù)信息的對應(yīng)關(guān)系，即可在備份恢復(fù)時保證各分片的全局事務(wù)一致性。(五)應(yīng)用應(yīng)激防護(hù)過載保護(hù)為了保障數(shù)據(jù)庫服務(wù)不受業(yè)務(wù)系統(tǒng)突發(fā)過量壓力影響，導(dǎo)致系統(tǒng)穩(wěn)定性下降，數(shù)據(jù)庫需要提供對請求流量進(jìn)行控制的功能，保障數(shù)據(jù)庫服務(wù)在極端應(yīng)用負(fù)載情況下仍能穩(wěn)定運行。當(dāng)監(jiān)測到連接可用性下降時，會觸發(fā)進(jìn)入限流模式，基于實時查詢量對主庫和

50、從庫的訪問量進(jìn)行限制。限制策略有連接數(shù)限制、查詢量限制和處理時間限制等。SQL 入侵防御SQL入侵防御是對用戶發(fā)送的SQL進(jìn)行語法解析，過濾非法SQL 的一種安全能力。數(shù)據(jù)庫產(chǎn)品一般通過中間件或基于計算節(jié)點集成防火墻功能，對非法SQL進(jìn)行過濾、阻斷和報警，有效的預(yù)防SQL注入或惡意非法攻擊。對于不同SQL，防火墻采用攔截模式或告警模式進(jìn)行處理：攔截模式是指當(dāng)發(fā)現(xiàn)非法SQL時，防火墻會自動阻斷其執(zhí)行， 并發(fā)送報警通知；告警模式是指當(dāng)發(fā)現(xiàn)非法SQL時，防火墻會允許其繼續(xù)執(zhí)行，但會發(fā)送告警通知?；赟QL入侵防御技術(shù)，數(shù)據(jù)庫可以有效識別和攔截外部的SQL 攻擊行為，并記錄日志，供事后追查。例如各類S

51、QL注入攻擊模式， 包括脫庫、高危SQL等，SQL防火墻都能實現(xiàn)有效攔截。 來源：北京百度網(wǎng)訊科技有限公司圖 12SQL 防火墻示意圖數(shù)據(jù)回滾在存儲限額范圍內(nèi)，數(shù)據(jù)庫將刪除的數(shù)據(jù)庫表移動到數(shù)據(jù)回收站保存。對于誤操作或者需要恢復(fù)刪除的情況，可以對數(shù)據(jù)庫表進(jìn)行DROP操作后進(jìn)行快速“閃回”。數(shù)據(jù)回收站的數(shù)據(jù)會自動按照清理策略進(jìn)行清除，不會影響正常數(shù)據(jù)庫服務(wù)。彈性擴(kuò)容當(dāng)分布式數(shù)據(jù)庫的負(fù)載不斷增加，或出現(xiàn)短期的業(yè)務(wù)浪涌，可以使用彈性擴(kuò)容功能對計算節(jié)點和存儲節(jié)點進(jìn)行擴(kuò)容，保障數(shù)據(jù)庫服務(wù)平穩(wěn)運行。計算節(jié)點水平擴(kuò)容當(dāng)集群的處理能力不足的時候，分布式數(shù)據(jù)庫支持在線增加計算節(jié)點，擴(kuò)展服務(wù)能力。同時，當(dāng)集群的計算

52、節(jié)點資源利用率較低時， 支持降低集群規(guī)模，減少計算節(jié)點數(shù)量，降低服務(wù)能力，提供服務(wù)能力彈性擴(kuò)展能力。由于在分布式數(shù)據(jù)庫系統(tǒng)中計算節(jié)點往往被設(shè)計為無狀態(tài)，通過新增或減少計算節(jié)點數(shù)量，并在配置節(jié)點中進(jìn)行相關(guān)元數(shù)據(jù)的更新即可完成計算節(jié)點的調(diào)整。存儲節(jié)點水平擴(kuò)容存儲節(jié)點水平擴(kuò)展通過增加存儲節(jié)點線性提升集群整體容量和吞吐性能，分布式數(shù)據(jù)庫的控制臺可以發(fā)起擴(kuò)容操作。以百度分布式數(shù)據(jù)庫為例，該操作主要分成四個步驟：1）創(chuàng)建新的存儲節(jié)點；2） 重新分布數(shù)據(jù)，并保持新節(jié)點和原節(jié)點數(shù)據(jù)實時同步；3）變更計算節(jié)點拓?fù)?，切換流量到新節(jié)點；4）清理原節(jié)點上的數(shù)據(jù)。在整體擴(kuò)容過程中，第三步會對業(yè)務(wù)有秒級的連接閃斷（一般應(yīng)

53、用層具有重連機(jī)制），因此分布式數(shù)據(jù)庫往往提供手動觸發(fā)第三步切換操作，運維人員可選擇業(yè)務(wù)低峰期完成切換。來源：北京百度網(wǎng)訊科技有限公司圖 13 存儲節(jié)點水平擴(kuò)展示意圖四、分布式數(shù)據(jù)庫容災(zāi)方案分布式數(shù)據(jù)庫容災(zāi)設(shè)計核心思想是就是充分利用分布式多副本數(shù)據(jù)一致性協(xié)議原理，并結(jié)合各種意外情況的具體特點，找到對應(yīng)的解決方案。及時發(fā)現(xiàn)故障，準(zhǔn)確分析故障原因在分布式數(shù)據(jù)庫容災(zāi)過程中的關(guān)鍵。集群中任何節(jié)點的軟硬件故障，或者任何節(jié)點之間的網(wǎng)絡(luò)連接故障，都可能影響集群的正常工作。由于其天然的復(fù)雜性，這個環(huán)境發(fā)生故障的幾率并不低，因此分布式數(shù)據(jù)庫系統(tǒng)需要將節(jié)點軟硬件故障和網(wǎng)絡(luò)故障當(dāng)作常見情況來處理，而不是當(dāng)作極低概率的

54、事件來處理。下文從節(jié)點故障、網(wǎng)絡(luò)故障、數(shù)據(jù)中心故障等維度重點介紹數(shù)據(jù)庫容災(zāi)應(yīng)對方案。(一)節(jié)點故障為了能描述系統(tǒng)容災(zāi)的過程，下面先對分布式數(shù)據(jù)庫的常見節(jié)點故障處理過程進(jìn)行介紹。計算節(jié)點故障分布式數(shù)據(jù)庫的計算節(jié)點多采用多實例部署，且自身不維持狀態(tài)。所以當(dāng)一個計算節(jié)點故障后，負(fù)載均衡通過健康檢查識別故障，自動 把請求分發(fā)到其他的計算節(jié)點上。來源：北京百度網(wǎng)訊科技有限公司圖 14 計算節(jié)點故障轉(zhuǎn)移切換示意圖待該節(jié)點自愈恢復(fù)后，負(fù)載均衡檢測到節(jié)點正常服務(wù)，會自動將請求重新均衡到該計算節(jié)點上。存儲節(jié)點主庫故障當(dāng)分布式數(shù)據(jù)庫的存儲節(jié)點集群出現(xiàn)主庫故障，集群的健康檢查 模塊會監(jiān)測到主庫故障，并通過多次探測確

55、認(rèn)故障。如果主庫故障確 認(rèn)，系統(tǒng)會控制存儲節(jié)點集群進(jìn)行主從切換，將一個從庫節(jié)點選舉為 新的主庫節(jié)點，并調(diào)整集群的主從同步關(guān)系。同時集群拓?fù)涞脑獢?shù)據(jù) 會進(jìn)行更新，推送到集群的各節(jié)點，包括查詢路由相關(guān)信息。這樣應(yīng) 用層的寫操作會發(fā)送到新的主庫。此時由于存在一個故障的副本節(jié)點， 根據(jù)集群的副本策略和恢復(fù)機(jī)制，恢復(fù)系統(tǒng)會觸發(fā)一個恢復(fù)任務(wù)，重新恢復(fù)一個新的從庫節(jié)點加入集群。來源：北京百度網(wǎng)訊科技有限公司圖 15 主庫節(jié)點故障轉(zhuǎn)移切換示意圖存儲節(jié)點從庫故障當(dāng)分布式集群的一組主從出現(xiàn)從庫節(jié)點故障，集群的健康檢查模塊會監(jiān)測到從庫故障，并通過多次探測來確認(rèn)故障。如果確認(rèn)從庫故障，系統(tǒng)會將該從庫進(jìn)行下線處理。同時

56、集群拓?fù)涞脑獢?shù)據(jù)會進(jìn)行更新，將該故障的從庫節(jié)點從集群信息中刪除，并推送到集群的各節(jié)點進(jìn)行更新。查詢路由相關(guān)的信息更新后，應(yīng)用層的讀操作不再發(fā)送到故障的從庫。此時由于存在一個故障的副本節(jié)點，根據(jù)集群的副本策略和恢復(fù)機(jī)制，系統(tǒng)的恢復(fù)系統(tǒng)會觸發(fā)一個恢復(fù)任務(wù)，重新恢復(fù)一個新的從庫節(jié)點加入集群。來源：北京百度網(wǎng)訊科技有限公司圖 16 從庫節(jié)點故障轉(zhuǎn)移切換示意圖(二)網(wǎng)絡(luò)故障對查詢的影響專線網(wǎng)絡(luò)抖動異常一般會帶來延時和丟包。GaiaDB-X集群的計算服務(wù)節(jié)點、存儲服務(wù)節(jié)點、管控節(jié)點之間的通訊都有完備的超時重試機(jī)制，少量的延時丟包不會影響查詢性能，跨專線的主從延時會增大，待網(wǎng)絡(luò)質(zhì)量恢復(fù)后即恢復(fù)正常。對寫入的

57、影響采用分組半同步的集群，網(wǎng)絡(luò)延時和丟包可能會造成同步延時甚至同步中斷重連，影響寫操作提交，導(dǎo)致部分事務(wù)提交失敗。一般來說，分組半同步有兩種應(yīng)對策略：一是支持配置同步退化超時時間，即延時超過一定時間后強(qiáng)同步退化為異步同步，可以減少鏈路異常對應(yīng)用寫入操作的影響，但同步退化后降級為異步同步，主從數(shù)據(jù)的強(qiáng)一致性已經(jīng)不能保障。此時如果網(wǎng)絡(luò)抖動蔓延成網(wǎng)絡(luò)中斷故障，出現(xiàn)存儲節(jié)點集群切換后會出現(xiàn)數(shù)據(jù)丟失，即RPO0。二是應(yīng)用需要最大程度保障數(shù)據(jù)一致性，由于網(wǎng)絡(luò)抖動情況復(fù)雜， 所以采用犧牲這段異常時間段的寫入功能可用性，保持強(qiáng)同步策略。所有寫入全部會被網(wǎng)絡(luò)異常阻塞，等待人工處理或者網(wǎng)絡(luò)恢復(fù)；實際 情況應(yīng)該根據(jù)

58、數(shù)據(jù)庫的業(yè)務(wù)要求采用不同的策略配置。(三)同城雙活生產(chǎn)中心災(zāi)難以同城雙活容災(zāi)架構(gòu)為例，此處介紹遇到機(jī)房級災(zāi)難情況下系統(tǒng)的應(yīng)對措施。當(dāng)生產(chǎn)中心機(jī)房出現(xiàn)嚴(yán)重災(zāi)難，導(dǎo)致大面積服務(wù)器和網(wǎng)絡(luò)故障。這時災(zāi)備中心的數(shù)據(jù)庫集群會監(jiān)測到生產(chǎn)中心的計算節(jié)點和存儲節(jié)點不可用，開始進(jìn)行容災(zāi)應(yīng)急處理。首先系統(tǒng)會對生產(chǎn)中心的計算節(jié)點進(jìn)行下線處理。由于生產(chǎn)中心的計算節(jié)點已經(jīng)全部不可訪問，系統(tǒng)會在元數(shù)據(jù)中將所有異常節(jié)點進(jìn)行剔除，并調(diào)整負(fù)載均衡配置，生產(chǎn)中心的所有查詢流量都只會發(fā)送到容災(zāi)中心的計算節(jié)點。同時系統(tǒng)對生產(chǎn)中心的存儲節(jié)點進(jìn)行下線處理。對于主庫在生產(chǎn)中心的集群，按照存儲節(jié)點主庫故障的處理流程進(jìn)行自動主從切換，將災(zāi)備中心

59、的從庫切換為主庫；對于主庫在災(zāi)備中心的集群，則按照存儲節(jié)點從庫故障的處理流程進(jìn)行節(jié)點下線。調(diào)整完成后更新集群元數(shù)據(jù)，所有存活的計算節(jié)點都會調(diào)整路由，將讀寫操作發(fā)送到新的容災(zāi)機(jī)房的存儲節(jié)點集群；最后根據(jù)容災(zāi)策略，系統(tǒng)會對復(fù)本率不足的主從集群補(bǔ)充從庫節(jié)點。整個容災(zāi)切換的處理示意圖如下：來源：北京百度網(wǎng)訊科技有限公司圖 17 同城雙活生產(chǎn)中心故障轉(zhuǎn)移切換示意圖此時容災(zāi)中心的負(fù)載均衡入口可以承載全流量的業(yè)務(wù)壓力，業(yè)務(wù)系統(tǒng)可自動或手動將流量全部轉(zhuǎn)移到災(zāi)備中心的數(shù)據(jù)庫集群。以一個四分片的分布式數(shù)據(jù)庫為例，主從切換后，分片拓?fù)湔{(diào)整如下（不包括補(bǔ)充副本）：來源：北京百度網(wǎng)訊科技有限公司圖 18 主從切換后分片

60、拓?fù)湔{(diào)整示意圖在同城雙活的容災(zāi)架構(gòu)下，對分布式數(shù)據(jù)庫容災(zāi)指標(biāo)的特性進(jìn)行分析。數(shù)據(jù)庫服務(wù) RTO數(shù)據(jù)庫服務(wù)的主要節(jié)點是計算節(jié)點和存儲節(jié)點。下面針對兩種節(jié)點的故障恢復(fù)進(jìn)行分析。計算服務(wù)節(jié)點一般采用多實例部署，節(jié)點本身不保存數(shù)據(jù)和狀態(tài)。通過負(fù)載均衡設(shè)備進(jìn)行流量均衡；當(dāng)一個計算節(jié)點發(fā)生故障后，往往 可以在秒級內(nèi)完成節(jié)點的故障轉(zhuǎn)移。落到該故障節(jié)點的應(yīng)用訪問一般 重試后即可恢復(fù)。存儲服務(wù)節(jié)點一般采用多分片和多副本的模式組建集群。出現(xiàn)存儲節(jié)點故障情況下，數(shù)據(jù)庫服務(wù)完成恢復(fù)時間包括四部分：集群故障監(jiān)測時間分布式數(shù)據(jù)庫采用多重監(jiān)測機(jī)制來保障故障感知的準(zhǔn)確性：節(jié)點監(jiān)測：存儲節(jié)點實例的可用性監(jiān)測（服務(wù)進(jìn)程狀態(tài)、內(nèi)存