|
|
51CTO旗下网站
|
|
移动端

新来的实习生不小心删库了,吓得我虎躯一震!

昨天下午看一篇程序员的搞笑文章,看到了删库跑路的段子,然后想起了自己曾经的经历,于是就想写写了。

作者:佚名来源:51CTO技术栈|2020-02-03 09:10

昨天下午看一篇程序员的搞笑文章,看到了删库跑路的段子,然后想起了自己曾经的经历,于是就想写写了。

图片来自 Pexels

记得是发生在 2013 年,具体日期记不清了。那时候,我们的存储系统已经成功在全部门铺开了,当时我们正准备着手进行第二轮的优化。

相比前面阶段,我们的压力已经小了很多,因为已经完成了最关键的 KPI, 我们可以有规划,有时间地慢慢做优化了。

那天晚上,我本着想 22 点就走的,想回去看部电影,毕竟太久没看了。不过正要走的时候,被 Leader 拉住,他跟我讨论起了存储冷备的问题。

热备我们已经解决的不错了,业务的可用性因此得到很大的提升,冷备是为了解决业务上的问题,比如有人不小心写了个 Bug 把数据给删了,便可以从冷备的数据中恢复回来。

我们讨论得很投入,方案也慢慢清晰了,不知不觉已经 23 点了,觉得太晚了,就约定明天再聊。

我关了显示器,正准备离开的时候,隔壁团队的 D 带着新人 J 跑了过来,很慌张地样子。

他拉住了我,对我说:“你们存储系统的数据可以恢复吗?”

我有点懵:“什么意思?容灾(热备)出问题了吗?”

D 答到:“不是,我们一个实习生的代码有 Bug , 把业务 G 的核心数据全删了!”

“啊!” 我吃惊道。

刚好我 Leader 也在,他走过来,“刚刚我们还在讨论冷备的事情,就是为了应对这种情况的,不过还没开始搞呢!” 他说道。

“那怎么办? 有没有其他办法可以恢复数据,要不整个业务就完蛋了,那是最核心的数据!” D 惊慌地说道。

“让我们想想 !” 我转过身就跟我的 Leader 讨论了起来。

讨论了不到十分钟,就想到一个办法。

因为我们的存储采用的是 BitCask 的模型,删除操作只是在对应的数据里面做了一个标记,没有真正删除,真实的删除会在业务低峰期,数据回收的时候才进行。

也就是说,只要执行数据回收之前,我们就有可能把数据捞出来做恢复。

但方案执行起来有很多需要注意的细节,而且有比较大风险,于是就具体的细节,我们又讨论了二十来分钟。

那时候时间已经是 00:30 了。

一切敲定后,我登录上了他们业务的机器,看配置,数据回收的时间是凌晨 3 点,我赶紧将配置改到了中午 12 点,为接下来的恢复争取时间。

我跟 D 解释了一番,并告知他,可以从未被回收的旧文件里面恢复数据,不过因为第一次遇到这种情况,我需要写个新的工具把旧文件的数据捞出来,然后 D 那边也需要配合写一个工具,将读出来的数据,从业务接口面写回去。

D 听到,仿佛得到拯救一般,连忙道谢!之后就一些细节,我们又进行了一番讨论。

一切敲定,大家便各自忙了起来。我也立马带上我的耳机,吭哧吭哧写起了代码。所幸工具的逻辑不是特别复杂,不到一小时就写完了。

我自己验证了几遍,可以正确的将数据从旧文件中读出来。这时候,已经是凌晨 2 点了。

我跑去了他们的座位,他们那边的工具也准备好了。

于是我们拿了一台机器,准备合起来跑一遍工具,做一次全流程的验证。D 执行了这个操作,看着黑底白字的屏幕上打出的一行行 log , 我们都屏住了呼吸,生怕看到 “Error” 的字样!

所幸,整个过程没有任何报错,我们又找了一个旧工具做了一次数据读取的验证,以确保恢复的数据是正确的。

当看到最终结果的那一刻,我们终于松了一口气,整个方案是可行的,可以正确的恢复数据。这时候,时间已经到了凌晨 3 点多。

此时放松的心,又紧绷了起来。

因为有数据的业务机器有上百台,我们必须在凌晨 5 点前完成全部数据的恢复,要不就会影响到用户的正常访问了。

我们又立马投入方案的讨论中。很快敲定了,单机多进程,多机并发跑的方案。

方案的执行,需要写些并发的 Shell 脚本。我们 3 人又赶忙跑到了运维大神 A 座位,他已经了解事情的前因后果,我们就执行方案跟他做了进一番的讨论,敲定后,他立马就写起了 Shell 。

十多分种后,两个 Shell 脚本都搞定了,A 做了一次验证,一切符合预期。

在准备开跑前,我们又讨论了异常的应对情况,需要监控的关键数据和曲线。这时候时间已经接近 4 点了。

“时间不多了,跑吧!”, 我们异口同声道。

D 和他的实习生也跑回了座位去看业务监控,我在运维大神 A 旁边看着他的操作和监控。

很快,一百多台机器上的自动化脚本和工具全部跑了起来,我们来回切换,看机器的负载和业务的曲线,一切都在预期之中,5 点前,数据终于全部被恢复了。

我们又赶忙找了几个测试号,从用户侧做了一次完整的验证,确保整个业务流程不受影响。

一切符合预期!我们的心才终于安定了下来。看了看时间,已经是凌晨 5 点多了。

搞了一整夜,大家已经是极度疲惫,我们下楼叫了出租车各自回去。

在出租车上,我看着冷清的街道,绿化树一棵棵飞快地往后跑去,马路两边的霓虹灯已经渐渐微弱,天边慢慢露出了乳白色的微光。

我感到疲惫,但也感到一种兴奋。似乎经历了一个人生的重大危机,所幸是有惊无险!

现在回想起来,那确实是惊心动魄的一夜,不过,所幸大家都响应的很及时,配合的很好,才避免了一次可能上微博的删库跑路事件。

我们后来看玩笑,幸好那晚的运气和配合都很好,D 和他的实习生终于不用跑了 。

这是一个业务高速发展路上的一个小插曲。因为当时的业务发展很快,无论是人员的培训还是技术方案的完备性上,都有缺失,但因为大家的努力和尽责,最终还是挺了过来。

在后面的日子里,我们做了多方面的改进,类似的事情,便从未再发生!

【编辑推荐】

  1. 2019年全球最受欢迎数据库新鲜出炉,你猜中了吗?
  2. 国内首份《云数据库选型及满意度调查报告》出炉!
  3. 一次线上故障:数据库连接池泄露后的思考
  4. 聊一聊 MySQL 数据库中的那些锁
  5. 数据库优化,以实际SQL入手,带你一步一步走上SQL优化之路
【责任编辑:庞桂玉 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

Python应用场景实战手册

Python应用场景实战手册

Python应用场景实战手册
共3章 | KaliArch

21人订阅学习

一步到位玩儿透Ansible

一步到位玩儿透Ansible

Ansible
共17章 | 骏马金龙1

203人订阅学习

云架构师修炼手册

云架构师修炼手册

云架构师的必备技能
共3章 | Allen在路上

39人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微