一次删库跑路的经历

百家 作者:程序人生 2020-02-01 04:30:05


来源 | 大飞码字(BigFly1024
不好意思,有点标题党了,库确实被删了,不过没有跑路哈。
昨天下午看一篇程序员的搞笑文章,看到了删库跑路的段子,然后想起了自己曾经的经历,于是就想写写了。
记得是发生在2013年,具体日期记不清了。
那时候,我们的存储系统已经成功在全部门铺开了,当时我们正准备着手进行第二轮的优化。相比前面阶段,我们的压力已经小了很多,因为已经完成了最关键的 kpi,  我们可以有规划,有时间地慢慢做优化了。
那天晚上,我本着想 22 点就走的,想回去看部电影,毕竟太久没看了。不过正要走的时候,被 leader 拉住,他跟我讨论起了存储冷备的问题。
热备我们已经解决的不错了,业务的可用性因此得到很大的提升,冷备是为了解决业务上的问题,比如有人不小心写了个 bug 把数据给删了,便可以从冷备的数据中恢复回来。
我们讨论得很投入,方案也慢慢清晰了,不知不觉已经 23 点了,觉得太晚了,就约定明天再聊。
我关了显示器,正准备离开的时候,隔壁团队的 D 带着新人 J 跑了过来,很慌张地样子。
他拉住了我,对我说:“你们存储系统的数据可以恢复吗?
我有点懵:“什么意思?容灾(热备)出问题了吗?
D 答到:“不是,我们一个实习生的代码有 bug , 把业务 G 的核心数据全删了!
“啊!” 我吃惊到。
刚好我 leader 也在,他走过来,“刚刚我们还在讨论冷备的事情,就是为了应对这种情况的,不过还没开始搞呢!” 他说到。
“那怎么办?  有没有其他办法可以恢复数据,要不整个业务就完蛋了,那是最核心的数据!” D惊慌地说到。
“让我们想想 !” 我转过身就跟我的 leader 讨论了起来。
讨论了不到十分钟,就想到一个办法。
因为我们的存储采用的是 BitCask 的模型,删除操作只是在对应的数据里面做了一个标记,没有真正删除,真实的删除会在业务低峰期,数据回收的时候才进行。也就是说,只要执行数据回收之前,我们就有可能把数据捞出来做恢复。
但方案执行起来有很多需要注意的细节,而且有比较大风险,于是就具体的细节,我们又讨论了二十来分钟。
那时候时间已经是 00:30 了。
一切敲定后,我登录上了他们业务的机器,看配置,数据回收的时间是凌晨3点,我赶紧将配置改到了12点,为接下来的恢复争取时间。
我跟D解释了一番,并告知他,可以从未被回收的旧文件里面恢复数据,不过因为第一次遇到这种情况,我需要写个新的工具把旧文件的数据捞出来,然后D那边也需要配合写一个工具,将读出来的数据,从业务接口面写回去。
D听到,仿佛得到拯救一般,连忙道谢!之后就一些细节,我们又进行了一番讨论。
一切敲定,大家便各自忙了起来。我也立马带上我的耳机,吭哧吭哧写起了代码。所幸工具的逻辑不是特别复杂,不到一小时就写完了。
我自己验证了几遍,可以正确的将数据从旧文件中读出来。这时候,已经是凌晨2:00了。
我跑去了他们的座位,他们那边的工具也准备好了。
于是我们拿了一台机器,准备合起来跑一遍工具,做一次全流程的验证。D执行了这个操作,看着黑底白字的屏幕上打出的一行行log , 我们都屏住了呼吸,生怕看到 “Error” 的字样!
所幸,整个过程没有任何报错,我们又找个一个旧工具做了一次数据读取的验证,以确保恢复的数据是正确的。
当看到最终结果的那一刻,我们终于松了一口气,整个方案是可行的,可以正确的恢复数据。这时候,时间已经到了凌晨3点多。
此时放松的心,又紧绷了起来。
因为有数据的业务机器有上百台,我们必须在凌晨5点前完成全部数据的恢复,要不就会影响到用户的正常访问了。
我们又立马投入方案的讨论中。很快敲定了,单机多进程,多机并发跑的方案。方案的执行,需要写些并发的 shell 脚本。我们 3 人又赶忙跑到了运维大神A座位,他已经了解事情的前因后果,我们就执行方案跟他做了进一番的讨论,敲定后,他立马就写起了shell 。
十分多种后,两个 shell 脚本都搞定了,A做了一次验证,一切符合预期。
在准备开跑前,我们又讨论了异常的应对情况,需要监控的关键数据和曲线。这时候时间已经接近 4:00 了。
“时间不多了,跑吧!”, 我们异口同声到。
D和他的实习生也跑回了座位去看业务监控,我在运维大神A旁边看着他的操作和监控。
很快,一百多台机器上的自动化脚本和工具全部跑了起来,我们来回切换,看机器的负载和业务的曲线,一切都在预期之中,5点前,数据终于全部被恢复了。
我们又赶忙找了几个测试号,从用户侧做了一次完整的验证,确保整个业务流程不受影响。一切符合预期!我们的心才终于安定了下来。看了看时间,已经是凌晨5多了。
搞了一整夜,大家已经是极度疲惫,我们下楼叫了出租车各自回去。
在出租车上,我看着冷清的街道,绿化树一棵棵飞快地往后跑去,马路两边的霓虹灯已经渐渐微弱,天边慢慢露出了乳白色的微光。我感到疲惫,但也感到一种兴奋。似乎经历了一个人生的重大危机,所幸是有惊无险!
现在回想起来,那确实是惊心动魄的一夜,不过,所幸大家都响应的很及时,配合的很好,才避免了一次可能上微博的删库跑路事件。
我们后来看玩笑,幸好那晚的运气和配合都很好,D和他的实习生终于不用跑了 。
这是一个业务高速发展路上的一个小插曲。因为当时的业务发展很快,无论是人员的培训还是技术方案的完备性上,都有缺失,但因为大家的努力和尽责,最终还是挺了过来。
在后面的日子里,我们做了多方面的改进,类似的事情,便从未再发生!


热 文 推 荐 

疫情之下「在家办公模式」开启,你该选择哪些远程协同工具?

☞2019 年 Java 的个人总结,请各位小伙伴查阅!

硬核!C语言八大排序算法,附动图和详细代码解释!

疫情面前,医院是否需要数据中台?

Kotlin 风险高、RxJava 已过时,Android 原生开发现状分析!


比特币区块链将分道扬镳、Libra 苦难继续,2020 区块链进入关键时期!

你点的每个“在看”,我都认真当成了喜欢

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接