10 月,开发者不可错过的开源大数据大会-2021 WeDataSphere 社区大会深圳站 了解详情
写点什么

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

2019 年 8 月 30 日

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

小蚂蚁说:

蚂蚁金服自研的金融级分布式关系型数据库 OceanBase 的高可用及容灾能力在发生城市级故障时,让系统秒级完成智能切换,实现自愈,用户的资金、数据 0 丢失。


今日,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 只要活着的两个城市的三个机房两两之间能够通信,就可以正常服务,也不会有任何的数据损失。


本文转载自公众号蚂蚁金服科技(ID:Ant-Techfin)。


原文链接:


https://mp.weixin.qq.com/s/29cwS71iKVLhZ_6YgS-rRQ


2019 年 8 月 30 日 16:023029
用户头像

发布了 150 篇内容, 共 24.6 次阅读, 收获喜欢 23 次。

关注

评论

发布
暂无评论
发现更多内容

开源中间件技术学习路线

开源中间件技术学习路线

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