如何恢复丢失的两个月数据——“下厨房”技术团队分析总结6.26数据库事故

下厨房是国内知名的美食社区，在Alexa的全球排名达到6,469，国内排名为769，国内注册用户160多万人。6月26日，由于技术人员操作失误，导致近两个月数据丢失，到昨天为止，他们找回了99%丢失的数据。技术团队在他们的博客上分析了本次事故的经过。

\

文章开始简述了本次事故的具体情况：

\

\

在6月26日凌晨12点左右，我们在做线上数据库的备库时，误将线上数据库分区上的所有文件删除。丢失的数据时间段为4月23日至6月25日两个月。

\

\

对于事故的根本原因，文章指出：

\

\

我们对数据库迁移工作的管理存在失误，是造成事故的根本原因。没有完成数据库备份节点，迁移工作就并没有结束。我们技术团队的所有人对这个事故都负有责任，这个隐患在两个月里都可能被发现，每个人都有可能提出这个工作的高优先级。也都可能提出相应的弥补工作来保证数据安全，比如在启用从节点前延长二进制日志的保存时间等。是我们的工作失误使数据库成为系统最脆弱的环节，经受不住偶然事故的冲击。

\

\

而事故隐患在4月23日之后就已经存在了：

\

\

我们线上数据库使用的是MySQL，在4月23日之前，我们对线上数据库主节点有三类备份。一是有一个独立的数据库从节点来备份，与线上服务器保持数据的实时同步，需要时可切换作线上使用。二是会定期把整个数据库dump成sql文件来备份，一天保存一次，备份的来源是数据库从节点。三是主节点开启有binlog，默认是保存十天的日志，十天内有任何事故可以从日志里完整恢复全部数据。这三个备份分别存放在两台不同的物理机，三个不同的分区上，是当时想到的最安全的方式。

\

4月23日，我们把数据库主节点迁移到一台新的物理机上，并把版本升级到5.5。由于版本和配置的问题，原来的从节点并不能直接使用。而一天一次的备份来源是从节点（备份主节点会令网站和手机app有1小时左右的卡顿），这个备份方式也就停止了更新。只有最后一个binlog还在运行。数据库迁移之后应用服务器存在一些性能问题需要投入时间，包括修复MySQL5.5版本和原代码的兼容，以及把应用服务器从gunicorn换成uwsgi，之后又陆续有一些开发任务，以致重新启用备份节点的工作一再拖延。

\

\

接下来，文章中分析了事故的发生过程：

\

\

6月26日凌晨12点，开始重新建立备份节点工作，需要把原来的从节点删除，重新安装，所以先使用了rm -f方式删除备份节点分区上的所有文件。

\

5分钟后，发现刚才删除的是数据库主节点的分区，为防止硬盘继续写入，就马上停止MySQL进程。此时采取了三个应急处理措施：

\

1. 整个分区dd成镜像，准备做将来硬盘恢复的备份。\
2. 把memcache里的数据dump出来，以备可能的恢复。\
3. 重新启用原来的从数据库。\

\

至凌晨4点，服务器恢复访问，但数据停留在4月23日。

\

但提供支持的沃趣科技技术人员认为：第一时间停止MySQL是错误的做法，

\

\

即使分区完全没有文件，mysql的进程继续运行，只要保留这个现场，可以从内存中获取更多的数据库结构信息，对恢复数据非常有帮助。

\

\

在应急处理过程中，紧张和沟通误解也带来了失误。

\

\

当配置从数据库的技术人员完成之后，重启了服务器和memcache，恢复了正常访问。但是做memcache导出工作的技术人员还没有完成，所以最终能从memcache里得到的那部分数据只有一半左右。

\

\

事故发生后的数据恢复从4个方面入手：

\

1. 硬盘上数据的恢复（主线）\
2. 从memcache导出的数据恢复\
3. 从binlog里恢复\
4. 从搜索引擎的快照里恢复页面、\

详细步骤，可以参考原文。

\

接下来，他们要做的主要是两件事：

\

• 解决用户产生的新数据和恢复的旧数据之间的不兼容情况。\
• 落实和第三方方的云存储方案合作，把数据备份到服务器之外的地方。\

到博客文章发表时，数据已经恢复了99%。

\

文章最后，感谢了杭州沃趣网络科技有限公司(@沃趣科技)的陈栋（@grassbell）和李春（@pickup112），沃趣科技是由阿里巴巴原来的DBA和SA团队核心骨干成立的创业公司，此外还有淘宝MySQL数据库运维负责人周振兴（@orczhou）、以及北亚数据恢复中心。

\

三年前，InfoQ中文站曾经发表过一篇新闻：《站点恢复过程中的经验和教训》，讲述了Stackoverflow的创始人Jeff Atwood的两个博客站点的事故和恢复过程。Jeff指出：

\

\

可以肯定的是：只有在你拥有某种备份策略，并且坚持执行的时候，你才会了解它。如果备份数据看起来有点麻烦，那就对了，因为它的确是那样。

\

\

而他最后得到的教训是：

\

\

1. 我吸取教训。\
2. 是的，真的，我吸取教训。\
3. 不要依赖于你的提供商或者任何其他人来备份你重要的数据。而应该自己来做。如果你不能够对你自己的备份负责，那么数据丢失就不会是偶然事件了。\
4. 如果你的数据真的出了问题，那么你怎么才能够恢复呢？过程是什么呢？恢复最困难的部分是什么呢？我想在我思想深处对Coding Horror的灾难恢复能力有错误的信心，因为我一直认为它大多数都是文本。当然，后来发现文本是其中最简单的部分。而我曾经认为是很好方式的镜像比我意识到的更加重要，而且更加难以恢复。有些人认为我们不应该讨论如何备份，而应该讨论如何恢复。\
5. 定期对你的恢复过程进行检查，以确认它仍然是可用的、有效的并且功能齐备，这是非常有价值的工作。\

\

Jeff在这篇新闻中还提出了更多关于备份策略的技术观点，三年过去，这些观点仍不过时，感兴趣的同学请猛击此处查看更多。

\