|
|
本帖最后由 xuexiaogang 于 2017-9-7 10:58 编辑
常在河边站哪有不湿鞋，做数据库没删过库，那么说明经验不够，实战太少。十几年没有误删除过文件或者表，怎么可能？
2015年5月，先是支付宝被一铲子挖断，然后就是携程删库，然后就是股市大跌。有人曾经戏说，携程打算给员工加钱，结果支付宝被挖断了，携程员工没收到，一怒之下删除数据库，结果导致很多要去操盘的人无法定飞机酒店导致股市大跌。
不管什么原因，数据是企业的血液，数据库是心脏。心血都没有了，是很可怕的。企业把这么重要的交到我们手上，我们要慎重再慎重。
2013年我在一个没投入生产的准生产上查问题。通过KVM切换服务器。服务器后面连着存储，有的存储是放文件的，有的存储是放数据库的。看到一个存储连接的不对，通过摸排线路和弹出光驱反复确认这个服务器的存储是放文件的，需要格式化。
格式化完毕，打开所有应用，发现数据库写入报错。通过toad plsql能登录，查询部分表可以，但是有些会报错，表或视图不存在。写入的都报错。通过命令查询部分数据文件丢失。
实在不知道为什么，把实施的人和供应商不断电话，才知道，供应商当时做了个多路径，不管是不是数据库都看得到数据库的存储，但是看不到具体的文件。双方留了这个问题，让我踩了坑。
没有备份，只能重建。好在系统还没正式使用，惊出一身汗。也是从业以来最严重的一次宕机事件。不过即使是真的，也不能跑路啊。改承担责任就承担。不是恶意的，故意的就行。这是本质问题。
现在由于管理的更多数据库了，xshell切来切去，更加注意生产与测试的。堡垒机上异构的数据库，不同版本的还有不同用途的，反复看清再做操作。
越是到后来越对数据库敬畏，时候plsql都不敢点右键，点了右键也是从下往上走，生怕会碰到drop table。
我再补充下，害人之心不可有，防人之心不可无。比如人很靠谱，但是疏忽大意不是这个人的本意。万一删错了呢。
所以建立有备份，但是在互联网场景下，数据这么多，不可能指望着备份来恢复。需要时间不说，更加主要的是业务要中断，而且恢复还不见得能到故障点。所以采用多活和延迟复制这样的技术结合，能有效的防止误操作。
|
|
楼主: mei过大猪
IP卡
狗仔卡
发表于 2017-8-27 21:53
显身卡
，还好是测试哭，后来师傅给恢复了，只不过一些测试数据需要弄，让组里的同事们增加了一些工作，很惭愧，在以后做truancate，delete，drop 等操作都是看了又看，一定要确认确认在确认，dba要有责任心，嘿嘿
