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

1、一、容災(zāi)備份概述容災(zāi)備份簡稱“災(zāi)備”，是指利用科學的技術(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ù)性的目標，備份是為了應(yīng)對災(zāi)難來臨時造成的數(shù)據(jù)丟失問題。(一)容災(zāi)備份基礎(chǔ)介紹災(zāi)備由來及定義災(zāi)備行業(yè)起源于20世紀70年代的美國費城。1979年，SunGard公司在費城建立了全世界第一個災(zāi)備中心，當時人們關(guān)注的重點是企業(yè)的數(shù)據(jù)備份和系統(tǒng)備份。后來，IT備份發(fā)展到了災(zāi)難恢復(fù)規(guī)劃（DRP），在IT備份中加入了災(zāi)難恢復(fù)預(yù)案、資源需求、災(zāi)備中心管理，形成了對生產(chǎn)運行中心的保障概念。再后來，人們把

2、災(zāi)難恢復(fù)從IT角度逐漸轉(zhuǎn)向了業(yè)務(wù)的角度，用業(yè)務(wù)來衡量災(zāi)備目標，即哪些業(yè)務(wù)最重要，哪些業(yè)務(wù)可容忍的恢復(fù)時間最短。隨著企業(yè)規(guī)模擴展及信息系統(tǒng)的應(yīng)用范圍日益擴大，信息系統(tǒng)在企業(yè)運營過程中的角色愈發(fā)重要，為防范因為各種因素企業(yè)數(shù)據(jù)遭到毀壞，如地震、火災(zāi)、恐怖襲擊等，異地災(zāi)備建設(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攻擊，導致數(shù)據(jù)庫寫入鎖定，網(wǎng)站出現(xiàn)不穩(wěn)定和宕機。信息安全管理問題升級失敗、權(quán)限管理混亂20

3、18年4月，英國TSB銀行系統(tǒng)升級嚴重混亂。災(zāi)害類事件地震、洪災(zāi)、火災(zāi)2014年4月，三星位于首爾郊區(qū)的果川的數(shù)據(jù)中心發(fā)生火災(zāi)，導致三星服務(wù)宕機。來源：公開資料整理根據(jù)研究表明 HYPERLINK l _bookmark0 1，在以上各種導致系統(tǒng)故障的原因中，其占比分 別為：約40%的系統(tǒng)故障由操作人員失誤引起，約40%的系統(tǒng)故障由 應(yīng)用軟件的問題所引起，約20%的系統(tǒng)故障由設(shè)備的物理原因引起，如硬件失效、掉電等。綜上，系統(tǒng)故障導致業(yè)務(wù)下線的主要原因在于 人為操作失誤或應(yīng)用軟件問題，而自然災(zāi)難引發(fā)的業(yè)務(wù)下線概率較小。容災(zāi)定義及分類容災(zāi)，即災(zāi)難發(fā)生時，在保證生產(chǎn)系統(tǒng)數(shù)據(jù)盡量少丟失的情況下，保持生

4、產(chǎn)系統(tǒng)業(yè)務(wù)的不間斷運行。容災(zāi)技術(shù)是信息系統(tǒng)的高可用性技術(shù)的一個組成部分。容災(zāi)方式根據(jù)容災(zāi)距離和保護等級存在兩種分類方式。按容災(zāi)距離劃分按照容災(zāi)距離分類，容災(zāi)可分為本地容災(zāi)和異地容災(zāi)。本地容災(zāi)一般指主機集群，當某臺主機發(fā)生故障，其它主機可以12021 中國災(zāi)備行業(yè)白皮書，英方研究院。代替該主機，繼續(xù)正常對外提供服務(wù)。通常可以通過共享存儲或雙機 雙柜的方式實現(xiàn)本地容災(zāi)，其中多以共享存儲為主。共享存儲由活動 主節(jié)點、不活動備節(jié)點和共享存儲三部分組成。其中兩臺計算資源節(jié) 點提供主備角色服務(wù)，通過SAN網(wǎng)絡(luò)附加型存儲作為數(shù)據(jù)存儲的介質(zhì)。主備節(jié)點共享一份存儲，一旦主節(jié)點宕機，備節(jié)點可基于共享存儲實 現(xiàn)業(yè)務(wù)

5、的接管。共享存儲的短板在于遠距離高可用接管成本較高，存 在較大存儲故障風險，且只支持一對一架構(gòu)。異地容災(zāi)是指在與生產(chǎn)機房一定距離的異地建立與生產(chǎn)機房類 似的備份中心，并采用特定的技術(shù)將生產(chǎn)中心的數(shù)據(jù)傳輸?shù)絺浞葜行摹鹘y(tǒng)異地容災(zāi)通過磁盤或磁帶備份手段，對本地關(guān)鍵數(shù)據(jù)進行備份，然后運輸至生產(chǎn)中心之外的地方進行保存，災(zāi)難發(fā)生后，可通過磁盤 或磁帶實現(xiàn)系統(tǒng)和數(shù)據(jù)的恢復(fù)。這種手段成本低、易操作，但是當存 儲數(shù)據(jù)大規(guī)模增加時，存儲介質(zhì)管理將成為難以解決的問題?，F(xiàn)多采 用網(wǎng)絡(luò)傳輸?shù)姆绞竭M行異地容災(zāi)。按保護級別劃分按照保護級別，容災(zāi)系統(tǒng)可分為數(shù)據(jù)級容災(zāi)、應(yīng)用級容災(zāi)和業(yè)務(wù)級容災(zāi)。數(shù)據(jù)級容災(zāi)是最基礎(chǔ)的手段，指通過

6、建立異地容災(zāi)中心，進行數(shù)據(jù)的遠程備份，發(fā)生災(zāi)難時應(yīng)用會中斷。這種級別的容災(zāi)方案實施相對簡單、資源投入和后期運維成本低，但系統(tǒng)恢復(fù)速度較慢，業(yè)務(wù)恢復(fù)難度高。應(yīng)用級容災(zāi)主要針對關(guān)鍵應(yīng)用進行的容災(zāi)方案，應(yīng)用級容災(zāi)是建立在數(shù)據(jù)級容災(zāi)基礎(chǔ)上，對應(yīng)用系統(tǒng)進行實時復(fù)制，即在備份站點構(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ǔ)之上，

7、還需要考慮IT系統(tǒng)之外的業(yè)務(wù)因素。如發(fā)生重大災(zāi)難時，用戶的辦公場所可能會被損壞，除了恢復(fù)原來的數(shù)據(jù)外，還需要工作人員在備份的工作場所能夠正常地開展業(yè)務(wù)。備份定義及分類備份是指數(shù)據(jù)或系統(tǒng)的備份，它是容災(zāi)的基礎(chǔ)，是指為防止系統(tǒng)出現(xiàn)操作失誤或故障導致的數(shù)據(jù)丟失，而將全部或部分數(shù)據(jù)集合從應(yīng)用主機的硬盤或陣列復(fù)制到其它存儲介質(zhì)的過程，數(shù)據(jù)庫的備份與恢復(fù)通?；跀?shù)據(jù)庫日志文件進行操作。備份方式根據(jù)備份數(shù)據(jù)量、備份頻率和備份對象等多種分類方式。按照備份數(shù)據(jù)量，備份可分為全量備份、增量備份和差異備份。全量備份是指用存儲介質(zhì)對整個數(shù)據(jù)及系統(tǒng)進行完全備份。這種備份方式易理解、易恢復(fù)；短板是在備份數(shù)據(jù)中有大量的重復(fù)

8、數(shù)據(jù)，由于需要備份的數(shù)據(jù)量相當大，因此備份時間較長。增量備份是指備份自上一次備份（包含全量備份、差異備份、增量備份）之后有變化的數(shù)據(jù)。增量備份過程中，只備份有標記的選中的文件和文件夾。這種備份的優(yōu)點是重復(fù)數(shù)據(jù)少，即節(jié)省存儲空間又縮短了備份時間。差異備份是指備份上一次全量備份之后有變化的數(shù)據(jù)，差異備份后不標記為已備份文件，進行恢復(fù)時，只需對第一次全量備份和最后一次差異備份進行恢復(fù)。增量備份與差異備份的差異是，增量備份判斷數(shù)據(jù)更新標準是依據(jù)上一次備份檢查點，而差異備份一定是依據(jù)全量備份檢查點。如沒有全量備份，就沒有差異備份。差異備份的主要目的是限制完全恢復(fù)時使用的介質(zhì)數(shù)量。表 2 備份類型及差異備

9、份類型原理優(yōu)點缺點全量備份對備份集合所有數(shù)據(jù)進行備份完全恢復(fù)系統(tǒng)需要的時間最短費時，如果文件不頻繁更改，備份內(nèi)容幾乎完全相同增量備份對上次備份后改變的數(shù)據(jù)進行備份存儲的數(shù)據(jù)最少，備份速度最快完全恢復(fù)系統(tǒng)需要時間比全量或差異備份長差異備份對自上次全量備份后改變的數(shù)據(jù)進行備份恢復(fù)時僅需要最新全量備份和相應(yīng)的差異備份，速度比全量備份快完全恢復(fù)系統(tǒng)需要時間比全量備份長，如果大量數(shù)據(jù)發(fā)生變化，備份所需時間長于增量備份來源：2021中國災(zāi)備行業(yè)白皮書，英方研究院按照備份頻率，備份可以分為定時備份和實時備份。定時備份是指有時間間隔的數(shù)據(jù)備份方式，比如一小時一次，一天一次，定時備份無法保證數(shù)據(jù)零丟失。實時備份

10、是指無時間間隔的數(shù)據(jù)備份方式，通過實時數(shù)據(jù)復(fù)制，保證主備兩端的數(shù)據(jù)讀寫一致，確保數(shù)據(jù)零丟失。按照備份對象，備份可以分為字節(jié)級備份、塊級備份和文件級備份。字節(jié)級備份是指以字節(jié)級變量為基本單位，通過捕獲生產(chǎn)系統(tǒng)數(shù)據(jù)的變化，并將變化數(shù)據(jù)實時傳輸?shù)絺涠?。塊級備份是指以磁盤塊為基本單位，將數(shù)據(jù)從源端復(fù)制到備端，即每次備份數(shù)據(jù)以一個扇區(qū)或 多個連續(xù)扇區(qū)為單位來進行備份。文件級備份是指以文件為單位，將 數(shù)據(jù)以文件的形式讀出，通過文件系統(tǒng)接口調(diào)用備份到另一個介質(zhì)上。此外，根據(jù)數(shù)據(jù)備份時服務(wù)器是否停機可分為冷備和熱備，按照數(shù)據(jù) 存儲介質(zhì)之間的距離又分為本地備份和異地備份。容災(zāi)與備份的區(qū)別備份是容災(zāi)的基石，其目的

11、是為了系統(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ù)據(jù)異步復(fù)制的間隔內(nèi)會 被刪除。這時需要從備份系統(tǒng)中取出最新備份，從而恢復(fù)被錯誤刪除 的信息。因此，容災(zāi)系統(tǒng)的建設(shè)不能替代備份系統(tǒng)的建設(shè)。災(zāi)難恢復(fù)衡量指標評估一個災(zāi)備系統(tǒng)可靠性的兩個重要指標為恢復(fù)時間目標（Recovery Time Objective，以下簡稱“RTO”）與恢復(fù)點目標（Recovery Point Objective，以下

12、簡稱“RPO”）。RTO是恢復(fù)時間目標，指災(zāi)難發(fā)生后，從系統(tǒng)宕機導致業(yè)務(wù)停頓開始，到系統(tǒng)恢復(fù)至可以支持業(yè)務(wù)部門運作，業(yè)務(wù)恢復(fù)運營之時，此兩點之間的時間，RTO可簡單地描述為企業(yè)能容忍的恢復(fù)時間。根據(jù)金融行業(yè)標準規(guī)定 HYPERLINK l _bookmark1 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ù)要求，中國人民銀行。少達到該標準中規(guī)定的4級以上，其中4級RTO30分鐘、5級15分鐘，6級1分鐘。RPO是恢復(fù)點目標，指災(zāi)難發(fā)生后，業(yè)務(wù)系統(tǒng)所能容忍的最大數(shù)據(jù)丟失量，它是衡量企業(yè)在發(fā)生災(zāi)難后會丟失多少生產(chǎn)數(shù)據(jù)的指標。根據(jù)上

13、述金融行業(yè)標準，應(yīng)用于金融領(lǐng)域的分布式事務(wù)數(shù)據(jù)庫RPO要求均為0。RTO與RPO的確定必須在進行風險分析和業(yè)務(wù)影響分析后根據(jù)不同的業(yè)務(wù)需求確定，不同企業(yè)統(tǒng)一業(yè)務(wù)，需求也會有所不同。最理想的情況是兩個指標都為零。(二)金融機構(gòu)災(zāi)備現(xiàn)狀與要求金融機構(gòu)災(zāi)備現(xiàn)狀與需求金融機構(gòu)對數(shù)據(jù)零丟失和業(yè)務(wù)連續(xù)性要求在各行各業(yè)要求最高。以銀行為例，銀行信息系統(tǒng)架構(gòu)最為嚴格，要求采用兩地三中心或主備等多種模式構(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)端物理機與虛擬機并存，災(zāi)備端以虛擬機為主的配置 H

14、YPERLINK l _bookmark2 3。綜合各類金融機構(gòu)，主要需求包括但不限于：1）海量數(shù)據(jù)備份、實時復(fù)制；2）數(shù)據(jù)庫數(shù)據(jù)跨平臺遷移和讀寫分離；3）主備業(yè)務(wù)系統(tǒng)應(yīng)用高可用；4）提升災(zāi)備中心智能運維水平；5）大規(guī)模災(zāi)備系統(tǒng)可用性驗證的自動化能力等。32021 中國災(zāi)備行業(yè)白皮書，英方研究院。金融機構(gòu)容災(zāi)要求金融機構(gòu)分類較多，不同行業(yè)發(fā)布的法律法規(guī)各不相同，以要求最為嚴格的銀行和證券行業(yè)為代表，以下列舉相關(guān)重要的現(xiàn)行標準規(guī)范：證券期貨業(yè)數(shù)據(jù)分類分級指引自2018年9月27日同日公布實施，數(shù)據(jù)分類是按照GB/T 10113-2003 中的線分類法和GB/T 22240-2008中的定級方法為

15、基礎(chǔ)進行分類的。目的是在數(shù)據(jù)分類的基礎(chǔ)上，對已分類數(shù)據(jù)按照數(shù)據(jù)泄露或損壞造成的影響進行分級，形成統(tǒng)一的分類分級方法。同時，在數(shù)據(jù)用語的使用過程中，也強調(diào)予以統(tǒng)一。除上述監(jiān)管要求外，證券行業(yè)信息安全監(jiān)管還有包括但不限于：證券期貨業(yè)信息安全保障管理辦法；證券期貨業(yè)信息安全事件報告與調(diào)查處理方法；證券期貨經(jīng)營機構(gòu)信息系統(tǒng)備份能力標準等。銀行業(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)用的可行性進行驗證測試，并記

16、錄和保存驗證測試的結(jié)果；最后，應(yīng)制定災(zāi)難備份系統(tǒng)集成與測試計劃并組織實施，通過技術(shù)和業(yè)務(wù)測試，確認災(zāi)難備份系統(tǒng)的功能和性能達到設(shè)計指標要求。銀行業(yè)信息安全監(jiān)管還有包括但不限于：商業(yè)銀行業(yè)數(shù)據(jù)中心監(jiān)管指引；網(wǎng)上銀行業(yè)務(wù)連續(xù)性監(jiān)控指引；關(guān)于進一步加強銀行業(yè)金融機構(gòu)信息安全保障工作的指導意見等。金融領(lǐng)域確保業(yè)務(wù)連續(xù)性是重中之重，它關(guān)系到廣大投資者和用戶日常的投資行為和經(jīng)濟消費行為，任何由于數(shù)據(jù)庫導致的非計劃性停機，都可能引發(fā)巨大的經(jīng)濟損失和非經(jīng)濟性影響。127.8150151.8177.4200207.8市場（億人民幣）(三)災(zāi)備市場與行業(yè)趨勢350 329.1300280.3250240.5201

17、0 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021E 2022E時間（年）50060.355.149.888.773.9100106.5數(shù)據(jù)來源：2021中國災(zāi)備行業(yè)白皮書，英方研究院圖 12010-2022 中國災(zāi)備行業(yè)市場規(guī)模智研咨詢報告 HYPERLINK l _bookmark3 4顯示，中國災(zāi)備行業(yè)市場規(guī)模從2010年的49.8億人民幣，增長至2018年近180億人民幣，預(yù)計至2022年中國災(zāi)備行業(yè)市場規(guī)模可達300億以上。前瞻產(chǎn)業(yè)研究院的報告重點提到云災(zāi)備將成為未來趨勢，云災(zāi)備市場規(guī)模從2013年的1億元，快速增長到20

18、1842017-2022 年中國災(zāi)備行業(yè)深度研究及市場前景預(yù)測報告年的10億元，預(yù)計到2022年規(guī)模達70億元。Gartner預(yù)計到2021年，使用備份而非歸檔方式來管理企業(yè)長期的比例將由2017年的30%升至50%。國際災(zāi)備市場發(fā)展同樣強勁，根據(jù)DataCore的2018年報告 HYPERLINK l _bookmark4 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)用場景從同機房本地備份容災(zāi)，向同城、異

19、地及云端等更宏大的場景延伸；災(zāi)備技術(shù)從傳統(tǒng)的存儲復(fù)制技術(shù)，延伸到基于主機、操作系統(tǒng)、數(shù)據(jù)庫、文件和網(wǎng)絡(luò)等五大數(shù)據(jù)復(fù)制技術(shù)。災(zāi)備產(chǎn)品也正在不斷拓展邊界，涵蓋傳統(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)中

20、心的多個不同可用區(qū)多實例部署，實現(xiàn)數(shù)據(jù)庫服務(wù)高可用。不同可用區(qū)的數(shù)據(jù)庫均能向5The State of Software-Defined Storage, Hyperconverged and Cloud Storage應(yīng)用系統(tǒng)提供數(shù)據(jù)庫訪問服務(wù)。來源：北京百度網(wǎng)訊科技有限公司圖 2 單中心容災(zāi)部署架構(gòu)示意圖基于數(shù)據(jù)庫的高可用機制，可以抵御部分節(jié)點甚至機房可用區(qū)整體故障，仍然保持數(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ù)壓力

21、。數(shù)據(jù)庫系統(tǒng)在生產(chǎn)中心和災(zāi)備中心都需要冗余部署滿足系統(tǒng)正常運行的全部組件，并配備滿足全量數(shù)據(jù)存儲和訪問壓力的存儲和計算資源。正常情況下，只有生產(chǎn)中心投入運行，災(zāi)備中心處于在線待機狀態(tài)。當數(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ù)同步方式，可以采用強同步機制或異步同步機制。這取決于根據(jù)業(yè)務(wù)對數(shù)據(jù)一致性的要求，同時也受到數(shù)據(jù)中心距離帶來的網(wǎng)絡(luò)延時限制。當數(shù)據(jù)中心和災(zāi)備中心在同城距離較近，網(wǎng)絡(luò)

22、延時較小，通常選擇強同步，可稱為同城互備；當數(shù)據(jù)中心間距離較遠，跨地區(qū)進行傳輸?shù)木W(wǎng)絡(luò)延時較大，可稱為異地互備。(三)同城雙活同城雙活是雙活技術(shù)與同城災(zāi)備中心模式結(jié)合的一種主流容災(zāi)架構(gòu)。業(yè)務(wù)系統(tǒng)可以同時通過生產(chǎn)中心和災(zāi)備中心進行訪問，無需指定特定的訪問規(guī)則。數(shù)據(jù)庫架構(gòu)同時兼?zhèn)洚惖鼗淠Ｊ降呢撦d均衡和故障自動切換能力，且由于處于同城較近距離，兩個數(shù)據(jù)中心的存儲節(jié)點可以保持數(shù)據(jù)強一致。當其中一個中心發(fā)生災(zāi)難時，通過接入前端的負載均衡調(diào)整，可將全流量輸入對等的災(zāi)備中心；數(shù)據(jù)庫同時自動進行切換，災(zāi)備中心的數(shù)據(jù)庫集群承載全部查詢請求。同城雙活的部署示意圖如下：來源：北京百度網(wǎng)訊科技有限公司圖 4 同城雙活

23、容災(zāi)部署架構(gòu)示意圖基于數(shù)據(jù)分布式架構(gòu)可以對應(yīng)用層提供透明的雙活能力。以一個四分片的數(shù)據(jù)表為例，分片數(shù)據(jù)可以均勻分布在兩個中心的數(shù)據(jù)庫存儲節(jié)點中：來源：北京百度網(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)下，再增加一個遠距離的容災(zāi)中心，可實現(xiàn)兩地三中心的容災(zāi)架構(gòu)。該架構(gòu)在同城容災(zāi)方案的基礎(chǔ)上，獲得了對地震、颶風等區(qū)域級災(zāi)難的抵御能力。由于異地災(zāi)備中心距離較遠，所以數(shù)據(jù)同步一般考

24、慮使用異步模式，可基于數(shù)據(jù)庫異步同步功能實現(xiàn)，或者在應(yīng)用層使用消息隊列等組件進行業(yè)務(wù)數(shù)據(jù)異步同步，進而實現(xiàn)遠距離異地機房的數(shù)據(jù)最終一致性。來源：北京百度網(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)細節(jié)。一套完整的數(shù)據(jù)庫容災(zāi)技術(shù)既要有采用數(shù)據(jù)備份保護和恢復(fù)數(shù)據(jù)的功能，也要有保證數(shù)據(jù)安全、正確、高效傳輸?shù)墓δ埽瑫r還要有強大的應(yīng)激防護能力。(一)數(shù)據(jù)備份與恢復(fù)數(shù)據(jù)備份是以容災(zāi)為目的，為防止故障導致的數(shù)據(jù)丟失，而將全部或者部分數(shù)據(jù)復(fù)制到其他存

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

26、對數(shù)據(jù)庫的數(shù)據(jù)內(nèi)容進行備份的方式。這種模式的優(yōu)點是能靈活地選擇備份范圍，即可以選擇指定的庫表進行備份，還可以通過條件篩選備份內(nèi)容。邏輯備份的模式下往往通過讀取數(shù)據(jù)轉(zhuǎn)換為“insert into table ”一類SQL語句，需要額外的解析和轉(zhuǎn)換，同時還涉及大事務(wù)通過事務(wù)隔離性保障數(shù)據(jù)一致性，所以導致效率相對較低。數(shù)據(jù)恢復(fù)全量備份是基于時間點的數(shù)據(jù)庫鏡像，而增量備份是將此時間點擴展到持續(xù)的時間窗口。通過全量備份和增量備份，數(shù)據(jù)庫可以恢復(fù)備份覆蓋的時間范圍內(nèi)任意時間點的數(shù)據(jù)狀態(tài)。同時數(shù)據(jù)恢復(fù)也可指定恢復(fù)目標，將恢復(fù)范圍限制為部分庫表，可大幅降低恢復(fù)時間開銷。(二)數(shù)據(jù)同步與傳輸按照監(jiān)管要求，核心業(yè)

27、務(wù)系統(tǒng)生產(chǎn)中心的數(shù)據(jù)庫數(shù)據(jù)能實時同步傳輸?shù)疆惖氐臑?zāi)備中心。下面以MySQL數(shù)據(jù)庫場景為例，介紹幾種不同的同步傳輸技術(shù)，供數(shù)據(jù)庫容災(zāi)架構(gòu)規(guī)劃參考。主從復(fù)制MySQL主從復(fù)制 HYPERLINK l _bookmark5 6是一個異步的復(fù)制過程，主庫發(fā)送更新事件到從庫，從庫讀取更新記錄，并執(zhí)行更新記錄，使得從庫的內(nèi)容與主庫保持一致。每一組主從復(fù)制的連接，都由三個獨立的線程協(xié)作實現(xiàn)。在主庫上為每一個連接到主庫的從庫創(chuàng)建一個二進制日志( 以下簡稱 “binlog”)輸出線程。每一個發(fā)送給從庫的SQL事件或者數(shù)據(jù)變更事件，都會基于binlog傳輸給從庫。而每一個從庫都會為同步創(chuàng)建一個 I/O線程和一個S

28、QL線程。I/O線程連接到主庫并請求主庫發(fā)送binlog事件到從庫，讀取到的binlog會更新到本地中繼日志（以下簡稱 “relay-log”）文件。而SQL線程讀取到I/O線程寫到relay-log的更新事件后，在數(shù)據(jù)庫中進行執(zhí)行，從而完成數(shù)據(jù)從主庫到從庫的同步。半同步復(fù)制半同步復(fù)制是MySQL 5.5版本引入的機制 HYPERLINK l _bookmark6 7。半同步復(fù)制出現(xiàn)前，雖然異步復(fù)制可以滿足主從實例之間的數(shù)據(jù)同步要求，但如果主庫崩潰，將從庫提升為主庫時，原來的主庫上可能有一部分已經(jīng)提交的數(shù)據(jù)還沒有來得及被從庫接收，主從不一致將導致切換后的新主庫丟失這一部分數(shù)據(jù)。半同步復(fù)制改進了

29、事務(wù)提交的邏輯。客戶端在主庫上寫入一個事6MySQL 官方手冊：Replication7MySQL 官方手冊：Semisynchronous Replication務(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ù)在存儲

30、引擎內(nèi)部提交之前，必須要先收到從庫的應(yīng)答確認，否則不進行事務(wù)的最后提交，從而解決上述提到的幻讀問題。組復(fù)制MySQL在5.7版本正式推出組復(fù)制（MySQL Group Replication HYPERLINK l _bookmark7 8，以下簡稱“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ò)的要求

31、非常高。網(wǎng)絡(luò)延時和不穩(wěn)定會嚴重影響MGR集群的正常工作，所以多用在單數(shù)據(jù)中心的內(nèi)網(wǎng)環(huán)境中，對于主備和多活容災(zāi)架構(gòu)下異地同步的場景，存在一定的短板。8MySQL 官方手冊：Group Replication分組強同步半同步復(fù)制機制保障了主庫故障切換時事務(wù)數(shù)據(jù)能夠在至少一個從庫中持久化存儲，保證切換過程不丟失最新數(shù)據(jù)。隨著數(shù)據(jù)庫集群規(guī)模逐漸增大，同城和異地多機房災(zāi)備架構(gòu)對同步的要求也愈發(fā)提高。當跨多機房部署的集群出現(xiàn)大規(guī)模故障，例如機房故障或?qū)＞€故障時，主庫和完成接收binlog數(shù)據(jù)的從庫節(jié)點可能同時出現(xiàn)故障。因此在半同步的基礎(chǔ)上，出現(xiàn)了分組強同步機制。分組強同步機制能夠保證在跨機房的場景下仍然保

32、持高可用和強同步的能力。任何一個集群的從庫可以分成若干組，在每一組中，只要有一個從庫返回成功，則認為該組復(fù)制成功。當所有的組都復(fù)制成功，主庫的事務(wù)才能完成提交。分組強同步復(fù)制算法可以保證已經(jīng)提交成功事務(wù)的數(shù)據(jù)不丟失，修復(fù)了MySQL原生半同步可能丟失數(shù)據(jù)的隱患，確保在主庫發(fā)生故障情況下，不會因為二進制日志丟失導致從庫丟失數(shù)據(jù)，進一步提升了數(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ù)庫之間進行數(shù)據(jù)遷移、數(shù)據(jù)同步和數(shù)據(jù)訂閱。DTS 支持在業(yè)務(wù)不影響源數(shù)

33、據(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)備場景下也被作為異步同步的重要方案。來源：北京百度網(wǎng)訊科技有限公司圖 7 數(shù)據(jù)傳輸服務(wù)架構(gòu)示意圖(三)故障自動切換當分布式數(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)難而不可用，

34、數(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)中心。集中式架構(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)移目標。發(fā)生故障轉(zhuǎn)移時，數(shù)據(jù)庫通過一組

35、獨立的服務(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ǔ)資源 HYPERLINK l _bookmark8 9。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ù)庫 HYPE

36、RLINK l _bookmark9 10。分布式架構(gòu)分布式數(shù)據(jù)庫架構(gòu)由于進程、磁盤和服務(wù)器等故障，往往導致集群的少量節(jié)點實例不可用，應(yīng)對措施主要是通過冗余和副本節(jié)點進行替換止損，替換過程中可能出現(xiàn)主備切換或主從切換；對于交換機、路由器等網(wǎng)絡(luò)設(shè)備發(fā)生故障，除了導致部分節(jié)點實例不可用外，還可能出現(xiàn)集群分裂情況，因此分布式數(shù)據(jù)庫需要建立應(yīng)付各種類型和規(guī)9SQL Server 官方文檔Windows Server 故障轉(zhuǎn)移群集與 SQL Server10SQL Server 官方文檔什么是 Always On 可用性組？模故障的容災(zāi)能力。計算節(jié)點故障切換當其中一個計算節(jié)點出現(xiàn)故障，流量以秒級切換至其

37、他計算節(jié)點。整個切換過程對用戶透明，應(yīng)用代碼無需變更，應(yīng)用進程無需重啟。來源：北京百度網(wǎng)訊科技有限公司圖 8 計算節(jié)點故障切換示意圖計算節(jié)點自愈分為故障感知和故障處理兩部分。故障感知是指通過節(jié)點代理的定時任務(wù)定期執(zhí)行自愈監(jiān)控項采集任務(wù)，對計算節(jié)點的監(jiān)控指標進行采集，并上報至服務(wù)自愈模塊，該模塊對節(jié)點的監(jiān)控數(shù)據(jù)進行分析，對可能的故障信息進行定位和二次檢測，若確定為故障則發(fā)起故障處理任務(wù)。故障處理是指服務(wù)自愈模塊檢測到故障節(jié)點，任務(wù)調(diào)度模塊創(chuàng)建自愈任務(wù)，自動對故障節(jié)點進行恢復(fù)處理，處理完成后故障節(jié)點重新上線恢復(fù)正常服務(wù)。存儲節(jié)點故障切換分布式數(shù)據(jù)庫采用多副本保存數(shù)據(jù)，存儲節(jié)點通過多副本方式構(gòu)成集群

38、。最常見的集群模式是主從集群，即一個主節(jié)點負責寫入，并基于一定的一致性算法同步至其他從庫。當對外提供數(shù)據(jù)庫服務(wù)時，主庫承擔讀寫服務(wù)，從庫提供只讀服務(wù)。當主庫節(jié)點故障時，系統(tǒng)會自動發(fā)現(xiàn)并嘗試恢復(fù)主庫，如果主庫無法恢復(fù)則發(fā)起主從切換。來源：北京百度網(wǎng)訊科技有限公司圖 9 存儲節(jié)點故障切換示意圖切換協(xié)調(diào)模塊為切換核心模塊，負責存儲節(jié)點健康診斷、切換仲 裁與協(xié)調(diào)，并變更集群的拓撲信息。如上圖所示，數(shù)據(jù)庫實例的三個 節(jié)點代理構(gòu)成了切換的協(xié)調(diào)者。節(jié)點代理通過與決策集群通信獲取其 托管的集群元信息，并借助集群取得集群中其它節(jié)點代理的通訊方式。(四)分布式事務(wù)容災(zāi)金融類業(yè)務(wù)數(shù)據(jù)模型復(fù)雜度較高，往往需要多維度進

39、行數(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)能力的重要考量指標。百度分布式數(shù)據(jù)庫GaiaDB-X采用基于優(yōu)化的XA協(xié)議及兩階段提交算法實現(xiàn)分布式事務(wù)機制。其優(yōu)勢有：1）自研DMVCC HYPERLINK l _bookmar

40、k10 11算法，解決分布式全局讀一致性問題；2）解決MySQL原生XA在事務(wù)一致性和持久性上的缺陷；3）在宕機等故障場景下，能夠基于持久化的全局事務(wù)狀態(tài)對懸掛事務(wù)進行提交或回滾，保證分布式事務(wù)的容災(zāi)恢復(fù)能力；4）支持備份恢復(fù)的事務(wù)一致性、死鎖檢測等高級功能。來源：北京百度網(wǎng)訊科技有限公司圖 10GaiaDB-X 分布式事務(wù)機制示意圖11*DMVCC：Shao J, Yin B, Chen B, et al. Read Consistency in Distributed Database Based on DMVCCC IEEE, International Conference on Hi

41、gh PERFORMANCE Computing. IEEE, 2017:142-151.上圖為GaiaDB-X的分布式事務(wù)架構(gòu)，其中分布式事務(wù)處理器（Distributed Transaction Manager，以下簡稱“DTM”）負責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ù)的高可用能力。當分布式表進行備份和恢復(fù)時，如何保證恢復(fù)數(shù)據(jù)的一致性也是考

42、驗分布式數(shù)據(jù)庫的難題。GaiaDB-X實現(xiàn)了基于全局事務(wù)點的備份恢復(fù)機制。來源：北京百度網(wǎng)訊科技有限公司圖 11 基于全局事務(wù)點的備份恢復(fù)機制示意圖所有分片同時通過備庫上定時任務(wù)啟動備份任務(wù)獨立進行備份，根據(jù)備份結(jié)果獲取全局事務(wù)標識（Global Transaction ID，以下簡稱 “GTID”），并從主庫日志中解析得到備份快照點及對應(yīng)分片的全局事務(wù)信息，與備份數(shù)據(jù)一同備份。這樣基于快照點與全局事務(wù)信息的對應(yīng)關(guān)系，即可在備份恢復(fù)時保證各分片的全局事務(wù)一致性。(五)應(yīng)用應(yīng)激防護過載保護為了保障數(shù)據(jù)庫服務(wù)不受業(yè)務(wù)系統(tǒng)突發(fā)過量壓力影響，導致系統(tǒng)穩(wěn)定性下降，數(shù)據(jù)庫需要提供對請求流量進行控制的功能，

43、保障數(shù)據(jù)庫服務(wù)在極端應(yīng)用負載情況下仍能穩(wěn)定運行。當監(jiān)測到連接可用性下降時，會觸發(fā)進入限流模式，基于實時查詢量對主庫和從庫的訪問量進行限制。限制策略有連接數(shù)限制、查詢量限制和處理時間限制等。SQL 入侵防御SQL入侵防御是對用戶發(fā)送的SQL進行語法解析，過濾非法SQL的一種安全能力。數(shù)據(jù)庫產(chǎn)品一般通過中間件或基于計算節(jié)點集成防火墻功能，對非法SQL進行過濾、阻斷和報警，有效的預(yù)防SQL注入或惡意非法攻擊。對于不同SQL，防火墻采用攔截模式或告警模式進行處理：攔截模式是指當發(fā)現(xiàn)非法SQL時，防火墻會自動阻斷其執(zhí)行，并發(fā)送報警通知；告警模式是指當發(fā)現(xiàn)非法SQL時，防火墻會允許其繼續(xù)執(zhí)行，但會發(fā)送告警

44、通知?；赟QL入侵防御技術(shù)，數(shù)據(jù)庫可以有效識別和攔截外部的SQL攻擊行為，并記錄日志，供事后追查。例如各類SQL注入攻擊模式，包括脫庫、高危SQL等，SQL防火墻都能實現(xiàn)有效攔截。來源：北京百度網(wǎng)訊科技有限公司圖 12SQL 防火墻示意圖數(shù)據(jù)回滾在存儲限額范圍內(nèi)，數(shù)據(jù)庫將刪除的數(shù)據(jù)庫表移動到數(shù)據(jù)回收站保存。對于誤操作或者需要恢復(fù)刪除的情況，可以對數(shù)據(jù)庫表進行 DROP操作后進行快速“閃回”。數(shù)據(jù)回收站的數(shù)據(jù)會自動按照清理策略進行清除，不會影響正常數(shù)據(jù)庫服務(wù)。彈性擴容當分布式數(shù)據(jù)庫的負載不斷增加，或出現(xiàn)短期的業(yè)務(wù)浪涌，可以使用彈性擴容功能對計算節(jié)點和存儲節(jié)點進行擴容，保障數(shù)據(jù)庫服務(wù)平穩(wěn)運行。計

45、算節(jié)點水平擴容當集群的處理能力不足的時候，分布式數(shù)據(jù)庫支持在線增加計算節(jié)點，擴展服務(wù)能力。同時，當集群的計算節(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é)點水平擴展通過增加存儲節(jié)點線性提升集群整體容量和吞吐性能，分布式數(shù)據(jù)庫的控制臺可以發(fā)起擴容操作。以百度分布式數(shù)據(jù)庫為例，該操作主要分成四個步驟：1）創(chuàng)建新的存儲節(jié)點；2）重新分布數(shù)據(jù)，并保持新節(jié)點和原節(jié)點數(shù)據(jù)實時同步；3）變更計算節(jié)點

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

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

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

49、檢查模塊會監(jiān)測到從庫故障，并通過多次探測來確認故障。如果確認從庫故障，系統(tǒng)會將該從庫進行下線處理。同時集群拓撲的元數(shù)據(jù)會進行更新，將該故障的從庫節(jié)點從集群信息中刪除，并推送到集群的各節(jié)點進行更新。查詢路由相關(guān)的信息更新后，應(yīng)用層的讀操作不再發(fā)送到故障的從庫。此時由于存在一個故障的副本節(jié)點，根據(jù)集群的副本策略和恢復(fù)機制，系統(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é)點之間的通訊都有完備的超時

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

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

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

53、從切換后，分片拓撲調(diào)整如下（不包括補充副本）：來源：北京百度網(wǎng)訊科技有限公司圖 18 主從切換后分片拓撲調(diào)整示意圖在同城雙活的容災(zāi)架構(gòu)下，對分布式數(shù)據(jù)庫容災(zāi)指標的特性進行分析。數(shù)據(jù)庫服務(wù) RTO數(shù)據(jù)庫服務(wù)的主要節(jié)點是計算節(jié)點和存儲節(jié)點。下面針對兩種節(jié)點的故障恢復(fù)進行分析。計算服務(wù)節(jié)點一般采用多實例部署，節(jié)點本身不保存數(shù)據(jù)和狀態(tài)。通過負載均衡設(shè)備進行流量均衡；當一個計算節(jié)點發(fā)生故障后，往往 可以在秒級內(nèi)完成節(jié)點的故障轉(zhuǎn)移。落到該故障節(jié)點的應(yīng)用訪問一般 重試后即可恢復(fù)。存儲服務(wù)節(jié)點一般采用多分片和多副本的模式組建集群。出現(xiàn)存儲節(jié)點故障情況下，數(shù)據(jù)庫服務(wù)完成恢復(fù)時間包括四部分：集群故障監(jiān)測時間分布式

54、數(shù)據(jù)庫采用多重監(jiān)測機制來保障故障感知的準確性：節(jié)點監(jiān)測：存儲節(jié)點實例的可用性監(jiān)測（服務(wù)進程狀態(tài)、內(nèi)存使用情況、磁盤設(shè)備狀態(tài)）。單個存儲節(jié)點的心跳是定時檢測，當連續(xù)檢測到一定次數(shù)的異常心跳，即判斷節(jié)點故障。建議心跳連續(xù)驗證次數(shù)配置不能太低，否則容易出現(xiàn)誤切換；另外對于異地機房節(jié)點，建議增加連續(xù)驗證次數(shù)，以防線路抖動觸發(fā)誤切換；同步監(jiān)測：獲取集群各存儲節(jié)點的同步關(guān)系的信息數(shù)據(jù)。通過分析所有存儲節(jié)點的主從關(guān)系，驗證其組成的拓撲關(guān)系正確性。這種監(jiān)控不需要連續(xù)檢測，一次檢測即可發(fā)現(xiàn)集群異常；集群監(jiān)測：監(jiān)測存儲節(jié)點的存活和同步狀態(tài)，保障切換的最小集群規(guī)模并避免反復(fù)切換。建議連續(xù)多次監(jiān)測失敗才能確認異常。通

55、過多種監(jiān)測機制完成確認集群異常，建議通過配置測試各階段的合理重復(fù)檢測次數(shù)，使整體檢測時間保持在10至20秒合理范圍，過短的監(jiān)測時間容易出現(xiàn)誤感知導致誤切換。主從切換準備當存儲服務(wù)主庫節(jié)點異常時，需要啟動主從切換流程進行故障轉(zhuǎn)移。主從切換前，往往需要在仍然存活的副本中選舉一個新主庫，形成新集群拓撲。在新集群進行切換前，各存儲節(jié)點根據(jù)同步機制不同，可能存在數(shù)據(jù)不一致的情況。所以接下來需要等待所有節(jié)點完成數(shù)據(jù)交換補齊，將各節(jié)點數(shù)據(jù)同步到最新狀態(tài)。在一般情況下，所有節(jié)點不存在較高同步延時，數(shù)據(jù)補齊準備工作會在1至2秒內(nèi)完成，但對于負載很高的集群，主從之間會存在一定的同步延時，則切換準備時間會在幾秒到幾

56、十分鐘不等。造成較高同步延時的原因有：存在批量大事務(wù)執(zhí)行，例如批量導入和刪除任務(wù)，建議將任務(wù)放在業(yè)務(wù)低峰期或拆解為多批次小數(shù)據(jù)量執(zhí)行。有突較高業(yè)務(wù)壓力，建議對重點數(shù)據(jù)表進行分表拆分。主從切換節(jié)點全部完成同步后，所有存儲節(jié)點的數(shù)據(jù)一致，此時重新調(diào)整主從關(guān)系，切換一般秒級即可完成。集群路由調(diào)整完成切換后，配置節(jié)點中的集群拓撲結(jié)構(gòu)會進行相應(yīng)的調(diào)整，并同步到所有計算節(jié)點，時間與元數(shù)據(jù)同步周期有關(guān)，一般在數(shù)秒左右。正常情況下，基于分布式數(shù)據(jù)庫的多副本同步復(fù)制機制，在同步延時較小的集群上，RTO故障恢復(fù)時間應(yīng)該可以保持在30秒到1分鐘左右。數(shù)據(jù)庫服務(wù)RPO基于強同步機制的數(shù)據(jù)庫服務(wù)可以實現(xiàn)數(shù)據(jù)無丟失，即R

57、PO=0。實際的數(shù)據(jù)庫應(yīng)用場景中，RPO的能力取決于采用何種同步機制策略。如果應(yīng)用系統(tǒng)容忍丟失少量數(shù)據(jù)，則可以采用異步同步機制，這樣還 可以提高集群寫入性能，但RTO0；如果應(yīng)用系統(tǒng)嚴格要求數(shù)據(jù)完整 性，則可以采用強同步機制，雖然集群寫入性能會受到一定影響，但 能保證故障切換后不丟失數(shù)據(jù)，即RPO=0。一般來說，使用強同步后，事務(wù)提交的延時會增加大概一個集群節(jié)點網(wǎng)絡(luò)間往返時延 （Round-Trip Time，以下簡稱“RTT”）的最大值。以同城雙活容災(zāi)架構(gòu)為例，最大的RTT是兩個同城機房間的網(wǎng)絡(luò)交互延時，一般約為 1至2毫秒。即開啟強同步后，每個事務(wù)都會增加1至2毫秒的時間開銷。專線延時對查

58、詢的影響分布式數(shù)據(jù)庫的同城雙活容災(zāi)架構(gòu)下，數(shù)據(jù)是分布在兩個機房的。如果查詢請求所需的存儲服務(wù)節(jié)點不在當前機房，就需要一次跨專線 的訪問。與跨機房的強同步類似，一次交互也需要額外的1至2毫秒時 間開銷。減少跨機房查詢的有效方式是業(yè)務(wù)系統(tǒng)設(shè)計時就考慮分布式數(shù)據(jù)庫適配，采用單元化和服務(wù)化設(shè)計，可以將跨機房的查詢情況降低90%以上。如果業(yè)務(wù)系統(tǒng)沒有進行單元化改造，或者業(yè)務(wù)系統(tǒng)是單體架構(gòu)，采用數(shù)據(jù)分布式方式構(gòu)建系統(tǒng)，極端情況下跨庫訪問的概率可能會超過50%。(四)兩地三中心主區(qū)域災(zāi)難以兩地三中心容災(zāi)架構(gòu)為例，介紹遇到地理級災(zāi)難情況下系統(tǒng)的應(yīng)對措施。當出現(xiàn)城市級重大災(zāi)難，位于該城市的生產(chǎn)中心和災(zāi)備中心出現(xiàn)大面積的服務(wù)器和網(wǎng)絡(luò)故障，所有數(shù)據(jù)庫節(jié)點均受到影響。異地災(zāi)備中心的數(shù)據(jù)庫集群會監(jiān)測到生產(chǎn)中心和同城災(zāi)備中心的計算節(jié)點和存