攜程事件反思:是該重視數(shù)據(jù)庫(kù)災(zāi)備了!

責(zé)任編輯:editor004

作者:王濤

2015-06-01 21:24:43

摘自:巨杉數(shù)據(jù)庫(kù)

在上周,互聯(lián)網(wǎng)技術(shù)圈的一條重磅消息就是某旅游類(lèi)門(mén)戶網(wǎng)站的癱瘓,而據(jù)傳這一情況出現(xiàn)是因?yàn)槠浜笈_(tái)的數(shù)據(jù)庫(kù)被物理刪除,造成數(shù)據(jù)的全部丟失。例如,對(duì)于數(shù)據(jù)庫(kù)管理員來(lái)說(shuō),主備庫(kù)最好由完全不同的團(tuán)隊(duì)管理。

在上周,互聯(lián)網(wǎng)技術(shù)圈的一條重磅消息就是某旅游類(lèi)門(mén)戶網(wǎng)站的癱瘓,而據(jù)傳這一情況出現(xiàn)是因?yàn)槠浜笈_(tái)的數(shù)據(jù)庫(kù)被物理刪除,造成數(shù)據(jù)的全部丟失。到筆者發(fā)稿時(shí),該網(wǎng)站的業(yè)務(wù)尚未恢復(fù),而這一情況出現(xiàn)已經(jīng)超過(guò) 10 個(gè)小時(shí)。有人根據(jù)其業(yè)務(wù)進(jìn)行估計(jì),這一事故的出現(xiàn),每小時(shí)將損失超過(guò)千萬(wàn)元。

我們先不論這一事故是操作失誤還是設(shè)備故障抑或是有人故意為之,數(shù)據(jù)庫(kù)引發(fā)的整個(gè)網(wǎng)站癱瘓也讓人們開(kāi)始重新關(guān)注和重視數(shù)據(jù)庫(kù)的安全性以及高可用性。那么下來(lái)筆者也以這個(gè)事件為引子,談?wù)動(dòng)嘘P(guān)數(shù)據(jù)庫(kù)的數(shù)據(jù)災(zāi)備的一些觀點(diǎn)。

“數(shù)據(jù)庫(kù)災(zāi)備是什么 ”

數(shù)據(jù)庫(kù)災(zāi)備指的是在同一時(shí)間,一個(gè)數(shù)據(jù)庫(kù)在運(yùn)行的同時(shí),還有另外一個(gè)數(shù)據(jù)庫(kù)在另一個(gè)不同的地點(diǎn)運(yùn)行,同時(shí)完全和當(dāng)前的主要運(yùn)行的數(shù)據(jù)庫(kù)實(shí)時(shí)同步。這樣當(dāng)主數(shù)據(jù)庫(kù)發(fā)生任何問(wèn)題的時(shí)候,另一個(gè)地點(diǎn)的數(shù)據(jù)庫(kù)可以立刻接管業(yè)務(wù),使整個(gè)業(yè)務(wù)不會(huì)中斷。

在很多傳統(tǒng)的數(shù)據(jù)庫(kù)中,災(zāi)備是一種非常成熟的技術(shù)。例如 Oracle 的 DataGuard,DB2 的 HADR,都是鼎鼎有名的跨數(shù)據(jù)中心數(shù)據(jù)庫(kù)災(zāi)備方案。使用了災(zāi)備機(jī)制的數(shù)據(jù)庫(kù),當(dāng)主系統(tǒng)所在的數(shù)據(jù)中心出現(xiàn)故障后(不管是被人把系統(tǒng)干掉了,還是整個(gè)數(shù)據(jù)中心被地震震塌了),備系統(tǒng)可以在短時(shí)間內(nèi)感知并接管數(shù)據(jù)服務(wù),使得在線業(yè)務(wù)持續(xù)運(yùn)行。

從技術(shù)的角度看,傳統(tǒng)的災(zāi)備方案一般會(huì)將主庫(kù)的日志順序發(fā)送給備庫(kù),在備庫(kù)上重新執(zhí)行主庫(kù)上的操作。這樣主庫(kù)和備庫(kù)之間可能僅存在非常小的延時(shí),基本實(shí)現(xiàn)同步。但是,在很多新型的分布式數(shù)據(jù)庫(kù)中,災(zāi)備方案還并沒(méi)有像傳統(tǒng)數(shù)據(jù)庫(kù)那樣普及。因此,數(shù)據(jù)的安全性隱患也是很多企業(yè)在考慮使用新型分布式數(shù)據(jù)庫(kù)時(shí)一個(gè)非常重要的因素。

“數(shù)據(jù)庫(kù)災(zāi)備需要考慮的因素 ”

除了基本的數(shù)據(jù)復(fù)制功能外,災(zāi)備方案還有些什么其他重要的考慮因素呢?

1)主備庫(kù)之間的延遲。既然主備庫(kù)分別部署在不同的數(shù)據(jù)中心,互聯(lián)網(wǎng)延遲則是必須考慮的因素。主備庫(kù)之間的延遲越小,當(dāng)主庫(kù)出現(xiàn)故障時(shí)丟失的數(shù)據(jù)越少。例如如果主備庫(kù)之間的延遲可以縮小到一秒鐘以內(nèi),當(dāng)主庫(kù)所在的系統(tǒng)出現(xiàn)人為或非可控災(zāi)難的時(shí)候,主備庫(kù)切換所造成的數(shù)據(jù)損失會(huì)被限定在一秒鐘內(nèi),這樣和整個(gè)門(mén)戶網(wǎng)站的癱瘓比起來(lái),企業(yè)所遭受的損失幾乎可以忽略不計(jì)。

2)占用帶寬小。一般來(lái)說(shuō),主備數(shù)據(jù)中心之間的網(wǎng)絡(luò)帶寬非常昂貴。由于主備數(shù)據(jù)中心之間的網(wǎng)絡(luò)一般都是跨廣域網(wǎng)的,因此其帶寬的承受能力絕對(duì)不能像局域網(wǎng)那樣假設(shè)為千兆或萬(wàn)兆帶寬。因此,在網(wǎng)絡(luò)傳輸時(shí)數(shù)據(jù)通道的條數(shù),數(shù)據(jù)傳輸時(shí)的壓縮比率都是非常重要的指標(biāo)。

3)安全的傳輸通道。既然數(shù)據(jù)是跨廣域網(wǎng)的傳輸,如果有人在機(jī)房外架設(shè)嗅探器,是否可以截獲我們的網(wǎng)絡(luò)通訊呢?如果主備節(jié)點(diǎn)之間總是以明文通訊,這絕對(duì)是一個(gè)非常重大的安全隱患。因此,主備數(shù)據(jù)中心之間的數(shù)據(jù)通訊是否加密則是第三個(gè)重要的安全指標(biāo)。

這些跨數(shù)據(jù)中心復(fù)制的重要因素,在 SequoiaDB 企業(yè)版中得到了非常高的重視。在保證網(wǎng)絡(luò)順暢的環(huán)境中,使用 SequoiaDB 進(jìn)行遠(yuǎn)程跨數(shù)據(jù)中心復(fù)制可以將主備庫(kù)的延時(shí)限定在秒級(jí),同時(shí) SSL 數(shù)據(jù)通道配合數(shù)據(jù)壓縮,使得數(shù)據(jù)在傳輸時(shí)高效安全可靠。

“事故預(yù)防 還需健全的權(quán)限管理 ”

當(dāng)然,除了技術(shù)以外,很多災(zāi)難場(chǎng)景的發(fā)生都是人為產(chǎn)生的。再嚴(yán)密的加密措施也無(wú)法擋住 DBA 從內(nèi)部販賣(mài)數(shù)據(jù);再嚴(yán)格的防火墻也擋不住系統(tǒng)管理員的 rm –rf。因此,對(duì)內(nèi)部員工的培訓(xùn)、監(jiān)管以及系統(tǒng)隔離是非常必要的。

例如,對(duì)于數(shù)據(jù)庫(kù)管理員來(lái)說(shuō),主備庫(kù)最好由完全不同的團(tuán)隊(duì)管理。譬如北京和上海兩個(gè)數(shù)據(jù)中心完全可以由不同的 DBA 團(tuán)隊(duì)運(yùn)營(yíng),就算其中一個(gè)團(tuán)隊(duì)出現(xiàn)問(wèn)題,也不會(huì)對(duì)另一個(gè)團(tuán)隊(duì)運(yùn)維的系統(tǒng)產(chǎn)生影響。

第二,數(shù)據(jù)的備份很多企業(yè)都非常重視,但是可能會(huì)存在一個(gè)團(tuán)隊(duì)能夠管理和隨意修改備份文件。這種情況下,假設(shè)這個(gè)團(tuán)隊(duì)的成員在內(nèi)部進(jìn)行破壞,將生產(chǎn)系統(tǒng)和備份全部銷(xiāo)毀,會(huì)導(dǎo)致整個(gè)企業(yè) IT 系統(tǒng)的完全癱瘓。因此,如何將歷史數(shù)據(jù)和在線數(shù)據(jù)的管理隔離,也是企業(yè)內(nèi)部安全流程非常重要的管理措施。

最后,筆者對(duì)該網(wǎng)站出現(xiàn)的故障深表同情,也希望各大其他的企業(yè)引以為鑒,多多注重?cái)?shù)據(jù)安全,避免相同的事故重演。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號(hào)-6京公網(wǎng)安備 11010502049343號(hào)