從Jason Warner的文章中不難看出,造成斷網(wǎng)43秒癱瘓24小時的罪魁禍?zhǔn)资菙?shù)據(jù)庫。由于部署在兩個數(shù)據(jù)中心的數(shù)據(jù)庫集群沒有實時同步。意外發(fā)生時,Github的工程師擔(dān)心數(shù)據(jù)丟失,不敢快速將主數(shù)據(jù)庫安全切換到東海岸的備份數(shù)據(jù)中心。

程序員們在GitHub這篇“懺悔錄”下面留言,表達對數(shù)據(jù)庫集群的“哀悼”。但更多IT從業(yè)者關(guān)心的問題是,如何避免這樣的災(zāi)難事件降臨到自己的公司,自己維護的系統(tǒng)。

螞蟻金服OceanBase分布式數(shù)據(jù)庫專家認(rèn)為,此次Github事件是典型的城市級故障。如果系統(tǒng)采用的是高可用的三地五中心解決方案,就可以自如應(yīng)對。

就在一個月前,今年的杭州云棲大會上,螞蟻金服副CTO胡喜現(xiàn)場模擬剪斷支付寶近一半的服務(wù)器光纜。只用了26秒,模擬環(huán)境中的支付寶就完全回復(fù)了正常,這背后即是OceanBase城市級別故障的自愈能力。

原來,Github類似銀行采用的傳統(tǒng)數(shù)據(jù)庫兩地三中心模式,即“主庫(主機房)+同城熱備庫(同城熱備機房)+異地災(zāi)備庫(異地災(zāi)備機房)”。這種方式下通常只有主機房的服務(wù)器能提供寫服務(wù)。如果主城市出現(xiàn)城市級故障,災(zāi)備城市的數(shù)據(jù)庫雖然可以工作,但由于沒有同步的最新數(shù)據(jù),因此災(zāi)備庫的數(shù)據(jù)是有損的。

但在三地五中心部署下,任何單個城市故障,OceanBase都不會停止服務(wù),數(shù)據(jù)也不會有任何損失。

Github表示,為了保證數(shù)據(jù)完整性,他們不得不犧牲恢復(fù)時間。其實,這個問題采用三地五中心方案可以更好的應(yīng)對。城市故障時,OceanBase只要活著的兩個城市的三個機房兩兩之間能夠通信,就可以正常服務(wù),也不會有任何的數(shù)據(jù)損失。

分享到

xiesc

相關(guān)推薦