華為云：機(jī)房失火還能拯救你的數(shù)據(jù)嗎？

相信很多人都有整理C盤的經(jīng)歷，C盤作為電腦的系統(tǒng)盤，系統(tǒng)運(yùn)行所需的關(guān)鍵數(shù)據(jù)都存儲(chǔ)在其中。但如果使用不當(dāng)，C盤就特別容易變紅，然后電腦變卡，惡性循環(huán)，最差的結(jié)局就是系統(tǒng)崩潰，所有數(shù)據(jù)丟失。

對于企業(yè)來說，數(shù)據(jù)存儲(chǔ)和管理更是關(guān)乎生存的大事。

如今的企業(yè)數(shù)據(jù)量大、數(shù)據(jù)來源多樣、數(shù)據(jù)形態(tài)復(fù)雜，原有的存儲(chǔ)模式已經(jīng)無法滿足需求，反而會(huì)加重存儲(chǔ)負(fù)擔(dān)。

所以，磨刀不誤砍柴工，你們企業(yè)的數(shù)據(jù)存儲(chǔ)做好了嗎？巧婦難為無米之炊，你們業(yè)務(wù)的瓶頸是不是可以從數(shù)據(jù)存儲(chǔ)管理的維度打破？

打好數(shù)據(jù)存儲(chǔ)的地基

從最早的穿孔卡片、關(guān)系數(shù)據(jù)庫、非關(guān)系數(shù)據(jù)庫到如今的云數(shù)據(jù)庫，Gartner研究報(bào)告稱到2023年，全球75%的數(shù)據(jù)都會(huì)出現(xiàn)在云平臺(tái)上。

數(shù)據(jù)上云四個(gè)字打出來容易，但真正落實(shí)下來卻存在各種困難。

第一重要的環(huán)節(jié)便是數(shù)據(jù)存儲(chǔ)，就像建高樓一樣，打好地基是關(guān)鍵，只有把數(shù)據(jù)存儲(chǔ)這個(gè)環(huán)節(jié)做到極致，業(yè)務(wù)才能快馬加鞭跑起來。

目前，不少云服務(wù)廠商都推出了數(shù)據(jù)庫產(chǎn)品，在去IOE的路上一路狂奔。

而一個(gè)優(yōu)秀的數(shù)據(jù)存儲(chǔ)產(chǎn)品，既要給足安全感，還要夠便宜，讓數(shù)據(jù)存儲(chǔ)不再是負(fù)擔(dān)，而是業(yè)務(wù)的催化劑。

目前，從結(jié)構(gòu)化/非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)、到數(shù)據(jù)的復(fù)制遷移、災(zāi)備以及預(yù)處理，華為云給數(shù)據(jù)上云的每個(gè)環(huán)節(jié)，都填滿了相應(yīng)的產(chǎn)品。

無論什么業(yè)務(wù)場景，都可以在短時(shí)內(nèi)完成數(shù)據(jù)庫的部署，實(shí)現(xiàn)云端完全托管。

而之所以能做到又快又全又便宜，華為云的這些技術(shù)絕招功不可沒，且聽我們慢慢道來。

數(shù)據(jù)庫“意外失聯(lián)”，DRS速來支招

1、不停機(jī)免費(fèi)遷移

如果將數(shù)據(jù)庫比喻成“城市”，我們可以理解DRS（數(shù)據(jù)復(fù)制服務(wù)）便是城市之間的“地底光纖”，確保將“始發(fā)地”源庫的數(shù)據(jù)安全、快速、高效地運(yùn)輸?shù)健澳康牡亍蹦繕?biāo)庫。

為了保障數(shù)據(jù)庫遷移過程中數(shù)據(jù)的一致性，一種方式是需要停掉業(yè)務(wù)，進(jìn)行一次性遷移（也稱離線遷移），這就造成了數(shù)據(jù)量越大，遷移時(shí)間越長，也就意味著停機(jī)時(shí)間越久。

那么是否有一種方式既能保障數(shù)據(jù)庫遷移過程中數(shù)據(jù)的一致性，又能做到業(yè)務(wù)持續(xù)運(yùn)行？

DRS通過全量遷移+增量同步的方式（也稱在線遷移），在全量遷移完成后，啟動(dòng)增量同步過程。

增量同步是將源庫先進(jìn)行日志解析，日志可以很形象的看成是“錄像帶”，記錄了源庫的所有操作，我們將日志“回放”出來，源庫做了什么數(shù)據(jù)操作，目標(biāo)庫就做什么樣的操作，最終這部分增量數(shù)據(jù)被并行復(fù)制到目標(biāo)庫，來保證數(shù)據(jù)的一致性。整個(gè)過程可以理解為在業(yè)務(wù)運(yùn)行的過程中，潛移默化地完成了源庫與目標(biāo)庫之間的數(shù)據(jù)遷移，業(yè)務(wù)無感知。

原本只能是數(shù)據(jù)庫遷移專家才能完成的復(fù)雜數(shù)據(jù)庫遷移如今在云上變得輕松簡單，普通的從業(yè)者也能完成云上數(shù)據(jù)庫高效遷移，極大便利了客戶、一線運(yùn)維人員和開發(fā)者。

2、多活災(zāi)備

但也有人會(huì)極度缺乏安全，一旦數(shù)據(jù)沒有放在自己的眼皮底下，擔(dān)憂總是無盡的。

在遷移上云后，數(shù)據(jù)備份和恢復(fù)的問題一直困擾中型企業(yè)。老板總是會(huì)擔(dān)心，我的數(shù)據(jù)都放在你們服務(wù)器里，哪天你們機(jī)房發(fā)生地震，我的數(shù)據(jù)怎么辦？

首先，華為云數(shù)據(jù)庫很早便推出了雙AZ高可用災(zāi)備方案，即“同城兩中心”，也就是在同城建立兩個(gè)數(shù)據(jù)庫，當(dāng)其中一個(gè)數(shù)據(jù)庫突發(fā)異常或被破壞時(shí)，可以從另一個(gè)數(shù)據(jù)庫獲取數(shù)據(jù)，以保證系統(tǒng)的持續(xù)穩(wěn)定。

華為云數(shù)據(jù)庫在“同城兩中心”的基礎(chǔ)上提出了異地保護(hù)的方案，DRS推出了異地多活災(zāi)備，即“兩地四中心”。

該災(zāi)備方案支持搭建主備高可用架構(gòu)，當(dāng)主實(shí)例所在區(qū)域突發(fā)自然災(zāi)害等狀況，主備節(jié)點(diǎn)均無法連接時(shí)，可將異地災(zāi)備實(shí)例切換為主實(shí)例，即可快速恢復(fù)應(yīng)用的業(yè)務(wù)訪問，而且可以實(shí)現(xiàn)主實(shí)例和跨區(qū)域的災(zāi)備實(shí)例之間的實(shí)時(shí)同步。

彈性擴(kuò)容之外，從“快遞驛站”獲得高寫入性能

華為云數(shù)據(jù)庫產(chǎn)品不得不提的一個(gè)特點(diǎn)就是彈性擴(kuò)容，業(yè)務(wù)無感知。

以GaussDB(for MySQL)為例，其基于華為最新一代DFV分布式存儲(chǔ)，采用計(jì)算存儲(chǔ)分離架構(gòu)。

當(dāng)計(jì)算和存儲(chǔ)解耦，再利用云架構(gòu)彈性的優(yōu)勢，存儲(chǔ)和計(jì)算均可單獨(dú)按需擴(kuò)縮容，且在分鐘內(nèi)完成，資源利用率達(dá)到最大化。

GaussDB(for MySQL)還支持1寫15讀的只讀節(jié)點(diǎn)的極速擴(kuò)展，最高支持128TB的海量存儲(chǔ)，可實(shí)現(xiàn)超百萬級QPS吞吐，單節(jié)點(diǎn)相比原生MySQL性能提升7倍，而且兼容MySQL，無需分庫分表，應(yīng)用無需改造即可輕松遷移上云。

另外，GaussDB(for MySQL)數(shù)據(jù)庫在寫入性能上，在業(yè)界同類產(chǎn)品中是最好的，這主要得益于它在MySQL內(nèi)核方面的諸多優(yōu)化，其中有一項(xiàng)便是從“送快遞”得來靈感的優(yōu)化——事務(wù)異步提交。

快遞的配送過程中，最耗時(shí)的，不是裝貨、卸貨，而是電話和等待。快遞驛站可以很大程度解決這個(gè)問題。

同樣，事務(wù)處理過程中，存儲(chǔ)的IO就是一個(gè)較長的等待。

數(shù)據(jù)庫使用經(jīng)驗(yàn)豐富的開發(fā)人員來都知道，等待redo日志寫入存儲(chǔ)的磁盤IO性能，很大程度上決定了數(shù)據(jù)庫的寫入性能。

對于GaussDB(for MySQL)這樣存算分離的數(shù)據(jù)庫，存儲(chǔ)的IO耗時(shí)在事務(wù)處理的總耗時(shí)中占據(jù)不小比例，雖然有l(wèi)og buffer的合并寫入，提升并發(fā)情況下的整體吞吐，但如果在等待IO時(shí)間內(nèi)，這些線程能夠去做別的事情（例如處理等待中的其他事務(wù)），那么將會(huì)有進(jìn)一步的性能提升。

既然找到了等待的點(diǎn)，那么我們就可以像快遞配送的優(yōu)化方法，為數(shù)據(jù)庫創(chuàng)造一個(gè)“快遞驛站”。

圖：GaussDB(for MySQL)的“快遞驛站”

如圖所示，當(dāng)redo日志的flush to disk動(dòng)作完成后，即可進(jìn)行事務(wù)提交，但是此時(shí)并不應(yīng)答客戶端，而是直接處理下一個(gè)事務(wù)。同時(shí)使用少量post comit worker線程，來批量等待日志寫入完成（等待的過程其實(shí)并不占用CPU），并應(yīng)答客戶端，這就可以讓“等待”和“下一個(gè)事務(wù)的處理”并行化，讓CPU“閑不下來”。

在標(biāo)準(zhǔn)的sysbench寫入模型下，沒有使用Post Commit時(shí)極限性能是35萬QPS左右，而使用Post commit后可以到大42萬以上的QPS，提升了20%的寫入性能。

擔(dān)心事務(wù)丟失？華為云數(shù)據(jù)庫MySQL表示不可能

數(shù)據(jù)上云后，企業(yè)對云上數(shù)據(jù)庫的要求也越來越高，尤其是數(shù)據(jù)的完整可靠。

有的云廠商為了保證事務(wù)不丟失，選擇增加一個(gè)數(shù)據(jù)庫結(jié)點(diǎn)的方式，但成本也相應(yīng)提高。

有沒有一種兩全其美的方法，既能保證數(shù)據(jù)零丟失，還能降低成本？

華為云數(shù)據(jù)庫MySQL高可靠的應(yīng)用機(jī)制可以做到：主備模式下，在最大程度保證主庫效率的同時(shí)，保證主庫崩潰時(shí)快速恢復(fù)服務(wù)，并且做到事務(wù)零丟失，進(jìn)而保證企業(yè)業(yè)務(wù)的穩(wěn)定持續(xù)。

華為云數(shù)據(jù)庫MySQL半同步復(fù)制基于狀態(tài)通道和時(shí)間戳的高可靠特性，總體上是管控節(jié)點(diǎn)（HA）保存主庫最后的復(fù)制狀態(tài)和時(shí)間戳，備實(shí)例保存主庫最后的復(fù)制狀態(tài)和時(shí)間戳，然后通過比較它們來精準(zhǔn)判斷主庫崩潰時(shí)的復(fù)制狀態(tài)。

·在自行恢復(fù)方面，它可以根據(jù)主庫崩潰時(shí)的復(fù)制狀態(tài)按照以下四種情況準(zhǔn)確恢復(fù)服務(wù)，保證不丟失事務(wù)，并且秒級恢復(fù)服務(wù)：

·在同步復(fù)制狀態(tài)下主庫崩潰，拉起主庫；

·在同步復(fù)制狀態(tài)下主庫崩潰，如果不能拉起主庫，服務(wù)平滑切換到備庫；

·在異步復(fù)制狀態(tài)下主庫崩潰，不能切換到備庫，拉起主庫；

·在異步復(fù)制狀態(tài)下主庫崩潰后，不能切換到備庫，如果不能拉起主庫，會(huì)在原來的數(shù)據(jù)上恢復(fù)主庫。

華為云數(shù)據(jù)庫MySQL半同步復(fù)制高可靠特性能最大程度保證主庫效率，是因?yàn)橹鲙斓氖聞?wù)提交只依賴于備庫，而備庫把這個(gè)事務(wù)寫入中繼日志后立即返回一個(gè)ACK（即確認(rèn)字符），沒有強(qiáng)同步復(fù)制備庫回放事務(wù)帶來的延遲。

舉個(gè)例子，如果用戶買了華為云數(shù)據(jù)庫MySQL，當(dāng)半同步復(fù)制主庫正在執(zhí)行大事務(wù)，并且復(fù)制狀態(tài)從同步復(fù)制轉(zhuǎn)換到異步復(fù)制時(shí)，主庫突然掛掉，用戶服務(wù)被迫中斷，華為云數(shù)據(jù)庫MySQL主庫會(huì)在秒級內(nèi)被拉起對外提供服務(wù)，用戶可以重新連接上華為云數(shù)據(jù)庫，并且與中斷前的數(shù)據(jù)視圖完全一致，沒有事務(wù)丟失。

最后

水是萬物之源，數(shù)據(jù)就是互聯(lián)網(wǎng)之源。

作為計(jì)算機(jī)的三駕馬車之一，數(shù)據(jù)庫是承載互聯(lián)網(wǎng)之源的關(guān)鍵。

828企業(yè)上云節(jié)期間，華為云的數(shù)據(jù)存儲(chǔ)產(chǎn)品也推出了優(yōu)惠活動(dòng)，正是企業(yè)入手云數(shù)據(jù)庫的最佳時(shí)機(jī)。

如果要存儲(chǔ)處理結(jié)構(gòu)化數(shù)據(jù)，有云數(shù)據(jù)庫MySQL、云數(shù)據(jù)庫PostgreSQL和GaussDB（for MySQL）；

如果是非結(jié)構(gòu)化數(shù)據(jù)，有OBS對象存儲(chǔ)服務(wù)、文檔數(shù)據(jù)庫DDS以及MapReduce服務(wù)，還有Redis、Kafka等中間件，從數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)入湖、災(zāi)備到分析，無論什么業(yè)務(wù)場景，總有一款產(chǎn)品最適合你。