微盟被“删库”后,为什么恢复时间这么长?

2020-03-05
341

圈子外的同学可能觉得这个不应该很复杂,感觉不就是重装一下系统吗,数据库不是都应该有备份吗,直接恢复一下不就行了吗。其实事情远远要比你想的复杂得多。很多时候,人常常会有一个认知上的偏差,对于一个自己没有切身参与过的领域,我们会不自觉地对难度产生错误的判断。这种所谓的迷之自信,是很难克服的。


这样的例子很多,比如在看球赛的时候,有人就恨不得把电视砸了,总觉得某些球员怎么这么挫,但是真要是轮到你上场,你就能比他好吗。再比如兰州拉面,看起来也没什么难度嘛,来回几下子面就拉出来了,但要是换你上,你能拉出那碗面吗。


其实,熟悉现代软件架构和运维的同学一定知道,现在软件的架构以及部署是极其复杂的,尤其在微服务大行其道的今天,每个微服务本身就是一个集群,微服务和微服务之间还有各种依赖关系,同时每个微服务都有可能会和数据库打交道,光理清楚这些服务之间的依赖和配置就够大家受的了。


更何况这次的微盟事件不是一次局部的更新和发布,而是几乎整体架构的全局梳理,从这个意义上说,难度不亚于从头搭建整个系统,更何况是在如此巨大的业务压力和舆论压力之下。


再来看看数据库,根据目前官方的信息推测,这次的数据库应该是在生产环境的本地库发生了不可逆的删除,否则不可能会需要这么长的时间。假定本地生产库没了,那唯一的方法就是借助远程灾备的全量备份库来恢复,但这也会引发出一系列的问题,比如远程库容量大,需要大量的网络传输时间。


再比如,增量备份的完整性欠缺,另外,还会出现由于近期的数据Scheme变更引发的备份数据兼容性问题等。这些都需要研发人员和运维人员的共同推进,这就会需要更多的时间……

扫描二维码分享到微信

在线咨询
客服微信
联系电话

028-86728035