不小心删库是一种怎样的体验？ 第1页

我手上的上千台数据库除了硬件会问题外，只出过一次失误导致的问题。

按条来算，从来没以为自己的误操作丢失过一条数据。

讲一讲我们怎么做的。

说实话，

要命的是，不清楚你们为什么会直接操作线上数据库。

更要命的是，不清楚为什么你们能直接有drop的权限。

表结构变更请用单独的管理账号，要review。

随便挑几个例子讲一讲：

不小心删库是一种怎样的体验？ - cv62的回答 - https://www.zhihu.com/question/58802374/answer/327277906

不小心删库是一种怎样的体验？ - 攻城狮不是攻的回答 - https://www.zhihu.com/question/58802374/answer/326580744

不小心删库是一种怎样的体验？ - 付强的回答 - https://www.zhihu.com/question/58802374/answer/327173503

每个数据库都有主从备份，大部分程度上避免硬件问题。

机械硬盘至少raid5。

DB机器只有DBA有权限。

不小心删库是一种怎样的体验？ - 丁三山的回答 - https://www.zhihu.com/question/58802374/answer/327007767

不小心删库是一种怎样的体验？ - 尹尔冲的回答 - https://www.zhihu.com/question/58802374/answer/326896300

每个数据库绝不直接drop表，truncate之前必须有备份，或者直接rename表然后create like，杜绝直接drop，非要drop，则应该把sql写成：rename table to _del_table_20181111之类。

删除删表可以用表文件的最后修改时间来进行二次确认。

业务账号只有CRUD权限，没有drop和alter权限。

这能杜绝你们的大部分删库问题。

重要操作double review，非业务系统造成的DML（一般用来修数据）需要审批才能执行。

不要小看review和审批，这个流程会让人要慎重很多。

不小心删库是一种怎样的体验？ - SuperFashi的回答 - https://www.zhihu.com/question/58802374/answer/327419801

升级版本造成的数据库访问失败，

一般的升级方式是

完全不会有升级失败的问题。

数据恢复成半年前的数据

每天一备，如果业务（代码上）误操作，用binlog恢复，决不能直接恢复数据，备份数据只能用作参考。

不小心删库是一种怎样的体验？ - https://www.zhihu.com/question/58802374/answer/327438719

大家还是互相理解一下，谁也不是每天都要DBA去恢复数据，不熟悉恢复操作也是正常的，

毕竟也不会经常有人误删了表、库去找他们恢复。

不小心删库是一种怎样的体验？ - 未来星老公的回答 - https://www.zhihu.com/question/58802374/answer/327721756

至于我出过的问题：

收编了一个库（原来是业务自己搭建的库，后来统一到我这里）。

因为种种原因要让他们测试一下只读的从库，测试之前我单独看了一下read_only参数，没错是开着的。read_only可以让数据库变成只读状态，无法写入。

开始测试之后发现不对劲，为什么他们的业务是正常的，明明应该出问题。

因为测试的话，该应用用的是laravel框架，laravel框架是会打开一个新的session的，这个session会被持久化到数据库中，用从库测试的话，会无法创建session，应用也就会出问题。

手机开始报警，从库slave线程停止，开始有人反馈有问题，数据库也有异常。

于是赶紧把现在的从库下掉，重做一个新从库。

还好只是个内部业务。

原因也很简单，没注意到这个收编的库很是有所有权限的，包括super权限。

read_only参数只对非super账号起作用，super权限账号仍能写入。

所以从库被写入了不该写入的数据，导致主从同步状态断掉了。

percona5.6和mysql5.7引入了新的参数super_read_only。

回收super权限，再次梳理所有有super权限的账号（只有收编过来的库才有这个问题），统一处理。

如果是个人或者小公司，自己重要操作之前心里要有个ACD数，什么时候该把库设置成只读，什么时候该把库rename掉，某些操作是不是在操作事项里面，某些操作是不是按照步骤来了，能不能避免写入脏数据，如果不能的话，是不是直接禁止写入数据更造成的损失更小，操作之前有没有喝酒，是不是很晚了能不能拖到明天再做，有没有事先制定操作流程，如果没有，有没有口头的double review？

我们程序员自己还是要小心点，不然又要如这位所说，“ HR 机智地把此回答下的所有答主列进了黑名单…… ”

审批、review、备份、预先制定流程、账号权限回收真的能解决这个题目下面大部分的问题。

另：有能力的公司，还是要统一运维统一处理，要有自己的DBA产品，有自己的流程，任何事情（上线、下线、扩容、DDL、DML、切换、等等）都要尽量通过流程解决，这样利远大于弊。

再补几句吧，评论里有人说到“卤煮是大公司的人，根本不懂这一套程序在IT部门只有十几人的小公司是根本玩不转的，什么活都要干，开发、生产运维、测试、需求，blah blah。严格的管理制度能执行才叫做制度，否则只是空谈”。

我也在小公司呆过啊。

制度上做不了，还有其他地方可以做。

就比如这个答案里提到的很多数据库挂了，结果没有备份的情况，没有raid我们可以做主从啊，没有主从可以做冷备啊，最不济我把数据库的binlog打开，恢复的时候用点心也行啊，实在不行，把那几个账号的drop权限给回收了也行啊。

简单说一下这几个操作的难易程度：

组raid：买新机器，迁数据库，重启业务。

binlog：改配置重启数据库。

主从：binlog基础上装mysql新实例，mysqldump导出，导入，配置位点，启动线程。

冷备：mysqldump导出（1条命令），或者xtrabackup导出（1条命令），再配置定时。

回收权限：略。

不是说因为业务繁忙，有些事情就可以省了，不要逃避问题。

我们说的俗一点，这活得你干，出问题了锅得你背，有可能扣你工资吧，顺手搞个一两件事情让自己的损失小一点有怎么了。

不能像大公司那样做标杆，基本操作我学过来一两件，例如我就学个每天定时冷备，你看题目里有多少人说是想恢复结果没备份，导致自己更狼狈了。

说的高端一点，“糊弄糊弄就完事”，不是一个做技术的人应该有的态度。