小螞蟻說：
螞蟻金服自研的金融級分布式關系型資料庫OceanBase的高可用及容災能力在發生城市級故障時，讓系統秒級完成智能切換，實作自愈，使用者的資金、資料0丢失（新來的同學可以移步《
現場剪光纜！ATEC上支付寶模拟自斷一半伺服器，26秒一切恢複正常》了解更多~）。
今日，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隻要活着的兩個城市的三個機房兩兩之間能夠通信，就可以正常服務，也不會有任何的資料損失。
— END —