免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
123下一页
最近访问板块 发新帖
查看: 75937 | 回复: 24

【大话IT】由炉石传说数据库事故说起!你的数据如何备份?(获奖名单已公布) [复制链接]

论坛徽章:
146
2015年亚洲杯之日本
日期:2015-04-28 13:32:012015年亚洲杯之朝鲜
日期:2015-05-06 10:16:442015年亚洲杯之日本
日期:2015-05-06 10:21:342015年亚洲杯纪念徽章
日期:2015-05-13 17:16:442015亚冠之北京国安
日期:2015-05-13 17:18:292015亚冠之鹿岛鹿角
日期:2015-05-13 17:19:062015亚冠之德黑兰石油
日期:2015-05-27 16:47:402015亚冠之塔什干棉农
日期:2015-05-28 15:24:122015亚冠之卡尔希纳萨夫
日期:2015-06-01 13:52:392015亚冠之柏斯波利斯
日期:2015-06-04 17:37:292015亚冠之阿尔纳斯尔
日期:2015-06-16 11:31:202015亚冠之塔什干火车头
日期:2015-06-23 10:12:33
发表于 2017-01-20 11:35 |显示全部楼层
获奖公布:最佳优胜奖:michael1983
精彩回复:lsstarboy    forgaoqiang    o枫叶o飘零
请以上获奖人员在4月20日前将姓名、电话、邮箱、公司、职务、快递地址站短给hyukhae079408,以便尽快给大家发放礼品。

导语:
昨天下午突然看到,《炉石传说》游戏数据库发生宕机并引发数据丢失事故的新闻。刚看到时,满满的不可思议。暴雪啊,网易啊。

都是很牛叉的公司。他们出的游戏也很受大家欢迎。

IMG_0307.JPG


当看到,第一时间着手抢修,重启服务器,并尝试数据恢复时,我的想法是他们的高可用方案呢?为什么不马上切换?

当看到相关备份数据库也出现故障时,就更无语了。其实这样的事情在我们的客户每年都会遇到很多。前不久就有一个医院, 数据库和备份都同时损坏,而且没有高可用的方案。

虽然最终帮他们修复了好数据库,但还是丢失部分数据,而且中间1天时间,业务都是手动操作,严重影响业务。

对于炉石这样的大公司,对应的方案应该是做得很全的,本次事故也可能是有其他的原因。

至于事故的具体原因,大家也可以畅所欲言,批评指正!


那么,


从您的角度,分析此次问题存在的原因是?是官方声称的数据库由于供电意外中断,丢失,还是另有隐情?


活动时间:1月20日—2月20日


活动奖励:
本期活动,我们将特设1个最佳优胜奖,送DTCC2017大会门票一张

同时,我们将会选取3个精彩回复,各送社区15周年限量版男士商务晴雨伞一把。

IMG_0308.JPG


DTCC 2017 来啦!

随着云计算和大数据时代的来临,数据正在以前所未有的速度成为各个领域价值创造的核心驱动力。

在此背景下,国内最受关注的数据库技术盛会——2017第八届中国数据库技术大会(DTCC2017)将于2017年5月11-13日如约而至。本届大会以“数据驱动•价值发现”为主题,汇集来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域的120多位技术专家,共同探讨Oracle、MySQL、NoSQL、云端数据库、智能数据平台、区块链、数据可视化、深度学习等领域的前瞻性热点话题与技术。大会共设定2大主场和20个技术专场,将吸引5000多名IT人士参会,为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供最具价值的交流平台。




官网链接:http://dtcc.it168.com/
购票链接:http://dtcc.it168.com/goupiao.html

欢迎扫码关注DTCC官方微信,获取最新信息!









论坛徽章:
1
15-16赛季CBA联赛之广夏
日期:2017-02-17 10:00:13
发表于 2017-01-20 14:11 |显示全部楼层
额。。。第一次夺得第一位!哈哈!!小激动!针对这次游戏数据库出问题这件事情看来,我觉得其实没什么复杂的,在一个环境当中,再牛叉的高可用也变成了低可用,除非做到异地备份与多可用区的高可用。。。要不然,停电一次就是一次灾难!!!

论坛徽章:
146
2015年亚洲杯之日本
日期:2015-04-28 13:32:012015年亚洲杯之朝鲜
日期:2015-05-06 10:16:442015年亚洲杯之日本
日期:2015-05-06 10:21:342015年亚洲杯纪念徽章
日期:2015-05-13 17:16:442015亚冠之北京国安
日期:2015-05-13 17:18:292015亚冠之鹿岛鹿角
日期:2015-05-13 17:19:062015亚冠之德黑兰石油
日期:2015-05-27 16:47:402015亚冠之塔什干棉农
日期:2015-05-28 15:24:122015亚冠之卡尔希纳萨夫
日期:2015-06-01 13:52:392015亚冠之柏斯波利斯
日期:2015-06-04 17:37:292015亚冠之阿尔纳斯尔
日期:2015-06-16 11:31:202015亚冠之塔什干火车头
日期:2015-06-23 10:12:33
发表于 2017-01-20 17:44 |显示全部楼层
回复 2# 670260542li

论坛徽章:
39
双子座
日期:2014-08-06 17:37:19极客徽章
日期:2016-12-07 14:03:402017金鸡报晓
日期:2017-01-10 15:13:292017金鸡报晓
日期:2017-02-08 10:39:4215-16赛季CBA联赛之新疆
日期:2017-03-24 16:36:1915-16赛季CBA联赛之江苏
日期:2017-04-26 17:19:08黑曼巴
日期:2018-03-07 18:56:5615-16赛季CBA联赛之八一
日期:2018-03-09 10:44:1015-16赛季CBA联赛之江苏
日期:2018-03-12 15:12:1915-16赛季CBA联赛之青岛
日期:2018-03-16 09:13:0515-16赛季CBA联赛之山东
日期:2018-04-27 18:23:0515-16赛季CBA联赛之新疆
日期:2018-05-04 11:29:30
发表于 2017-01-20 18:00 |显示全部楼层
本帖最后由 o枫叶o飘零 于 2017-02-10 14:45 编辑

先占个位置,这个问题场景 我遇到过  
我说说在上家公司的情况

项目托管在客户找第三方的机房。然后有整机房停电的想象。

因此我们做数据库(mysql)时,就做了 2主1从       主(机房1) 主(机房2) 从(机房1或者2)

这架构只能保证当其中一个机房出问题时,另外1个数据库能用。

但是这个架构有个缺陷就是无法做高可用,所以在实际过程中有点蛋疼。

有一次出现了一个意外情况, 有一个机房突然断电了,然后就发现数据库连接不上了,然后准备手动切换到另外一个机房上时,发现mysql重启起不来了,再然后死活无法启动mysql了。

过了30分钟,那个机房来电了,然后准备启动mysql,一样也无法启动了   再检查从库,出现一样的问题。  这时我开始绝望了。 (数据量太大,有1.7T  没有定期做完备)

最后的解决方法。,把mysql里面的ibdata1和.frm文件copy到另外一个新数据库,可以启动了 ,然后准备用mysqldump,无法mysqldump,我顿时无语。 最后只能用select导出数据,然后再还原了。。。。。

但是还是损失了几个小时的数据
最后发现由于停电把那个单库的.frm文件损坏了。。。而且所有主备机上的那个文件都损坏了。。

因此对于IT这种不是完全可控的来说,大黄易的情况我也能理解。不过对于大黄易来说,这次损失确实惨重

论坛徽章:
59
2015七夕节徽章
日期:2015-08-24 11:17:25ChinaUnix专家徽章
日期:2015-07-20 09:19:30每周论坛发贴之星
日期:2015-07-20 09:19:42ChinaUnix元老
日期:2015-07-20 11:04:38荣誉版主
日期:2015-07-20 11:05:19巳蛇
日期:2015-07-20 11:05:26CU十二周年纪念徽章
日期:2015-07-20 11:05:27IT运维版块每日发帖之星
日期:2015-07-20 11:05:34操作系统版块每日发帖之星
日期:2015-07-20 11:05:36程序设计版块每日发帖之星
日期:2015-07-20 11:05:40数据库技术版块每日发帖之星
日期:2015-07-20 11:05:432015年辞旧岁徽章
日期:2015-07-20 11:05:44
发表于 2017-01-20 22:02 |显示全部楼层
我觉得完全有可能。比如人为操作(不是故意的),或者外界因素,如电力,空调通风等都可能同时造成服务器和热备机同时出现问题。除非将主机和备份机放在不同的地方,比如至少不在同一个房间,当然最好是在两个不同的楼中(在不同的区域),停电一般是一片区一片区停的,不可能整个城市停电。

论坛徽章:
0
发表于 2017-01-22 17:22 |显示全部楼层
供电中断,相信吗?机房的电池不是一块两块的,是很多的,UPS也有两套主备,再说还有柴油发电机呢,备电设施全坏谁信啊?市电要是停的话也会提前告知,就是人为操作导致的,凡是经历过的运维人员都会知道的有时候就是神志不清的输入了rm -rf / ,天知道我为什么要敲这条命令且行且珍惜,建议尤其是DBA,最好买本《删库跑路指南》

论坛徽章:
323
射手座
日期:2013-08-23 12:04:38射手座
日期:2013-08-23 16:18:12未羊
日期:2013-08-30 14:33:15水瓶座
日期:2013-09-02 16:44:31摩羯座
日期:2013-09-25 09:33:52双子座
日期:2013-09-26 12:21:10金牛座
日期:2013-10-14 09:08:49申猴
日期:2013-10-16 13:09:43子鼠
日期:2013-10-17 23:23:19射手座
日期:2013-10-18 13:00:27金牛座
日期:2013-10-18 15:47:57午马
日期:2013-10-18 21:43:38
发表于 2017-01-23 09:39 |显示全部楼层
说是1.14 15:20停电导致数据库损坏,备份也坏无法恢复,后面又说回档到1.14 15:20的状态,那就是说停电并没有导致数据库损坏,这不自相矛盾么?公告写错的概率不大吧,我觉得是隐瞒了实情。

论坛徽章:
43
15-16赛季CBA联赛之上海
日期:2020-11-04 09:36:5515-16赛季CBA联赛之北控
日期:2018-10-29 18:20:3415-16赛季CBA联赛之北京
日期:2018-10-06 21:39:5715-16赛季CBA联赛之天津
日期:2018-08-09 10:30:41ChinaUnix元老
日期:2018-08-03 17:26:00黑曼巴
日期:2018-07-13 09:53:5415-16赛季CBA联赛之吉林
日期:2018-03-30 12:58:4315-16赛季CBA联赛之佛山
日期:2017-12-01 10:26:3815-16赛季CBA联赛之上海
日期:2017-11-14 09:20:5015-16赛季CBA联赛之江苏
日期:2019-02-20 09:53:3319周年集字徽章-庆
日期:2019-08-27 13:23:2515-16赛季CBA联赛之广夏
日期:2019-09-03 18:29:06
发表于 2017-01-23 12:42 |显示全部楼层
本帖最后由 fenyun689 于 2017-01-23 12:45 编辑

肯定是不愿意投钱。高可用方案只是做个样子,给外面看呢。没有真正去做。
没想过真的会出意想不到的情况。
像银行,电信等行业做的还可以。

论坛徽章:
72
20周年集字徽章-20	
日期:2020-10-28 14:04:30操作系统版块每日发帖之星
日期:2016-07-13 06:20:0015-16赛季CBA联赛之广夏
日期:2016-07-10 09:04:02数据库技术版块每日发帖之星
日期:2016-07-09 06:20:00操作系统版块每日发帖之星
日期:2016-07-09 06:20:00数据库技术版块每日发帖之星
日期:2016-07-07 06:20:00操作系统版块每日发帖之星
日期:2016-07-07 06:20:00操作系统版块每日发帖之星
日期:2016-07-04 06:20:00数据库技术版块每日发帖之星
日期:2016-07-03 06:20:00操作系统版块每日发帖之星
日期:2016-07-03 06:20:00数据库技术版块每日发帖之星
日期:2016-07-02 06:20:00操作系统版块每日发帖之星
日期:2016-07-02 06:20:00
发表于 2017-01-23 13:10 |显示全部楼层
难道真是误操作

论坛徽章:
72
20周年集字徽章-20	
日期:2020-10-28 14:04:30操作系统版块每日发帖之星
日期:2016-07-13 06:20:0015-16赛季CBA联赛之广夏
日期:2016-07-10 09:04:02数据库技术版块每日发帖之星
日期:2016-07-09 06:20:00操作系统版块每日发帖之星
日期:2016-07-09 06:20:00数据库技术版块每日发帖之星
日期:2016-07-07 06:20:00操作系统版块每日发帖之星
日期:2016-07-07 06:20:00操作系统版块每日发帖之星
日期:2016-07-04 06:20:00数据库技术版块每日发帖之星
日期:2016-07-03 06:20:00操作系统版块每日发帖之星
日期:2016-07-03 06:20:00数据库技术版块每日发帖之星
日期:2016-07-02 06:20:00操作系统版块每日发帖之星
日期:2016-07-02 06:20:00
发表于 2017-01-23 13:33 |显示全部楼层
可能性1:
这是一起运维人员操作失误与玩忽职守的责任事故。
可能性2:
发生小故障不愿停机维护,带病运行导致事故扩大。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP