mysql表误删回复_程序员误删库后，除了跑路还能怎么办？

虽然很多时候误删库都是运维或者DBA犯的错，这个锅都是应该由他们背。但是有的时候，只要有数据库操作权限的开发人员，都有可能踩到误删库这条红线上。

一般有网友笑称，除了误删库了，除了跑路，还能怎么办？

今天我们来聊一聊，除了跑路，我们还可以做些什么？依MySQL为例。

误删数据，一般分为以下几类。

1.使用 delete 语句误删数据行。

如果是使用delete语句误删的数据，我们可以通过Flashback工具通过闪回把数据恢复过来 。具体怎么操作，在这里就不展开讨论了。

但是需要说明的是，我并不建议你在主库上直接操作。我们可以恢复出一个备份。

2.使用 drop table 或者 truncate table 语句误删数据表或者使用 drop database 语句误删数据库

这种情况下，要想恢复数据，就需要使用全量备份，加增量日志的方式了。这个方案要求线上有定期的全量备份，并且实时备份 binlog。

在这两个条件都具备的情况下，假如有人中午 12 点误删了一个库，恢复数据的流程如下：

a.取最近一次全量备份，假设这个库是一天一备，上次备份是当天 0 点；

b.用备份恢复出一个临时库；

c.从日志备份里面，取出凌晨 0 点之后的日志；

d.把这些日志，除了误删除数据的语句外，全部应用到临时库。

预防误删库/表的方法：

第一：账号分离。

这样做的目的是避免写错命令，比如说。我们只给业务开发人员DML权限，如果业务开发人员有DDL需求的话，那么可以通过系统管理员取得权限。

第二：指定操作规范

这样做的目的是为了避免写错要删除的表名。改表名的时候要在表名上加上固定的前缀或者后缀，并且，删表的时候由管理员统一来删。

3.使用 rm 命令误删整个 MySQL 实例

只要不是恶意地把整个集群删除，而只是删掉了其中某一个节点的数据的话，HA 系统就会开始工作，选出一个新的主库，从而保证整个集群的正常工作。

这时，你要做的就是在这个节点上把数据恢复回来，再接入整个集群。

当然了，现在不止是 DBA 有自动化系统，SA(系统管理员)也有自动化系统，所以也许一个批量下线机器的操作，会让你整个 MySQL 集群的所有节点都全军覆没。

，