一個大膽的猜測：若是GitHub的數據庫用的是OceanBase

今日，GitHub技術負責人Jason Warner的一篇技術深度解析稿成爲IT圈爆款。文中，Jason坦誠地對外講述了10月21日100G光纜設備故障後，Github服務降級的應急過程以及反思總結。

從Jason Warner的文章中不難看出，形成斷網43秒癱瘓24小時的罪魁禍首是數據庫。因爲部署在兩個數據中心的數據庫集羣沒有實時同步。意外發生時，Github的工程師擔憂數據丟失，不敢快速將主數據庫安全切換到東海岸的備份數據中心。

程序員們在GitHub這篇「懺悔錄」下面留言，表達對數據庫集羣的「哀悼」。但更多IT從業者關心的問題是，如何避免這樣的災難事件降臨到本身的公司，本身維護的系統。

螞蟻金服OceanBase分佈式數據庫專家認爲，這次Github事件是典型的城市級故障。若是系統採用的是高可用的三地五中心解決方案，就能夠自如應對。

就在一個月前，今年的杭州雲棲大會上，螞蟻金服副CTO胡喜現場模擬剪斷支付寶近一半的服務器光纜。只用了26秒，模擬環境中的支付寶就徹底恢復了正常，這背後便是OceanBase城市級別故障的自愈能力。

原來，Github相似銀行採用的傳統數據庫兩地三中心模式，即「主庫（主機房）+同城熱備庫（同城熱備機房）+異地災備庫（異地災備機房）」。這種方式下一般只有主機房的服務器能提供寫服務。若是主城市出現城市級故障，災備城市的數據庫雖然能夠工做，但因爲沒有同步的最新數據，所以災備庫的數據是有損的。

但在三地五中心部署下，任何單個城市故障，OceanBase都不會中止服務，數據也不會有任何損失。

Github表示，爲了保證數據完整性，他們不得不犧牲恢復時間。其實，這個問題採用三地五中心方案能夠更好的應對。城市故障時，OceanBase只要活着的兩個城市的三個機房兩兩之間可以通訊，就能夠正常服務，也不會有任何的數據損失。

雙十一廣告：阿里雲雙十一1折拼團活動:已滿6人,都是最低折扣了
【滿6人】1核2G雲服務器99.5元一年298.5元三年 2核4G雲服務器545元一年 1227元三年
【滿6人】1核1G MySQL數據庫 119.5元一年
【滿6人】3000條國內短信包 60元每6月
參團地址：http://click.aliyun.com/m/1000020293/

做者： 華蒙
原文連接
本文爲雲棲社區原創內容，未經容許不得轉載。