【大话IT】由炉石传说数据库事故说起！你的数据如何备份？(获奖名单已公布)
获奖公布：最佳优胜奖：michael1983精彩回复：lsstarboy forgaoqiang o枫叶o飘零
请以上获奖人员在4月20日前将姓名、电话、邮箱、公司、职务、快递地址站短给hyukhae079408，以便尽快给大家发放礼品。
导语：
昨天下午突然看到，《炉石传说》游戏数据库发生宕机并引发数据丢失事故的新闻。刚看到时，满满的不可思议。暴雪啊，网易啊。
都是很牛叉的公司。他们出的游戏也很受大家欢迎。
当看到，第一时间着手抢修，重启服务器，并尝试数据恢复时，我的想法是他们的高可用方案呢？为什么不马上切换？
当看到相关备份数据库也出现故障时，就更无语了。其实这样的事情在我们的客户每年都会遇到很多。前不久就有一个医院， 数据库和备份都同时损坏，而且没有高可用的方案。
虽然最终帮他们修复了好数据库，但还是丢失部分数据，而且中间1天时间，业务都是手动操作，严重影响业务。
对于炉石这样的大公司，对应的方案应该是做得很全的，本次事故也可能是有其他的原因。
至于事故的具体原因，大家也可以畅所欲言，批评指正！
那么，
从您的角度，分析此次问题存在的原因是？是官方声称的数据库由于供电意外中断，丢失，还是另有隐情？
活动时间：1月20日—2月20日
活动奖励：
本期活动，我们将特设1个最佳优胜奖，送DTCC2017大会门票一张。
同时，我们将会选取3个精彩回复，各送社区15周年限量版男士商务晴雨伞一把。
DTCC 2017 来啦！
随着云计算和大数据时代的来临，数据正在以前所未有的速度成为各个领域价值创造的核心驱动力。
在此背景下，国内最受关注的数据库技术盛会——2017第八届中国数据库技术大会（DTCC2017）将于2017年5月11-13日如约而至。本届大会以“数据驱动•价值发现”为主题，汇集来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域的120多位技术专家，共同探讨Oracle、MySQL、NoSQL、云端数据库、智能数据平台、区块链、数据可视化、深度学习等领域的前瞻性热点话题与技术。大会共设定2大主场和20个技术专场，将吸引5000多名IT人士参会，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供最具价值的交流平台。
http://file.itpub.net/forum/201612/26/174317gf0a62pp5etz6pmf.jpg
官网链接：http://dtcc.it168.com/
购票链接：http://dtcc.it168.com/goupiao.html
欢迎扫码关注DTCC官方微信，获取最新信息！
http://file.itpub.net/forum/201612/26/174722r6m8hrnjnpporryr.jpg
额。。。第一次夺得第一位！哈哈！！小激动！针对这次游戏数据库出问题这件事情看来，我觉得其实没什么复杂的，在一个环境当中，再牛叉的高可用也变成了低可用，除非做到异地备份与多可用区的高可用。。。要不然，停电一次就是一次灾难！！！ 回复 2# 670260542li
:mrgreen:牛 本帖最后由 o枫叶o飘零 于 2017-02-10 14:45 编辑
先占个位置，这个问题场景 我遇到过{:qq23:}
我说说在上家公司的情况
项目托管在客户找第三方的机房。然后有整机房停电的想象。
因此我们做数据库(mysql)时，就做了 2主1从 主（机房1） 主（机房2） 从（机房1或者2）
这架构只能保证当其中一个机房出问题时，另外1个数据库能用。
但是这个架构有个缺陷就是无法做高可用，所以在实际过程中有点蛋疼。
有一次出现了一个意外情况， 有一个机房突然断电了，然后就发现数据库连接不上了，然后准备手动切换到另外一个机房上时，发现mysql重启起不来了，再然后死活无法启动mysql了。
过了30分钟，那个机房来电了，然后准备启动mysql，一样也无法启动了{:qq35:} 再检查从库，出现一样的问题{:qq35:}。这时我开始绝望了。{:qq35:} （数据量太大，有1.7T没有定期做完备）
最后的解决方法。，把mysql里面的ibdata1和.frm文件copy到另外一个新数据库，可以启动了 ，然后准备用mysqldump，无法mysqldump，我顿时无语。 最后只能用select导出数据，然后再还原了。。。。。{:qq35:}
但是还是损失了几个小时的数据{:qq35:}
最后发现由于停电把那个单库的.frm文件损坏了。。。而且所有主备机上的那个文件都损坏了。。
因此对于IT这种不是完全可控的来说，大黄易的情况我也能理解。不过对于大黄易来说，这次损失确实惨重{:qq30:}
我觉得完全有可能。比如人为操作（不是故意的），或者外界因素，如电力，空调通风等都可能同时造成服务器和热备机同时出现问题。除非将主机和备份机放在不同的地方，比如至少不在同一个房间，当然最好是在两个不同的楼中（在不同的区域），停电一般是一片区一片区停的，不可能整个城市停电。 供电中断，相信吗？机房的电池不是一块两块的，是很多的，UPS也有两套主备，再说还有柴油发电机呢，备电设施全坏谁信啊？市电要是停的话也会提前告知，就是人为操作导致的，凡是经历过的运维人员都会知道的有时候就是神志不清的输入了rm -rf / ,天知道我为什么要敲这条命令:lol且行且珍惜，建议尤其是DBA，最好买本《删库跑路指南》:lol 说是1.14 15:20停电导致数据库损坏，备份也坏无法恢复，后面又说回档到1.14 15:20的状态，那就是说停电并没有导致数据库损坏，这不自相矛盾么？公告写错的概率不大吧，我觉得是隐瞒了实情。 本帖最后由 fenyun689 于 2017-01-23 12:45 编辑
肯定是不愿意投钱。高可用方案只是做个样子，给外面看呢。没有真正去做。
没想过真的会出意想不到的情况。
像银行，电信等行业做的还可以。 难道真是误操作 可能性1：
这是一起运维人员操作失误与玩忽职守的责任事故。
可能性2：
发生小故障不愿停机维护，带病运行导致事故扩大。