下厨房是国内知名的美食社区,在 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 进程。此时采取了三个应急处理措施:
- 整个分区 dd 成镜像,准备做将来硬盘恢复的备份。
- 把 memcache 里的数据 dump 出来,以备可能的恢复。
- 重新启用原来的从数据库。
至凌晨 4 点,服务器恢复访问,但数据停留在 4 月 23 日。
但提供支持的沃趣科技技术人员认为:第一时间停止 MySQL 是错误的做法,
即使分区完全没有文件,mysql 的进程继续运行,只要保留这个现场,可以从内存中获取更多的数据库结构信息,对恢复数据非常有帮助。
在应急处理过程中,紧张和沟通误解也带来了失误。
当配置从数据库的技术人员完成之后,重启了服务器和 memcache,恢复了正常访问。但是做 memcache 导出工作的技术人员还没有完成,所以最终能从 memcache 里得到的那部分数据只有一半左右。
事故发生后的数据恢复从 4 个方面入手:
- 硬盘上数据的恢复(主线)
- 从 memcache 导出的数据恢复
- 从 binlog 里恢复
- 从搜索引擎的快照里恢复页面、
详细步骤,可以参考原文。
接下来,他们要做的主要是两件事:
- 解决用户产生的新数据和恢复的旧数据之间的不兼容情况。
- 落实和第三方方的云存储方案合作,把数据备份到服务器之外的地方。
到博客文章发表时,数据已经恢复了 99%。
文章最后,感谢了杭州沃趣网络科技有限公司 ( @沃趣科技) 的陈栋( @grassbell )和李春( @pickup112 ),沃趣科技是由阿里巴巴原来的 DBA 和 SA 团队核心骨干成立的创业公司,此外还有淘宝 MySQL 数据库运维负责人周振兴( @orczhou )、以及北亚数据恢复中心。
三年前,InfoQ 中文站曾经发表过一篇新闻:《站点恢复过程中的经验和教训》,讲述了Stackoverflow 的创始人 Jeff Atwood 的两个博客站点的事故和恢复过程。Jeff 指出:
可以肯定的是:只有在你拥有某种备份策略,并且坚持执行的时候,你才会了解它。如果备份数据看起来有点麻烦,那就对了,因为它的确是那样。
而他最后得到的教训是:
- 我吸取教训。
- 是的,真的,我吸取教训。
- 不要依赖于你的提供商或者任何其他人来备份你重要的数据。而应该自己来做。如果你不能够对你自己的备份负责,那么数据丢失就不会是偶然事件了。
- 如果你的数据真的出了问题,那么你怎么才能够恢复呢?过程是什么呢?恢复最困难的部分是什么呢?我想在我思想深处对 Coding Horror 的灾难恢复能力有错误的信心,因为我一直认为它大多数都是文本。当然,后来发现文本是其中最简单的部分。而我曾经认为是很好方式的镜像比我意识到的更加重要,而且更加难以恢复。有些人认为我们不应该讨论如何备份,而应该讨论如何恢复。
- 定期对你的恢复过程进行检查,以确认它仍然是可用的、有效的并且功能齐备,这是非常有价值的工作。
Jeff 在这篇新闻中还提出了更多关于备份策略的技术观点,三年过去,这些观点仍不过时,感兴趣的同学请猛击此处查看更多。
评论