暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

那些年删过的库,跑过的路,你从中找到解决方法了吗?

Deer 2019-09-25
1793


本月,多名网友反馈购物推荐网站什么值得买及APP无法访问。晚上10点多官方发表了公告,称服务器遭遇大面积攻击,网站及APP出现异常,目前正在逐步恢复中。针对之前传闻的数据丢失及泄露,什么值得买官方表示否认。但是此次疑似删库事件在网上也是引发了很多热议,下面我们来盘点下往年发生的一些删库事件,思考我们该如何做到更好地预防和处理删库事件。



顺丰事件

2018年9月19 日晚,据微博网友大佬坊间八卦爆料,顺丰的一个高级工程手误把线上系统一个库删除了,导致某项服务无法使用并持续 590 分钟。然后跑路了!


image.png


事件详情:

工程师邓某在接到该变更需求后,按照操作流程要求,登陆生产数据库跳转机,通过navicat-mysql客户端管理工具,连入SHIVA-OMCS的RUSS库进行操作。

但在操作过程中,该运维发现选错了RUSS 数据库,打算删除执行的sql。

在选定删除时,因其操作不严谨,光标回跳到RUSS库的实例上,在未看清所选内容的情况下,便通过delete执行删除,同时,他忽略了弹窗提示,直接回车,导致RUSS库被删除。

因工作运维人员工作不严谨的操作,导致OMCS运营监控系统发生故障,该系统上临时车线上发车功能无法使用并持续约590分钟。同比9月5日的929条临时车需求,此次故障对业务产生了严重的负面影响。



Gitlab删库事件

2017年1月底,Gitlab工作人员由于夜间开车时间很长,错误的将 db1.cluster.gitlab.com (生产库)的数据库删除,而不是db2的。丢失了 6 小时的数据库数据。


事件详情:

image.png


Gitlab的一位系统管理员在给线上数据库做负载均衡工作时,遭受了DDoS攻击。在阻止了攻击之后,运维人员发现了数据库不同步的问题,便开始修复,在修复过程中,错误地在生产环境上执行了数据库目录删除命令,导致300GB数据被删除,Gitlab被迫下线。在恢复的过程中,他们发现只有db1.staging的数据库可以用于恢复,而其它的5种备份机制都不可用。db1.staging 是6小时前的数据,而且传输速率有限,导致恢复进程缓慢,Gitlab 最终丢掉了差不多6个小时的数据。

起因是Gitlab检测到垃圾邮件发送者通过创建片段来攻击数据库,使其不稳定,于是运维block攻击者的IP,并移除用户发送垃圾邮件。之后运维A发现db2.staging复制滞后生产库4GB的数据(据后期2nd Quadrant的CTO – Simon Riggs 建议,PostgreSQL有4GB的同步滞后是正常的),运维A开始尝试修复db2,但复制失败,运维A在尝试了多种方案之后依然如此。

运维A决定删除该db2数据库目录,令其重新复制。由于夜间开车时间很长,运维A错误的将 db1.cluster.gitlab.com (生产库)的数据库删除,而不是db2的。大约 300 GB 左右的数据只剩下约4.5 GB。

随后虽然有号称有五重备份机制(常规备份(24小时做一次)、自动同步、LVM快照(24小时做一次)、Azure备份(只对 NFS 启用,对数据库无效)、S3备份),没有一个可靠地运行或设置,最终只能基于LVM的备份(最近6小时以前),还原了6 小时前的备份。恢复期间Gitlab直播了这次恢复过程。

2017/01/31 18:00开始数据异常,截止2017/02/02 02:14,GitLab.com恢复正常。期间丢失了 6 小时的数据库数据(问题,合并请求,用户,评论,片段等)。Git / wiki 存储库和自托管安装不受影响。根据GitLab从日志里得出的结论,有707位用户丢失数据,5,037项目丢失,受事故影响的用户基数不到1%。



verelox.com删库事件

2017年6月,一家荷兰海牙的云主机商 verelox.com,一名前任管理员删光了该公司所有客户的数据,并且擦除了大多数服务器上面的内容。最终导致 Verelox 暂时将网络下线。


image.png


 

网络剪报服务商 - Instapaper事件

2017年2月9日至2月10日下午7时30分,Instapaper服务突然中断,事故起因是2014年4月之前创建的RDS实例的2TB文件大小限制,造成了不小的损失。



事件详情:

Instapaper 最初的全文检索使用一台 Sphinx 服务器直接和 MySQL 联合提供搜索,这个搜索使用 AWS EC2 大约70GB 内存,4TB 存储的资源:

Instapaper 的索引数据量(数据库的数据量未知),在2016年5月时数据量2.2TB,每月增长约110GB,后来实在慢的不行,最后选择了 AWS 的 elasticsearch cluster来承载这项服务。而最终,还是败在了存储,数据写入失败直接导致数据库宕机。



携程删库事件

2015年5月28日上午11时,携程网突然陷入瘫痪。携程回应称携程部分服务器遭不明攻击,在此次故障中全部遭受物理删除,且备份数据也无法使用。但在5月29日,携程发布官方情况说明称,此次事件是由于员工错误操作,删除了生产服务器上的执行代码导致。


image.png

 


任何程序都会有Bug,任何系统都会有异常,历史发生的删库事件,是提醒我们需要时刻注意风险,积极总结和反思,预防那些可以避免的异常,妥善处理已经发生的异常,让产品更好地服务客户。

说道删库不得不提rm,rm 是 linux 系统下删除文件的命令,-r 代表删除这个下面的一切,一切的一切那种的一切。f 表示不需要用户确认,直接执行。通常这个命令都是指定文件夹用的,比如:

rm -rf /home/test/

就是删除 /home/test/ 这个文件夹下面的所有东西。但是如果后面的文件夹路径没有加对,rm -rf / 在服务器上也就意味着删库了!

所以!严重警告:rm是非常危险的!


面对上面的这些删库事件,我们该如何进行反思?做到更好地预防和处理删库事件呢?


首先,要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制,但是这套备份机制能否真实奏效是需要检验的。我接触过某大型企业,投入巨资兴建的灾备中心,从未正式切换过,这样的灾备在故障来临时也很难有人拍板去进行切换,所以备份的有效、容灾手段的有效是必须确保的。注意,备份的恢复速度必须足够的考虑到,磁带的低效备份关键时刻会害死人。

其次,要有完善的故障处理策略和流程。对于不同系统,在关键时刻要优先确保什么,是要订立规则的,有了规则才能照章办事,不走错方向,不无辜背锅。几年前某国内金融系统出现数据坏块,同样选择了带病修复,最终没能解决问题,同样选择了回档承担了数据损失。

再次,要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案,从业务端同样要有对应的预案,以便应急时同步处理,区别对待。很多时候,有了业务上的应急、降级服务方案,技术层面的处理就能够从容许多。

最后,要有能够快速协同的团队资源。很多时候严重的故障,需要较大规模的专业团队协作处理,原厂商和第三方在其中都承载着重要的角色,所以关键时刻,要能够获得内外部快速及时的支持,尤其是在绵延数天的高强度工作中。


还有无论是运维、DBA 还是程序员们都应该在日常 Coding 时严加注意操作规范,铭记“一失手成千古恨”的后果。在审查时也要做好自动容灾、数据同步的步骤,最重要的是不要忘记备份!!!

最后修改时间:2019-09-25 18:23:29
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论