【大话IT】炉石传说数据库事故，敲响新年的警钟

fantigcy

1结合案例，评估一下你自己的系统会不会出现这种情况，你的备份安全吗？你的备份检查过了吗？
个人认为，暂时不会出现这种情况。没有一个备份是安全的吧，只是定期检查，在测试机恢复测试。
2站在你自己的角度分析（仅仅分析而不做评论），这个可能是什么原因导致的。
仅仅是本地备份，未做远程备份，磁盘损坏就无法恢复
3对于预防这类问题你现在的公司是怎么设计和规避的？
公司数据量很小，只是分磁盘备份，没有做这些方面的设计和规避措施

情殇无恒

DBA最近买了本书叫《教你数据库从入门到删库跑路》

rengo

让你不给dba涨工资发年终奖

听海★蓝心梦

1、结合案例，评估一下你自己的系统会不会出现这种情况，你的备份安全吗？你的备份检查过了吗？
理论上没有人敢100%保证自己的系统不出问题，但是，在可承受范围之内，还是有很多功课可以做。
首先是，数据库备份，以及备份集的验证，确保数据库出问题的时候，有可用的备份集恢复。
另外，对于重要的数据库要做双活，灾备，异地灾备，对于不同级别的故障场景，设计不同级别的灾备方案。确保故障发生时，把损失降到最低。
任何时候都不是平时备份，建好灾备就可以高枕无忧。平时的巡检是确保灾难发生时，灾备方案可以及时被按原计划启动。
平时备份的检查，定期切换演练，都是恢复方案可随时启用的关键保证。

2、站在你自己的角度分析（仅仅分析而不做评论），这个可能是什么原因导致的。
事情发展到这一步，已经不能单单只去分析为什么会发生数据库故障。更值得考虑的时，平时制定的应急方案为什么都不可用了？
为了确保数据库故障时可以及时恢复，我们做了备份，以便在数据库需要恢复时从备份集恢复数据；那数据库备份不可用时，应急方案是什么，或者说，如果制定有效的方案确保保留的备份集是可用的？
数据库异常断电，带病工作了2天，没有做有效的补救，是不是存在一定的侥幸心理。

3、对于预防这类问题你现在的公司是怎么设计和规避的？
其实大家用的技术和方案都是差不多的，都是备份、灾备、双活灯方案。
只不过有的工作做的比较规范，确保所做的每一步都是有效的。而有些公司做的比较肤浅，只知期然不知所以然。
只知道每天备份，却不知道备份集是否可用？备份集存放了一周后是否可用？备份集转移了存储后是否可用？
只知道做了灾备，不知道一年后灾备是否可以正常切换，不知道一年前的灾备切换手册，一年后是否正常可用。

jieyancai

迷倪小魏 发表于 2017-1-20 11:37
关于炉石传说的Oracle数据库故障不要以为你也可以幸免

备份重于一切！！！最近公司也在主导灾备演练事项 ...

按理即使出现坏库，也应该可以通过不完全恢复+14日到16日的归档来追到最新时刻。
文中说故障只恢复到14日，说明归档都坏掉了或者说根本没有备份归档日志？

Ryan-liumin

年底不发红包，大家心情都不好。。。。

marvelsu

1结合案例，评估一下你自己的系统会不会出现这种情况，你的备份安全吗？你的备份检查过了吗？
数据库备份工作肯定要做好的。
2站在你自己的角度分析（仅仅分析而不做评论），这个可能是什么原因导致的。
数据异常需要修复这个情况肯定是有遇到过的，但是案例中没有及时发现是比较严重的。
3对于预防这类问题你现在的公司是怎么设计和规避的？
同城双活、异地容灾。

helonten

感觉像是误操作了

cngd1

感觉是一连串的误操作引发的杯具。猜测开始的时候只是存储出了一点小故障，存储维护人员按照例行的流程进行处理，但是操作过程又出了错，导致存储出现不可逆转的故障，接着导致整个数据库的不一致，然后试图通过DG做切换，结果然并卵，然后就没有然后了。发现这么大的事故的原因，人为因素应该占了比较大的部分，责任心、担当不到位，其次是系统的架构设计，好比前面多位都提到的RAC、DG、备份应该使用独立的存储等等，最后就是应急预案、故障切换演练、备份有效性检查这些应该都是比较欠缺的。

yleizzz

是放在同一个存储上的吧，不然怎么备份都不行了呢