当前位置: 首页 > >

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在备库等先进行恢复,防止数据的二次误操作。


误删数据库或者表
    使用最*的全量备份,在一个临时库中进行恢复,或者一个最新的备份快照。从日志备份中,或者该备份后的日志(binlog)。摘除误删除的语句后,全部应用到该临时库。

?


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


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

?


?


?



友情链接: