Mysql - 不同级别数据恢复问题

    主要的误删数据的级别误删方式有：

1、delete误删数据；

2、drop table/truncate table 误删数据；

3、drop table 误删数据；

4、rm误删整个数据库实例；

    Mysql的误删操作比较传统的做法就是依赖最近的全量备份数据，根据数据的重要性执行（一天一备、一周一备）获取最新的全量备份数据，用最近全量备份 + 最近的binlog恢复到最新的数据状态。  前面在Mysql - 争取一篇讲清楚Mysql中的锁（全局锁、表级锁、行级锁）及加锁规则、死锁问题中分析过，执行全量备份可以依赖Mysql实例级别的全局锁 Flush tables with read lock（FTWRL），但是如果所有的表都是InnoDB表，则可以利用一致性视图（Read View），使用mysql dump工具进行全量备份。传统方式使用老的快照再执行一遍所有更新过的操作。 

    现在的处理方式是根据当最新的数据【快照】，根据需要回退操作的binlog，使用回退工具将原binlog进行修改（insert改为delete【binlog event 类型从Write_rows event 改成 Delete_rows event】、delete改为insert、update改为update）再执行。可选的工具有大众点评的 MyFlash、阿里的 Flashback（推荐使用）。不论哪种工具实现原理基本一致，都有如下特点：

1、只能处理 binlog为 row模式的 delete、update、insert语句，并且binlog_row_image=FULL；

2、drop table、truncate table等底层的binlog都不是row模式，所以不能恢复这些操作的数据；

 

delete等DML误删除操作

    如果在这类误操作就可以直接用上面的工具，基于binlog在备库等先进行恢复，防止数据的二次误操作。

误删数据库或者表

1. 使用最近的全量备份，在一个临时库中进行恢复，或者一个最新的备份快照。
2. 从日志备份中，或者该备份后的日志（binlog）。
3. 摘除误删除的语句后，全部应用到该临时库。

 

    预防为主，如果你是一个公司的技术负责人，怎么制定一套流程？作为开发相关知道大概的恢复流程就可以了，因为基本这样的操作都是DBA来完成的。只是针对可能误删数据操作，公司应该有一套规范来尽量避免数据误操作，将风险控制在一定范围内，而不是在发生后进行恢复操作，一些建议如下：

1. sql语句应用到生产环境时，都应该进行审核操作；
2. sql_safe_updates=on，delete等语句时都应该带条件防止误操作，如果真的需要删除小表的整张表数据。 where id > 0 ,再配合审核sql操作；
3. 尽量增加备库防止 rm 误操作删除Mysql实例后，现在生产环境Myql集群都是HA高可用的；
4. 搭建延迟备库， CHANGE MASTER TO MASTER_DELAY = N 命令，可以指定这个备库持续保持跟主库有 N 秒的延迟，设置为 3600就表示与主库的延迟1个小时。这样如果是在1个小时之内那么还没有执行误操作，并且减少了数据恢复的时间；
5. 给不同的人员不同的账号权限，即使是DBA平时的使用账号也最好不要有 truncate/drop的权限；
6. 删除表之前需要先对表名进行修改，观察一段时间之后再进行删除操作【线上环境历史比较长，环境复杂，数据库表往往关联比较多，一段时间之后就会暴露没有想到的点】。修改表名可以制定一定的后缀名，比如 for_deleted等，删除的表名必须是该指定的后缀。
7. 经常可以模拟数据恢复，形成肌肉记忆，当真正需要恢复数据时，能快速、正确地处理【真正发生异常时，精神高度紧张，更容易出其他异常】。