今天你检查备份了吗?

简介: 今天你检查备份了吗?

0、导读

《炉石传说》游戏数据库回档事件反思

本文约900字,阅读时间约5分钟。

今天引爆各大技术群的事情就是网易游戏《炉石传说》游戏数据库发生宕机并引发数据丢失事故,最终决定回档并后续补偿玩家损失。详情可见官网公告:http://hs.blizzard.cn/articles/16/8565

我以前也在搜狐畅游(http://www.changyou.com,NASDAQ:CYOU)负责游戏数据库维护,也遇到过因为服务器故障最终导致回档的事故,不过都没像这次炉石搞这么大动作。在这里我并不想借机调侃消费他们或搞营销,只想和大家一起聊聊作为DBA,应该注意哪些事。

我们从公告的内容中,我们看到了几个问题:

  1. 公告发布时间是2017.1.18 18点,决定回档到2017.1.14 15:20,中间这段时间难道一直都在尝试恢复数据库,就不能快速做出决策尽快直接回档吗,这是在考验游戏玩家的耐心,很容易引发玩家的“群体事件”;
  2. 因为供电意外导致故障,并造成数据库损坏,如果也用MySQL数据库的话,看起来应该是没开启双1设置,并且有可能还在使用老式的锂电池BBU。所以断电后很容易导致阵列卡cache中的数据丢失,数据库也跟着损坏,以前没少才踩这个坑;
  3. 连备份数据库也发生故障,有点不可思议,这样就容易让人产生是人为事故的联想了。不过,我多年前也发生过类似的情况,不过那次是因为用mysqldump备份时指定了错误的字符集,并且在做备份恢复测试时没严格测试数据的有效性,致使发生故障时不能正常恢复,结果也悲剧了。作为不了解内情的局外人,只能以官方公告为准,无要无端臆测;

关于服务器可靠性以及数据库备份,有几点建议:

  1. 必须定期全备,并且优先推荐物理备份,逻辑备份通常相对更慢。一般至少每天一次全备;
  2. 每小时一次增备或差异备份,我以前的做法是开binlog,并且利用last_update_time列特征每小时做一次差异备份。这样我要恢复的话,一般最多只损失不到一个小时的数据;
  3. 备份文件务必进行恢复测试,如果有多个备份集,可以采用随机抽取的方式做恢复测试,但一定要保证所有实例的备份最终都会被验证一次;
  4. 必须监控服务器硬件健康状况,包括CPU、内存、阵列卡、阵列卡电池等部件,以及服务器温度等。我们曾经有在哈尔滨及西安某机房的服务器,一到夏天就很容易因为温度过高而引发自动重启😓😓 我们的解决方案就是利用监控,提前预警,及早通知机房打开机柜门并且安排散热,比如很low的放着风扇对服务器吹啊吹 😓😓

快过年了,做运维的同学应该也都差不多做完全服巡检了吧,先祝大家春节快乐,鸡年吉祥,新的一年服务器宕机率减少99%😄😄

相关文章
|
2月前
|
测试技术 数据库 数据安全/隐私保护
测试备份
测试备份
28 2
|
6月前
|
安全
linuxdd命令备份与恢复
`dd`命令实例:用于备份/恢复磁盘,如`dd if=/dev/hdb of=/dev/hdd`复制整个硬盘。还能压缩备份(`dd if=/dev/hdb | gzip > /root/image.gz`)、恢复(`gzip -dc /root/image.gz | dd of=/dev/hdb`)、备份MBR(`dd if=/dev/hda of=/root/image count=1 bs=512`)、创建swap分区(`dd if=/dev/zero of=/swapfile`)
132 1
|
存储 安全 容灾
备份方式
备份方式
205 0
|
运维 监控 关系型数据库
今天你检查备份了吗?
今天你检查备份了吗?
102 0
|
关系型数据库 MySQL 数据库
|
MySQL 关系型数据库 Perl