本篇文章833字,读完约2分钟

幕墙铝板

今天,github技术负责人jason warner的技术深度解析稿成为了it圈的爆款。 在本文中,jason坦率地叙述了10月21日100g光缆设备故障后,github服务降级的应急过程和反思总结。

从jason warner的副本可以看出,互联网瘫痪43秒全天候的原因是数据库。 因为部署在两个数据中心的数据库群集没有实时同步。 在发生意外情况时,github工程师担心数据丢失,无法迅速安全地将主数据库切换到东海岸的备份数据中心。


程序员们在名为github的忏悔下留言,表达对数据库集群的哀悼。 但是,越来越多的it人员关心的问题是,不让这种灾害降临到自己的企业,而是自己维持的系统。

蚂蚁金服oceanbase分布式数据库专家认为,此次github是典型的城市级障碍。 如果系统使用高可用性的三地五中心处理方案,则可以自由应对。

一个月前,在今年的杭州云栖大会上,蚂蚁金服副cto胡喜现场模拟切断了支付宝( Alipay )近一半的服务器光缆。 仅仅26秒钟,模拟环境的“支付宝”( Alipay )就完全恢复了正常。 其背后是oceanbase城市级障碍的自我修复能力。


原来,github如银行使用的那样,传达了2个地区的3个中心模式:主库(主机房) +同城热备盘(同城热备室) +异地灾害恢复库(异地灾害恢复室) 在这种方式中,一般只有主机室的服务器可以提供写入服务。 在主城市发生城市级故障的情况下,灾难恢复城市的数据库可以运行,但由于没有同步的最新数据,该灾难恢复库中的数据已损坏。

但是,在三地五中心的部署中,即使单个城市发生故障,oceanbase也不会停止服务,数据也不会丢失。

github先生说,为了保证数据的完整性,必须牺牲恢复时间。 其实,这个问题如果使用三地五中心方案的话,会得到更好的应对。 如果城市发生故障,oceanbase只要能够在活的两个城市的三个机房的两个之间进行通信,就可以正常服务,也不会有数据丢失。

标题:“怎么不使GitHub那样断网43秒瘫痪 24 个小时?”

地址:http://www.nh-inco.com/nnzx/40393.html