機(jī)房失火還能拯救你的數(shù)據(jù)嗎?
相信很多人都有整理C盤的經(jīng)歷,C盤作為電腦的系統(tǒng)盤,系統(tǒng)運(yùn)行所需的關(guān)鍵數(shù)據(jù)都存儲在其中。但如果使用不當(dāng),C盤就特別容易變紅,然后電腦變卡,惡性循環(huán),最差的結(jié)局就是系統(tǒng)崩潰,所有數(shù)據(jù)丟失。
對于企業(yè)來說,數(shù)據(jù)存儲和管理更是關(guān)乎生存的大事。
如今的企業(yè)數(shù)據(jù)量大、數(shù)據(jù)來源多樣、數(shù)據(jù)形態(tài)復(fù)雜,原有的存儲模式已經(jīng)無法滿足需求,反而會加重存儲負(fù)擔(dān)。
所以,磨刀不誤砍柴工,你們企業(yè)的數(shù)據(jù)存儲做好了嗎?巧婦難為無米之炊,你們業(yè)務(wù)的瓶頸是不是可以從數(shù)據(jù)存儲管理的維度打破?
打好數(shù)據(jù)存儲的地基
從最早的穿孔卡片、關(guān)系數(shù)據(jù)庫、非關(guān)系數(shù)據(jù)庫到如今的云數(shù)據(jù)庫,Gartner研究報告稱到2023年,全球75%的數(shù)據(jù)都會出現(xiàn)在云平臺上。
數(shù)據(jù)上云四個字打出來容易,但真正落實下來卻存在各種困難。
第一重要的環(huán)節(jié)便是數(shù)據(jù)存儲,就像建高樓一樣,打好地基是關(guān)鍵,只有把數(shù)據(jù)存儲這個環(huán)節(jié)做到極致,業(yè)務(wù)才能快馬加鞭跑起來。
目前,不少云服務(wù)廠商都推出了數(shù)據(jù)庫產(chǎn)品,在去IOE的路上一路狂奔。
而一個優(yōu)秀的數(shù)據(jù)存儲產(chǎn)品,既要給足安全感,還要夠便宜,讓數(shù)據(jù)存儲不再是負(fù)擔(dān),而是業(yè)務(wù)的催化劑。
目前,從結(jié)構(gòu)化/非結(jié)構(gòu)化數(shù)據(jù)的存儲、到數(shù)據(jù)的復(fù)制遷移、災(zāi)備以及預(yù)處理,華為云給數(shù)據(jù)上云的每個環(huán)節(jié),都填滿了相應(yīng)的產(chǎn)品。
無論什么業(yè)務(wù)場景,都可以在短時內(nèi)完成數(shù)據(jù)庫的部署,實現(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ù)量越大,遷移時間越長,也就意味著停機(jī)時間越久。
那么是否有一種方式既能保障數(shù)據(jù)庫遷移過程中數(shù)據(jù)的一致性,又能做到業(yè)務(wù)持續(xù)運(yùn)行?
DRS通過全量遷移+增量同步的方式(也稱在線遷移),在全量遷移完成后,啟動增量同步過程。
增量同步是將源庫先進(jìn)行日志解析,日志可以很形象的看成是“錄像帶”,記錄了源庫的所有操作,我們將日志“回放”出來,源庫做了什么數(shù)據(jù)操作,目標(biāo)庫就做什么樣的操作,最終這部分增量數(shù)據(jù)被并行復(fù)制到目標(biāo)庫,來保證數(shù)據(jù)的一致性。整個過程可以理解為在業(yè)務(wù)運(yùn)行的過程中,潛移默化地完成了源庫與目標(biāo)庫之間的數(shù)據(jù)遷移,業(yè)務(wù)無感知。
原本只能是數(shù)據(jù)庫遷移專家才能完成的復(fù)雜數(shù)據(jù)庫遷移如今在云上變得輕松簡單,普通的從業(yè)者也能完成云上數(shù)據(jù)庫高效遷移,極大便利了客戶、一線運(yùn)維人員和開發(fā)者。
2、多活災(zāi)備
但也有人會極度缺乏安全,一旦數(shù)據(jù)沒有放在自己的眼皮底下,擔(dān)憂總是無盡的。
在遷移上云后,數(shù)據(jù)備份和恢復(fù)的問題一直困擾中型企業(yè)。老板總是會擔(dān)心,我的數(shù)據(jù)都放在你們服務(wù)器里,哪天你們機(jī)房發(fā)生地震,我的數(shù)據(jù)怎么辦?
首先,華為云數(shù)據(jù)庫很早便推出了雙AZ高可用災(zāi)備方案,即“同城兩中心”,也就是在同城建立兩個數(shù)據(jù)庫,當(dāng)其中一個數(shù)據(jù)庫突發(fā)異常或被破壞時,可以從另一個數(shù)據(jù)庫獲取數(shù)據(jù),以保證系統(tǒng)的持續(xù)穩(wěn)定。
華為云數(shù)據(jù)庫在“同城兩中心”的基礎(chǔ)上提出了異地保護(hù)的方案,DRS推出了異地多活災(zāi)備,即“兩地四中心”。
該災(zāi)備方案支持搭建主備高可用架構(gòu),當(dāng)主實例所在區(qū)域突發(fā)自然災(zāi)害等狀況,主備節(jié)點均無法連接時,可將異地災(zāi)備實例切換為主實例,即可快速恢復(fù)應(yīng)用的業(yè)務(wù)訪問,而且可以實現(xiàn)主實例和跨區(qū)域的災(zāi)備實例之間的實時同步。
彈性擴(kuò)容之外,從“快遞驛站”獲得高寫入性能
華為云數(shù)據(jù)庫產(chǎn)品不得不提的一個特點就是彈性擴(kuò)容,業(yè)務(wù)無感知。
以GaussDB(for MySQL)為例,其基于華為最新一代DFV分布式存儲,采用計算存儲分離架構(gòu)。
當(dāng)計算和存儲解耦,再利用云架構(gòu)彈性的優(yōu)勢,存儲和計算均可單獨(dú)按需擴(kuò)縮容,且在分鐘內(nèi)完成,資源利用率達(dá)到最大化。
GaussDB(for MySQL)還支持1寫15讀的只讀節(jié)點的極速擴(kuò)展,最高支持128TB的海量存儲,可實現(xiàn)超百萬級QPS吞吐,單節(jié)點相比原生MySQL性能提升7倍,而且兼容MySQL,無需分庫分表,應(yīng)用無需改造即可輕松遷移上云。
另外,GaussDB(for MySQL)數(shù)據(jù)庫在寫入性能上,在業(yè)界同類產(chǎn)品中是最好的,這主要得益于它在MySQL內(nèi)核方面的諸多優(yōu)化,其中有一項便是從“送快遞”得來靈感的優(yōu)化——事務(wù)異步提交。
快遞的配送過程中,最耗時的,不是裝貨、卸貨,而是電話和等待。快遞驛站可以很大程度解決這個問題。
同樣,事務(wù)處理過程中,存儲的IO就是一個較長的等待。
數(shù)據(jù)庫使用經(jīng)驗豐富的開發(fā)人員來都知道,等待redo日志寫入存儲的磁盤IO性能,很大程度上決定了數(shù)據(jù)庫的寫入性能。
對于GaussDB(for MySQL)這樣存算分離的數(shù)據(jù)庫,存儲的IO耗時在事務(wù)處理的總耗時中占據(jù)不小比例,雖然有l(wèi)og buffer的合并寫入,提升并發(fā)情況下的整體吞吐,但如果在等待IO時間內(nèi),這些線程能夠去做別的事情(例如處理等待中的其他事務(wù)),那么將會有進(jìn)一步的性能提升。
既然找到了等待的點,那么我們就可以像快遞配送的優(yōu)化方法,為數(shù)據(jù)庫創(chuàng)造一個“快遞驛站”。
圖: GaussDB(for MySQL)的“快遞驛站”
如圖所示,當(dāng)redo日志的flush to disk動作完成后,即可進(jìn)行事務(wù)提交,但是此時并不應(yīng)答客戶端,而是直接處理下一個事務(wù)。同時使用少量post comit worker線程,來批量等待日志寫入完成(等待的過程其實并不占用CPU),并應(yīng)答客戶端,這就可以讓“等待”和“下一個事務(wù)的處理”并行化,讓CPU“閑不下來”。
在標(biāo)準(zhǔn)的sysbench寫入模型下,沒有使用Post Commit時極限性能是35萬QPS左右,而使用Post commit后可以到大42萬以上的QPS,提升了20%的寫入性能。
擔(dān)心事務(wù)丟失?華為云數(shù)據(jù)庫MySQL表示不可能
數(shù)據(jù)上云后,企業(yè)對云上數(shù)據(jù)庫的要求也越來越高,尤其是數(shù)據(jù)的完整可靠。
有的云廠商為了保證事務(wù)不丟失,選擇增加一個數(shù)據(jù)庫結(jié)點的方式,但成本也相應(yīng)提高。
有沒有一種兩全其美的方法,既能保證數(shù)據(jù)零丟失,還能降低成本?
華為云數(shù)據(jù)庫MySQL高可靠的應(yīng)用機(jī)制可以做到:主備模式下,在最大程度保證主庫效率的同時,保證主庫崩潰時快速恢復(fù)服務(wù),并且做到事務(wù)零丟失,進(jìn)而保證企業(yè)業(yè)務(wù)的穩(wěn)定持續(xù)。
華為云數(shù)據(jù)庫MySQL半同步復(fù)制基于狀態(tài)通道和時間戳的高可靠特性,總體上是管控節(jié)點(HA)保存主庫最后的復(fù)制狀態(tài)和時間戳,備實例保存主庫最后的復(fù)制狀態(tài)和時間戳,然后通過比較它們來精準(zhǔn)判斷主庫崩潰時的復(fù)制狀態(tài)。
在自行恢復(fù)方面,它可以根據(jù)主庫崩潰時的復(fù)制狀態(tài)按照以下四種情況準(zhǔn)確恢復(fù)服務(wù),保證不丟失事務(wù),并且秒級恢復(fù)服務(wù):
在同步復(fù)制狀態(tài)下主庫崩潰,拉起主庫;
在同步復(fù)制狀態(tài)下主庫崩潰,如果不能拉起主庫,服務(wù)平滑切換到備庫;
在異步復(fù)制狀態(tài)下主庫崩潰,不能切換到備庫,拉起主庫;
在異步復(fù)制狀態(tài)下主庫崩潰后,不能切換到備庫,如果不能拉起主庫,會在原來的數(shù)據(jù)上恢復(fù)主庫。
華為云數(shù)據(jù)庫MySQL半同步復(fù)制高可靠特性能最大程度保證主庫效率,是因為主庫的事務(wù)提交只依賴于備庫,而備庫把這個事務(wù)寫入中繼日志后立即返回一個ACK(即確認(rèn)字符),沒有強(qiáng)同步復(fù)制備庫回放事務(wù)帶來的延遲。
舉個例子,如果用戶買了華為云數(shù)據(jù)庫MySQL,當(dāng)半同步復(fù)制主庫正在執(zhí)行大事務(wù),并且復(fù)制狀態(tài)從同步復(fù)制轉(zhuǎn)換到異步復(fù)制時,主庫突然掛掉,用戶服務(wù)被迫中斷,華為云數(shù)據(jù)庫MySQL主庫會在秒級內(nèi)被拉起對外提供服務(wù),用戶可以重新連接上華為云數(shù)據(jù)庫,并且與中斷前的數(shù)據(jù)視圖完全一致,沒有事務(wù)丟失。
最后
水是萬物之源,數(shù)據(jù)就是互聯(lián)網(wǎng)之源。
作為計算機(jī)的三駕馬車之一,數(shù)據(jù)庫是承載互聯(lián)網(wǎng)之源的關(guān)鍵。
828企業(yè)上云節(jié)期間,華為云的數(shù)據(jù)存儲產(chǎn)品也推出了優(yōu)惠活動,正是企業(yè)入手云數(shù)據(jù)庫的最佳時機(jī)。
如果要存儲處理結(jié)構(gòu)化數(shù)據(jù),有云數(shù)據(jù)庫 MySQL、云數(shù)據(jù)庫 PostgreSQL和GaussDB(for MySQL);
如果是非結(jié)構(gòu)化數(shù)據(jù),有OBS對象存儲服務(wù)、文檔數(shù)據(jù)庫DDS以及MapReduce服務(wù),還有Redis、Kafka等中間件,從數(shù)據(jù)存儲、數(shù)據(jù)入湖、災(zāi)備到分析,無論什么業(yè)務(wù)場景,總有一款產(chǎn)品最適合你。
詳情請點擊查看
企業(yè)上云節(jié) 數(shù)據(jù)庫 數(shù)據(jù)復(fù)制服務(wù) DRS MySQL 華為云828
版權(quán)聲明:本文內(nèi)容由網(wǎng)絡(luò)用戶投稿,版權(quán)歸原作者所有,本站不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容,請聯(lián)系我們jiasou666@gmail.com 處理,核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。