下厨房6月26日数据丢失事故总结
Posted by破冰on 2013-7-8 9:39 Monday
在6月26日凌晨12点左右,我们在做线上数据库的备库时,误将线上数据库分区上的所有文件删除。丢失的数据时间段为4月23日至6月25日两个月,在经过7天的努力后,恢复了99%以上的数据。(具体见下面的统计)。
下面把整个事故过程记录下来,令关心本次技术事故的人们知晓。
一.事故隐患
现在回顾,事故隐患在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月23日,需要调整近两月表结构变更,让最新的代码可以跑起来。
当天的应急工作至凌晨4点,服务器都恢复访问,但数据停留在4月23日。
在整个应急过程中,部分是紧张,部分是沟通上存在误解,还是出现了失误。当配置从数据库的技术人员完成之后,重启了服务器和memcache,恢复了正常访问。但是做memcache导出工作的技术人员还没有完成,所以最终能从memcache里得到的那部分数据只有一半左右。
事后从沃趣科技的数据库工程师那里得知,我们第一时间停止MySQL防止硬盘继续写入这个应急措施是错误的,即使分区完全没有文件,mysql的进程继续运行,只要保留这个现场,可以从内存中获取更多的数据库结构信息,对恢复数据非常有帮助。
三.事故后恢复工作
事故后恢复工作从数据来源分为4条线索进行:
1.硬盘上数据的恢复(主线)
2.从memcache导出的数据恢复
3.从binlog里恢复
4.从搜索引擎的快照里恢复页面
以下按时间详细叙述:
下一阶段:
四.所缺失的近两月数据当前的恢复情况
至今,内容大多得到了99%左右的恢复。缺失部分并不是来自硬盘数据丢失,而是6月26日12点前id移位至大值前,半天创建的内容和原位置内容的冲突,我们还在尽力修补。
以下是当前主要内容的恢复情况:
恢复比例
五.致谢
特别感谢一下三个公司和个人在这7天的恢复工作中对我们的帮助。
杭州沃趣网络科技有限公司(@沃趣科技)是来自原阿里巴巴DBA/SA团队核心骨干组建的创业公司,提供数据库和系统相关的专业服务和产品,陈栋(@grassbell)、李春(@pickup112)对破损的数据库文件进行了灾难修复,提取出绝大部分数据表的内容。
周振兴(@orczhou)是淘宝MySQL数据库运维负责人,他对破损文件中部分带二进制段的数据表进行了修复,提取到了相关内容。
北亚数据恢复中心是来自前信息产业部职鉴中心,专门从事数据恢复服务的技术公司。张宇,刘子龙对硬盘文件进行了完整的恢复,使我们得到了数据库的全部数据。
http://www.xshell.net/database/1299.html
【博主评论】
在迁移前的准备阶段:
1 本次迁移,实际上涉及到了mysql升级,主库升级为5.5,从库版本低于主库。没有意识到这个问题,mysql升级后,必然出问题
2 对备份不够重视
即使从库作为实时备份,仍然需要保证另外一种备份策略,保证数据尤其是核心数据存在“强有力”的副本
迁移过程中:
1 没有一个非常清楚完整的checklist,难免会“丢三落四”,忘记操作某些步骤
2 操作不规范,没有一个合理的规范或制度能保证重大操作的风险可控
处理事故阶段:
1 操作不科学,比如,第一时间操作人员执行了停mysql服务,而科学的方法是不能停止mysql
2 多人沟通尤其是跨部门沟通,不顺畅,导致效率低下
其实,这些也在一定程度上反映了平时工作中,技术不过硬,操作不规范,缺乏保障机制,对数据库尤其是备份不重视等问题