如何避免GitHub那样断网43秒瘫痪 24 个小时?

栏目: 数据库 · 发布时间: 6年前

今日,GitHub技术负责人Jason Warner的一篇技术深度解析稿成为IT圈爆款。文中,Jason坦诚地对外讲述了10月21日100G光缆设备故障后,Github服务降级的应急过程以及反思总结。

如何避免GitHub那样断网43秒瘫痪 24 个小时?

从Jason Warner的文章中不难看出,造成断网43秒瘫痪24小时的罪魁祸首是数据库。由于部署在两个数据中心的数据库集群没有实时同步。意外发生时,Github的工程师担心数据丢失,不敢快速将主数据库安全切换到东海岸的备份数据中心。

程序员们在GitHub这篇“忏悔录”下面留言,表达对数据库集群的“哀悼”。但更多IT从业者关心的问题是,如何避免这样的灾难事件降临到自己的公司,自己维护的系统。

蚂蚁金服OceanBase分布式数据库专家认为,此次Github事件是典型的城市级故障。如果系统采用的是高可用的三地五中心解决方案,就可以自如应对。

就在一个月前,今年的杭州云栖大会上,蚂蚁金服副CTO胡喜现场模拟剪断支付宝近一半的服务器光缆。只用了26秒,模拟环境中的支付宝就完全回复了正常,这背后即是OceanBase城市级别故障的自愈能力。

如何避免GitHub那样断网43秒瘫痪 24 个小时?

原来,Github类似银行采用的传统数据库两地三中心模式,即“主库(主机房)+同城热备库(同城热备机房)+异地灾备库(异地灾备机房)”。这种方式下通常只有主机房的服务器能提供写服务。如果主城市出现城市级故障,灾备城市的数据库虽然可以工作,但由于没有同步的最新数据,因此灾备库的数据是有损的。

但在三地五中心部署下,任何单个城市故障,OceanBase都不会停止服务,数据也不会有任何损失。

Github表示,为了保证数据完整性,他们不得不牺牲恢复时间。其实,这个问题采用三地五中心方案可以更好的应对。城市故障时,OceanBase只要活着的两个城市的三个机房两两之间能够通信,就可以正常服务,也不会有任何的数据损失。

【本文版权归存储在线所有,未经许可不得转载。文章仅代表作者看法,如有不同观点,欢迎添加存储在线微信公众号(微信号:doitmedia)进行交流。】


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

最愚蠢的一代

最愚蠢的一代

马克·鲍尔莱因 / 杨蕾 / 天津社会科学院出版社 / 2011-7 / 39.80元

《最愚蠢的一代》 美国大学教授的鲍尔莱恩认为,数码时代正在使美国的年轻一代成为知识最贫乏的一代人。 美国的青少年和年轻人正在被数码时代各种娱乐消遣性的工具所淹没。这些工具包括手机、社交网络和信息传送等等。他们通过这些工具传达的却是幼稚浮浅的东西,而且这些东西正在妨碍他们同历史、公民义务、国际事务和美术等成年人的现实世界进行重要的接触。 我们想当然地以为,这些善于吸收新技术的美国年......一起来看看 《最愚蠢的一代》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器