|
出大事了！ 据可靠消息，位于荷兰海牙的一家云主机商 verelox.com， 一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容，客户数据恢复希望渺茫。 引用verelox.com公告全文：
等等，又是荷兰？！我怎么闻到了似曾相识的味道捏。没错，年初的GitLab的删库事件也发生在荷兰！看来今年不是荷兰的DBA时来运转的好时期。 回到事件，要怎么处理呢？我也不知道啊，静观其变。 不过这惨绝人寰的事情接连发生，让多愁善感的小编又要失眠了。月黑风高，有酒有故事，我们一起来回顾下那些删库跑路的日子吧。 不知道什么时候开始，有一本红遍大江南北的书叫做《MySQL 从删库到跑路》广泛流传于IT界，并持续阴魂不散，带着一股妖风，影响了整个IT界的风气。广大的运维DBA们，大概是找不到女朋友生活没有什么乐趣吧（小编已经做好被打死的准备了），非得找点好玩的事情来体验下人生。什么最好玩呢，当然是破坏！ 来我们玩个游戏！
看出来了吧，没有不想删库的DBA，只有不想负责任删库的DBA。但是自从'从删库到跑路'这一思想传遍大江南北，大家都知道了答案，再不济我还可以跑啊！你是不是也是这么想的。 大家都想删库，都想好了出路。果然2017在劫难逃。我们来细数一下2017所遭遇的删库跑路事件。 断电又不怪我 1月20日，大约一定是受到川普上任的影响，突如其来的服务器故障影响了一大批炉石玩家，恢复时间长，由于意外断电，导致数据库损坏，不得不通过游戏回档恢复数据库的使用。（关于炉石传说的Oracle数据库故障不要以为你也可以幸免） 游戏进度回退了，辛辛苦苦挣来的装备都不见了，然而面对网易和暴雪如此诚恳的态度，想发火都不容易。 深夜加班我也累呀 2月1日，除夕刚刚过完，荷兰的一个DBA在数据库复制过程中意外地删除了一个错误的服务器上的目录，删除了一个包含300GB的实时生产数据的文件夹。300G的数据库被删成4.5G，由于没有有效的备份，尝试了所有5个恢复工具都没有完成恢复。在丢失数据并恢复失败后，服务器彻底崩溃。（五重备份无一有效，还有哪些 rm -rf 和GitLab类似的忧伤？） 这估计是春节期间最劲爆的消息了，大过年的大家都放弃了吃肉喝酒的好光阴大半夜守着GitLab的故障分析直播。 讲真，我还真没有见过孩纸们这么热爱学习的时候呢。 老板你总是舍不得买高性能的存储 2月11日，网络剪报服务商 - Instapaper 遭受了超过31小时的服务中断，声明需要一个星期的数据库恢复时间，然而经过10天的恢复，也仅仅恢复了6个星期的数据。（云服务真的靠谱吗？ AWS 用户中断31小时仅恢复6周数据）
别这么看我，我们都犯错，只是我犯的错误更严重罢了 2017-04-05，位于纽约的云服务商 Digital Ocean 遭遇了一次长达4小时56分钟的停机事故，事故的原因是主数据库被删除了（primary database had been deleted），由于配置错误，本应指向测试环境的任务被指向了生产环境，测试任务包含的环境初始化过程删除了主生产数据库。（不以规矩不成方圆：Digital Ocean也删除了他们的数据库） 手动删库简直太low，我都是脚本自动删 又不禁想起了Google曾经轰动一时的流水线删库事件，这可是团队作案哟，这么团结真的好吗？（时移世易：遵从既往经验致 1.5PB 数据删除，Google SRE是如何应对的？）
办法不早就教你了吗 删库就删库也没有什么了不起，但是千万别说我没有告诉过你处理办法。不信往这里看，岁末警示：当你手抖删了线上数据库..
所以下次呢，如果你手抖删库了，一定要冷静地到你老板那里说，人家也很伤心，需要抱抱安慰。 好吧你这样就太过了，会被老板轰出去的。但你要记得，不要谈故障的原因，要谈解决方案，Be a man,你自己闯下的祸，自己承担起来! 万一老板真要惩罚你怎么办，一个字，跑啊！说实话，你是不是老早就打算删库跑路了，只是一直没有机会。 小编最近查了一下，发现想跑路的人真是不少。
我说大家都怎么了呢，这是跟世界有多大的仇恨呀。不过考虑到，你们可能真的没有遇到好老板心里苦，你看像我这种生活在幸福深处的员工，有一个超级完美的老板，就完全不能理解你们普通人的心情。
既然你都有了这种想法，我好像也没有什么可说的了。但是我必须要再次苦口婆心地提醒你，备份重于一切！rm是危险的！三思而后行！如果这三句话还没有成为你的座右铭，我觉得你应该需要休个假好好思考一下人生了~ 既然你都耐心看到了这里，不送礼我都不好意思结束文章，来收礼吧！
|
|
|
