MySQL误删数据救命指南

MySQL误删数据救命指南

导读：

已经安排了休假计划。在这前几天，已经把一个新项目的数据库环境都部署好了，包括自动化备份。

等我出去玩的时候，悲剧发生了，业务要求进行数据回滚，但发现备份文件不可用，原因是 备份时指定的字符集和表字符集不一致。
我勒个擦，原来该项目采用新的字符集，但是我没有认真检查确认并修改备份脚本，结果导致备份失效。最后，当季度绩效结果被降档。

不知道各位都亲手造了啥大故障，排名最前的几种是：

    误删文件。
    误删库、表。
    错误全表删除 / 更新。
    升级操作失误。

先说几点我平时预防误操作导致文件/数据丢失不成熟的建议：

（1）欲删除文件时，将rm命令改成mv，可在系统层面将rm命令做个alias（或参考Windows / Mac OSX做法，删除文件时先进回收站）。
（2）删除数据库、表时，不要用drop命令，而是rename到一个专用归档库里；
（3）删除表中数据时，不要直接用delete或truncate命令，尤其是truncate命令，目前不支持事务，无法回滚。
（4）用delete命令删除数据时，应当先显式开启事务，这样误操作时，还有机会进行回滚。
（5）要大批量删除数据时，可以将这些数据insert...select到一个新表，确认无误后再删除。或者反其道行之，把要保留的数据写到新表，然后将表重命名对掉。
（6）执行重要命令之前，先准备好相关命令，再三确认无误才之行。

虽说现在大部分操作可以靠平台来完成了，但平台也不是万能的，不也发生过平台本身的缺陷造成数据丢失、代码回滚、部署失误等事故嘛，我就不点名了。

做好备份，不管是物理备份还是逻辑备份！

说完预防措施，我们再说万一发生误操作时，怎么以最快速度进行补救。 我们分别列举几种常见的情况：

（1）执行DROP DATABASE / DROP TABLE命令误删库表，如果碰巧采用共享表空间模式的话，还有恢复的机会。如果没有，请直接从备份文件恢复吧。你连备份文件都没有？那麻烦退出DBA届吧，一个连备份都懒得做的人，不配成为DBA的。

（2）采用共享表空间模式下，误删后立刻杀掉（kill -9）mysql相关进程（mysqld_safe、mysqld），然后尝试从ibdataX文件中恢复数据。

（3）误删除正在运行中的MySQL表ibd或ibdataX文件。请立即申请对该实例进行维护，当然，不是指把实例关闭，而是把业务暂停，或者把该实例从线上环境摘除，
不再写入新数据，然后利用linux系统的proc文件特点，把该ibd文件从内存中拷出来，再进行恢复，因为此时mysqld实例在内存中是保持打开该文件的，
切记这时不要把mysqld实例关闭了。

（4）把复制出来的ibdataX或ibd文件拷贝回datadir后，重启mysqld进入recovery模式，innodb_force_recovery 选项从 0 - 6 逐级测试，直至能备份出（整个实例或单表的）所有数据后，再重建实例（或单表），恢复数据。

（5）未开启事务模式下，执行delete误删数据。意识到后立即将mysqld（以及mysqld_safe）进程杀掉（kill -9），不要任何犹豫，然后再用工具将表空间数据读取出来。
因为执行delete删除后，实际数据并没被物理清除，只是先打上deleted-mark标签，后续再统一清理，因此还有时间差。
（5.6及以前可以用percona innodb data recovery tool，5.7起应该不支持了，确实得靠全备+binlog恢复比较靠谱了）

（6）执行truncate误清整表。如果没使用共享表空间模式的话，基本别想了，走备份恢复+binlog吧。
执行不带where条件的update，或者update错数据。也别费劲了，走备份恢复+binlog吧。

还有：

innodb引擎，重装前把数据库整个目录备份了，以为和myisam一样，考回去就可以继续浪了，结果sb了。

如果你想cp数据目录，达到备份的目的，1：先关闭mysqld，然后再cp，就是OK的。注意只能恢复到备份那个版本。

2.flush tables with read lock; 然后 flush logs;来保证数据目录的数据是一致的，再cp文件，完成之后，

再执行flush tables释放锁。