昨天下午，看了一篇程序员写的搞笑文章。看到删库跑路的笑话了。然后我想起了自己的经历，所以我想写一下。图片来自Pexels，我记得它发生在2013年，但我不记得确切的日期。当时，我们的存储系统已经在全部门顺利上线，准备开始第二轮优化。和上一阶段相比，我们的压力小了很多，因为最关键的KPI已经完成了，有时间可以慢慢规划优化。那天晚上，我想22点离开，想回去看电影，毕竟好久没看了。但是临走的时候被Leader拦住了，还和我讨论了存储冷备份的问题。我们已经解决了热备份的问题，业务的可用性有了很大的提升。冷备份是为了解决业务问题。比如有人不小心写了个bug，把数据删了。恢复回来。大家讨论的很投入，方案也渐渐清晰了。不知不觉，已经23:00了，我们觉得来不及了，就约定明天再谈。我关掉显示器，正要离开的时候，隔壁小队的D带着一个新人J跑了过来，看上去很慌张。他一把抓住我，对我说：“你存储系统里的数据能恢复吗？”我有点懵：什么意思？是不是容灾（热备）有问题？D回复：“不行，我们一个实习生的代码有bug，业务G的核心数据全部被删除了！”“啊！”我惊讶的说道。正好我的Leader也在，他走了过来，“刚才我们在讨论冷备份，就是为了应对这种情况，还没开始呢！”他说。“那怎么办？有没有什么办法可以恢复数据，不然整个生意就毁了，那就是核心数据！”D惊慌的说道。“我们考虑一下！”我转身开始和我的领导讨论。商量了不到十分钟，想到了一个解决办法。因为我们的存储采用的是BitCask模型，所以删除操作只是对应数据中的一个标记，并没有真正的删除。真正的删除会在业务的淡季和数据回收的时候进行。也就是说，只要之前进行过数据恢复，我们就可以把数据捞出来进行恢复。但是方案执行需要注意的细节很多，风险比较大，所以具体细节我们又讨论了20分钟。那时已经是00:30了。一切敲定后，我登录到他们的业务机上，看了一下配置。数据恢复的时间是凌晨3:00。我迅速将配置更改为中午12:00，为下次恢复争取时间。我跟D解释了一下，告诉他可以从没有恢复的旧文件中恢复数据，但是因为第一次遇到这种情况，需要自己写一个新的工具把旧文件的数据捞出来，然后D还需要配合写一个工具，将读取到的数据从业务接口写回。D一听，像是得救了一般，连忙道谢！之后，我们讨论了一些细节。一切都敲定后，大家都忙起来了。我立即戴上耳机开始写代码。好在工具的逻辑不是特别复杂，不到一个小时就写完了。我自己也验证过几次，可以正确的从旧文件中读出数据。这时，已经是凌晨2点了。我跑到他们的座位上，他们的工具已经准备好了。于是我们就拿了一台机器，准备一起把这个工具跑起来，对整个过程做一个验证。D执行了这个操作，看着黑白屏幕上打印的一行行日志，我们都屏住了呼吸，生怕看到“Error”三个字！幸运的是，整个过程没有报错，我们又找了一个老工具做了数据读取校验，确保恢复的数据是正确的。看到最后的结果，我们终于松了一口气。整个方案是可行的，可以正确恢复数据。此时，时间已经到了凌晨三点多。这时，我放松的心又紧张了起来。因为有数据的业务机有上百台，我们必须在凌晨5点之前完成所有数据的恢复，否则会影响用户的正常访问。我们立即开始讨论这个计划。很快就敲定了，单机多进程，多机并发运行的方案。要执行该程序，您需要编写一些并发shell脚本。我们三人赶紧坐到运维师A的座位上。他已经了解了事情的来龙去脉，我们与他进一步讨论了实施方案。敲定后，他马上写了Shell。十多分钟后，两个shell脚本完成，A做了验证，一切都符合预期。在准备运行之前，我们讨论了异常响应情况，需要监控的关键数据和曲线。这时已经快4点了。“时间不多了，快跑吧！”我们异口同声地说。D和他的实习生也跑回座位看业务监控，我就在运维大师A旁边看他的运维监控。很快，100多台机器上的自动化脚本和工具全部运行起来。我们来回切换以查看机器的负载和业务曲线。一切都如预期的那样。5:00之前，终于恢复了所有数据。我们赶紧又找了几个测试账号，从用户端做了完整的验证，确保整个业务流程不会受到影响。一切都在预料之中！我们的心终于安定下来了。我看了看时间，已经是凌晨五点多了。工作了一晚上，大家都累的不行，就下楼叫了车回去。出租车里，我看着空无一人的街道，绿树一棵一棵地飞快地往回跑，道路两旁的霓虹灯已经渐渐褪去，天空缓缓透出一丝乳白色的微光。我觉得很累，但也有点兴奋。看来自己的人生经历了重大的危机，还好没有遇到危险！现在回想起来，那确实是一个惊心动魄的夜晚。不过好在大家反应及时，配合的很好，才避免了一条可能的微博。Bo的数据库删除事件。笑话我们后来看了，幸好那天晚上D和他的实习生配合得好，终于不用跑路了。这是企业高速发展路上的一个小插曲。因为当时业务发展很快，无论是人员培养还是技术方案的完备性都存在不足，但是因为大家的努力和付出，我们终于活了下来。在接下来的日子里，我们做了很多改进，类似的事情再也没有发生过！
