99%数据被误删,5类备份全部失效,怎么破?

杨志洪 2017-02-01 23:07:00

最近不仅吃得有点儿疲劳了,甚至看故障类的文章也有点儿疲劳了,似乎从来没有这么密集过。有人提议将今天,2月1日定为世界备份日,我觉得是个好提议,如果你同意,在文章末尾的评论里支持吧!

 

最近连着写了几篇故障文章,说别人家的故障,总有点隔鞋搔痒,看人家笑话的感觉。

 

先说一个小故事吧,某一年三四月份,我和几个同事一起去拜见某大客户的IT总经理木总,聊大型系统的运维经验,聊我们的管控手段,木总很不屑的说,这些我们都做了好几年了……比较幸运的是,半年后我们的团队开始支持他们的系统,紧接着2个月发生了“由于某些原因将某数据库重启后,系统性能运行非常缓慢,后面发现原因是重启后SGA变为几百兆了,而正常是几十GB”,“某数据库出问题,需要恢复的时候,发现Veritas软件恢复的时候不支持,需要打一个补丁”,“所有的用户权限都是DBA,某天突然应用用户drop了个生产表,需要立即恢复”…..木总原以为这些数据库有备份、有流程、有规范的在运维了,事实上是情况已经不像他以为的那么好。所以我们一直说,运维是个持续的过程,要靠专业的运维团队来做,而且流程规范要与时俱进更新和完善。

 

今天发生故障的是一家代码托管的创业公司gitlab.com,说实话我第一反应以为是github,虽然名字很像,其实不是。但是,我非常佩服这家公司,能非常透明地把整个故障情况清晰的发表出来,并在故障处理过程中持续的通过推特在更新。当然,这可能跟它公司的性质相关,它必须及时更新,以尽可能保留住这些用户。更多详细的情况,大家可以直接通过这个网址直接查看:https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

http://monitor.gitlab.net/dashboard/db/postgres-stats?panelId=10&fullscreen&from=now-24h&to=now
 

本文不做过多赘述(不想黏贴复制,也可以通过点击原文访问。后一个网址持续空白中,应该恢复后才能用)。

 

简单介绍一下:

 

1. 工作了一天,疲惫的工程师YP同学在1月31日23点的时候,想把一个自己以为是空目录的文件夹rm –rf删除了。大概一两秒之后,YP同学突然意识到,他大爷的,是不是搞错机器了!没错,他确实搞错机器了!(旁白:我相信你开车的时候,肯定也遇到过有那么几秒钟你突然回过神来,刚刚是不是差点睡着了!)

 

2. 23点27分的时候,YP同学终止了这个操作,然后发现,310GB的数据,只剩4.5GB了,99%的数据已经被误删除。

 

3. 非常不幸的是,之前号称的所有备份都失效了:常规备份(原文是说好像有,但是备份在哪不知道呢)、LVM备份(是24小时一次的。说YP在故障发生的6小时前做了一次,但从恢复进度来看,应该也是失败的)、Azure上的磁盘快照(以为做了,其实没做DB的)、S3上的备份好像也没成功、自动同步程序不稳定,也失效了。

 

截至本文写稿的时候,推特上显示恢复进度已经达到73%了,1小时5%的恢复进度,可想而知不是通过备份来做的恢复,具体恢复技术暂时不得而知。

 

 

我们总在吹牛说,备份重于一切,备份是运维工程师的最后防线。事实上呢?这个例子告诉我们,5重防线都没卵用,因为你没去真正落地。我们在运维群里吹鼻子瞪眼的喊要做好某某检查的时候,并没有把检查结果一一确认,事情就算就做过了,反正相安无事大家也就其乐融融,然后最终悲剧一定到来。作为冲在一线的运维管理者,这种歇斯底里地没有安全感的运维意识如果没有深深刻在骨子里,墨菲小姐的邂逅通常是你最没欲望的时刻。

 

我还是要说,gitlab.com的善后做得很好了,而且我相信,通过这样一次故障,这公司的运维团队很难再犯同样的错误了。真正值得注意的是,那些暂时还没有出过类似故障的团队或者说公司。

 

这次故障,从技术层面、运维层面、管理层面,我们有哪些教训可以习得?

 

  • 首先从技术层面来说,这个数据库居然是用slony的,选择这个版本本身很奇怪。主流数据库不管pg也好(本次生产环境),MySQL也好,Oracle也罢,高可用配置已经是基础建议配置了,但选择一个“稳定”版本应该算是基本的技术问题吧。

 

  • 其次从运维层面来说,备份脚本pg_dump失效,是因为数据库从9.2升级到9.6之后,它所需的备份目录不存在,所以备份是失败的。这东西就跟技术无关了。运维的人从来不看么?做升级这种大的动作,难道只是看升级后业务是否还能运转么?

 

  • 从管理上来说,一个是重大变更操作需要实行金手指模式,不要让一个人干这种事情,老司机也会犯错,何况是半夜。另外一个,晚上工作的人,白天通常就好好休息,也就是常说的运维轮班制度。人的工资贵,但人的工资没有数据价值贵。

 

其实数据库运维中有太多的坑,如果你的数据真的很重要,不妨请一个专业的运维DBA,或者请一个专业的运维DBA团队更靠谱。

 

Gitlab.com的数据恢复过程一直在直播中,如果你有兴趣,可以现在到B站看,3个DBA恢复过程中的对话也挺有趣的:http://live.bilibili.com/19398

 

最后问个问题,你公司最核心的数据库最近一次恢复测试是什么时候?

 

作者介绍

杨志洪DBAplus社群联合发起人,新炬网络首席布道师。Oracle ACE、OCM、《Oracle核心技术》译者。数据管理专家,拥有十余年电信、银行、保险等大型行业核心系统Oracle数据库运维支持经验,掌握ITIL运维体系,擅长端到端性能优化、复杂问题处理。现主要从事数据架构、高可用及容灾咨询服务。

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告