如何恢复丢失的两个月数据——“下厨房”技术团队分析总结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在这篇新闻中还提出了更多关于备份策略的技术观点,三年过去,这些观点仍不过时,感兴趣的同学请猛击此处查看更多。

\

你可能感兴趣的:(如何恢复丢失的两个月数据——“下厨房”技术团队分析总结6.26数据库事故)