MySQL的delete误操作的快速恢复方法

1. 根据误操作时间定位binlog位置
找到数据库的binlog存放位置，当前正在使用的binlog文件里面就有我们要恢复的数据。一般生产环境中的binlog文件都是几百M乃至上G的大小，我们不能逐行去找被删除的数据在什么位置，所以记住误操作的时间很重要，我们可以通过mysqlbinlog命令的--start-datetime参数快速定位数据位置。比如误操作时间为20181104151800，解析出的binlog内容：

[root@cos7-jiang mysql]# mysqlbinlog -vv --start-datetime='2018-11-04 15:18:00' on.000004|more

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!40019 SET @@session.max_insert_delayed_threads=0*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#700101  8:00:00 server id 1  end_log_pos 120 CRC32 0x199f2da4     Start: binlog v 4, server v 5.6.42-log created 700101  8:00:

00

# Warning: this binlog is either in use or was not closed properly.

BINLOG '

AAAAAA8BAAAAdAAAAHgAAAABAAQANS42LjQyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAaQt

nxk=

'/*!*/;

# at 120

#181104 15:18:37 server id 1  end_log_pos 192 CRC32 0x2224f8de     Query    thread_id=16    exec_time=0    error_code=0

SET TIMESTAMP=1541315917/*!*/;

SET @@session.pseudo_thread_id=16/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1075838976/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C latin1 *//*!*/;

SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 192

#181104 15:18:37 server id 1  end_log_pos 252 CRC32 0x65fbbe3b     Table_map: `test`.`person` mapped to number 85

# at 252

#181104 15:18:37 server id 1  end_log_pos 435 CRC32 0x005d1b39     Delete_rows: table id 85 flags: STMT_END_F

BINLOG '

TZ3eWxMBAAAAPAAAAPwAAAAAAFUAAAAAAAEABHRlc3QABnBlcnNvbgAGAw/+DwMDBgoA/gEKAD47

vvtl

TZ3eWyABAAAAtwAAALMBAAAAAFUAAAAAAAEAAgAG/8ABAAAAAmppATEDd2VyqEA0AGpqyADAAgAA

AANsdW8BMQN3ZXKcQjQAJ2zZAMADAAAAAnl1ATAEamVndfombwA3JyEBwAQAAAACZGEBMAdiZWlq

aW5nOgZQAFfZQADABQAAAAJnagEwB2JlaWppbmcSBlAAh+jOAMAGAAAABHlhbmcBMAduYW5qaW5n

cg5MAIdSqwo5G10A

'/*!*/;

### DELETE FROM `test`.`person`

### WHERE

###   @1=1 /* INT meta=0 nullable=0 is_null=0 */

###   @2='ji' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3='1' /* STRING(1) meta=65025 nullable=1 is_null=0 */

###   @4='wer' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @5=3424424 /* INT meta=0 nullable=1 is_null=0 */

###   @6=13134442 /* INT meta=0 nullable=1 is_null=0 */

### DELETE FROM `test`.`person`

### WHERE

###   @1=2 /* INT meta=0 nullable=0 is_null=0 */

###   @2='luo' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3='1' /* STRING(1) meta=65025 nullable=1 is_null=0 */

###   @4='wer' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @5=3424924 /* INT meta=0 nullable=1 is_null=0 */

###   @6=14248999 /* INT meta=0 nullable=1 is_null=0 */

### DELETE FROM `test`.`person`

### WHERE

###   @1=3 /* INT meta=0 nullable=0 is_null=0 */

###   @2='yu' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */

###   @4='jegu' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @5=7284474 /* INT meta=0 nullable=1 is_null=0 */

###   @6=18949943 /* INT meta=0 nullable=1 is_null=0 */

### DELETE FROM `test`.`person`

### WHERE

###   @1=4 /* INT meta=0 nullable=0 is_null=0 */

###   @2='da' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */

###   @4='beijing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @5=5244474 /* INT meta=0 nullable=1 is_null=0 */

###   @6=4249943 /* INT meta=0 nullable=1 is_null=0 */

### DELETE FROM `test`.`person`

### WHERE

###   @1=5 /* INT meta=0 nullable=0 is_null=0 */

###   @2='gj' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */

###   @4='beijing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @5=5244434 /* INT meta=0 nullable=1 is_null=0 */

###   @6=13559943 /* INT meta=0 nullable=1 is_null=0 */

### DELETE FROM `test`.`person`

### WHERE

###   @1=6 /* INT meta=0 nullable=0 is_null=0 */

###   @2='yang' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */

###   @4='nanjing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @5=4984434 /* INT meta=0 nullable=1 is_null=0 */

###   @6=178999943 /* INT meta=0 nullable=1 is_null=0 */

# at 435

#181104 15:18:37 server id 1  end_log_pos 466 CRC32 0xab85d971     Xid = 197

COMMIT/*!*/;

# at 466

#181104 15:19:38 server id 1  end_log_pos 538 CRC32 0x8b9e1093     Query    thread_id=16    exec_time=0    error_code=0

SET TIMESTAMP=1541315978/*!*/;

BEGIN

/*!*/;

# at 538

#181104 15:19:38 server id 1  end_log_pos 598 CRC32 0xb1679f78     Table_map: `test`.`person` mapped to number 85

# at 598

#181104 15:19:38 server id 1  end_log_pos 656 CRC32 0xa5d7a2d6     Write_rows: table id 85 flags: STMT_END_F

　　通过上面的命令可以比较方便地逐页寻找被删除的数据，我们应该要找到被删除的数据在binlog中的起始和终止位置点，例如上面的被删除数据的位置点在192和435之间，这样我们可以保证在这两个位置之间只有我们需要的待恢复的数据，而没有其他数据。

本次测试的数据量很小，如果一张表有数十万行数据被误删除，我们通过上面的方式找位置点是很费时间的。这时可以通过下面的两个命令锁定起始和终止位置：
确定起始位置点：

mysqlbinlog -vv --start-datetime='2018-11-04 15:18:00' on.000004| head -1000 |more

　　确定终止位置点：

mysqlbinlog -vv --start-datetime='2018-11-04 15:18:00' --stop-datetime='2018-11-04 15:20:00' on.000004| tail -1000 |more

　　我们只看binlog输出的前N行和后N行，来找到起始和终止位置，这样可以大大节省时间。

三、将binlog里的delete语句转化为insert语句
Binlog是二进制文件，我们可以先把待恢复数据导出为可阅读文本：

mysqlbinlog -vv --start-position=192 --stop-position=435 on.000004 |grep ^"###" >/tmp/bin_data

接下来就是处理/tmp/bin_data文本，将里面的delete语句转化为insert语句，可以通过下面的语句实现转化：

cat /tmp/bin_data | sed -n '/###/p' | sed 's/### //g;s/\/\*.*/,/g;s/DELETE FROM/INSERT INTO/g;s/WHERE/SELECT/g;' |sed -r 's/(@6.*),/\1;/g' | sed 's/@[1-9]=//g' | sed 's/@[1-9][0-9]=//g' >/tmp/person.sql

四、将insert语句导入数据库中
Delete语句误操作只会删除表数据，而表结构还在。所以我们可以直接将文本里的insert语句导入到数据库中，即可完成数据恢复：

mysql -h127.0.0.1 -P3306 -uroot -p123 < /tmp/person.sql

补充和总结：
1、以上操作只针对delete误操作有效，且binlog模式是行模式；如果是drop或者truncate语句造成的误操作，亦或者binlog不是row模式，在binlog文件里是找不到完整的被删除数据，这个时候可以考虑通过备份进行恢复；
2、如果在误操作很久之后才意识到数据被误删除，记不清误操作的大致时间，那么可以找到误操作所在的binlog文件，将binlog解析为可阅读文本形式，然后借助文本编辑命令找误操作位置，再恢复；如果这种方式很慢的话，可以考虑通过备份恢复，或者从别的环境中导出这张表的数据再导入到当前环境中；
3、Mysqlbinlog命令重要参数
-vv 将二进制转换为可阅读文本
--start-datetime 起始时间
--stop-datetime 终止时间
--start-position 起始位置
--stop-position 终止位置
--base64-output=decode-row 查看最底层DML语句数据模块，前提是数据库参数binlog_rows_query_log_events打开
4、熟悉linux的文本编辑命令，如grep、sed、awk等
5、虽然binlog2sql工具也可以快速解析binlog，生成回滚SQL，但只要清楚上面的命令和操作流程，恢复速度也不会比binlog2sql慢很多，更何况如果环境没有安装这个工具。

[root@cos7-jiang mysql]# mysqlbinlog -vv --start-datetime='2018-11-04 15:18:00' on.000004|more
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#700101 8:00:00 server id 1 end_log_pos 120 CRC32 0x199f2da4 Start: binlog v 4, server v 5.6.42-log created 700101 8:00:
00
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
AAAAAA8BAAAAdAAAAHgAAAABAAQANS42LjQyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAaQt
nxk=
'/*!*/;
# at 120
#181104 15:18:37 server id 1 end_log_pos 192 CRC32 0x2224f8de Query thread_id=16 exec_time=0 error_code=0
SET TIMESTAMP=1541315917/*!*/;
SET @@session.pseudo_thread_id=16/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 192
#181104 15:18:37 server id 1 end_log_pos 252 CRC32 0x65fbbe3b Table_map: `test`.`person` mapped to number 85
# at 252
#181104 15:18:37 server id 1 end_log_pos 435 CRC32 0x005d1b39 Delete_rows: table id 85 flags: STMT_END_F
BINLOG '
TZ3eWxMBAAAAPAAAAPwAAAAAAFUAAAAAAAEABHRlc3QABnBlcnNvbgAGAw/+DwMDBgoA/gEKAD47
vvtl
TZ3eWyABAAAAtwAAALMBAAAAAFUAAAAAAAEAAgAG/8ABAAAAAmppATEDd2VyqEA0AGpqyADAAgAA
AANsdW8BMQN3ZXKcQjQAJ2zZAMADAAAAAnl1ATAEamVndfombwA3JyEBwAQAAAACZGEBMAdiZWlq
aW5nOgZQAFfZQADABQAAAAJnagEwB2JlaWppbmcSBlAAh+jOAMAGAAAABHlhbmcBMAduYW5qaW5n
cg5MAIdSqwo5G10A
'/*!*/;
### DELETE FROM `test`.`person`
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='ji' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @3='1' /* STRING(1) meta=65025 nullable=1 is_null=0 */
### @4='wer' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @5=3424424 /* INT meta=0 nullable=1 is_null=0 */
### @6=13134442 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
### @1=2 /* INT meta=0 nullable=0 is_null=0 */
### @2='luo' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @3='1' /* STRING(1) meta=65025 nullable=1 is_null=0 */
### @4='wer' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @5=3424924 /* INT meta=0 nullable=1 is_null=0 */
### @6=14248999 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @2='yu' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
### @4='jegu' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @5=7284474 /* INT meta=0 nullable=1 is_null=0 */
### @6=18949943 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
### @1=4 /* INT meta=0 nullable=0 is_null=0 */
### @2='da' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
### @4='beijing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @5=5244474 /* INT meta=0 nullable=1 is_null=0 */
### @6=4249943 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
### @1=5 /* INT meta=0 nullable=0 is_null=0 */
### @2='gj' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
### @4='beijing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @5=5244434 /* INT meta=0 nullable=1 is_null=0 */
### @6=13559943 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
### @1=6 /* INT meta=0 nullable=0 is_null=0 */
### @2='yang' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
### @4='nanjing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
### @5=4984434 /* INT meta=0 nullable=1 is_null=0 */
### @6=178999943 /* INT meta=0 nullable=1 is_null=0 */
# at 435
#181104 15:18:37 server id 1 end_log_pos 466 CRC32 0xab85d971 Xid = 197
COMMIT/*!*/;
# at 466
#181104 15:19:38 server id 1 end_log_pos 538 CRC32 0x8b9e1093 Query thread_id=16 exec_time=0 error_code=0
SET TIMESTAMP=1541315978/*!*/;
BEGIN
/*!*/;
# at 538
#181104 15:19:38 server id 1 end_log_pos 598 CRC32 0xb1679f78 Table_map: `test`.`person` mapped to number 85
# at 598
#181104 15:19:38 server id 1 end_log_pos 656 CRC32 0xa5d7a2d6 Write_rows: table id 85 flags: STMT_END_F

MySQL的delete误操作的快速恢复方法的更多相关文章

MySQL【Delete误操作】数据恢复【转】
前言: 操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和binlog差来恢复,等不了,很费时.这里先说明下因为Delete 操作的恢复方法 ...
MySQL【Update误操作】回滚（转)
前言: 继上一篇MySQL[Delete误操作]回滚之后,现在介绍下Update回滚,操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和bi ...
MySQL中truncate误操作后的数据恢复案例
MySQL中truncate误操作后的数据恢复案例这篇文章主要介绍了MySQL中truncate误操作后的数据恢复案例,主要是要从日志中定位到truncate操作的地方然后备份之前丢失的数据,需要的 ...
SQLServer 2008以上误操作数据库恢复方法——日志尾部备份(转)
问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这 ...
[转]SQLServer 2008以上误操作数据库恢复方法——日志尾部备份
原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题: 经常看到有人误删数据,或者误操作,特别是update和delete的 ...
Mysql MGR架构误操作引发的问题处理
[背景介绍] 故障方描述:一次用户刷权限的时候不小心把数据库用户表记录删掉了,执行之后发现不对后重建用户,杀掉进程后重新MGR启动报错. [报错信息] 2018-06-13T12:47:41.4055 ...
SQLServer 2008以上误操作数据库恢复方法
解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持20 ...
SQL Server 2008以上误操作数据库恢复方法——日志尾部备份
原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题: 经常看到有人误删数据,或者误操作,特别是update和delete的 ...
SQLServer 2008以上误操作数据库恢复方法—日志尾部备份
原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题: 经常看到有人误删数据,或者误操作,特别是update和delete的 ...

随机推荐

Linux下安装redis报错信息
redis在Linux安装报错标签: redislinuxcentos 2017-02-24 13:46 384人阅读评论(0) 收藏举报分类: Linux安装工具(2) 版权声明:本文为 ...
给Java0基础的五个学习的思路?
关于Java初学者来说,想学习Java教程,需求了解,根底打好才干学得更好,Java教程之学习Java的路线图的五个必经阶段,希望能对Java学习者有所帮忙. 第一个阶段-java根底阶段 1.jav ...
实时聊天-websocket与ajax的区别于联系
Ajax是什么? Ajax,即异步JavaScript和XML,是一种创建交互式网页应用的网页开发技术.通过在后台与服务器进行少量数据交换,Ajax可以使网页实现异步更新,这意味着可以在不重新加载整 ...
IT兄弟连 HTML5教程了解HTML5的主流应用1
在很多人眼里,HTML5与互联网营销密切相关,但其实从开发者的角度而言,它是一种网页标准,定义了浏览器语言的编写规范.伴随HTML5标准尘埃落定,浏览器对HTML5特性的逐步支持,再加上国内对HTML ...
【文本处理命令】之sed命令详解
sed行处理命令详解一.简介 sed命令是一种在线编辑器.一个面向字符流的非交互式编辑器,也就是说sed不允许用户与它进行交互操作.sed是按行来处理文本内容的,它一次处理一行内容.处理时,把当前处 ...
POJ 1724 （分层图最短路）
### POJ 1724 题目链接 ### 题目大意: 给你 N 个点 ,M 条有向路,走每条路需要花费 C 元,这段路的长度为 L . 给你 K 元,问你能否从 1 走到 N 点且花费不超过 K 元 ...
安全NA第一天笔记：Firewall基本理论
防火墙的三种类型:<1>包过滤(packet filtering):也就是我们常用的访问控制列表(ACL)1.ACL类型:标准,扩展,命名,自反2.ACL其他特性:(1)重新排列序列号: ...
poj-3682 King Arthur's Birthday Celebration
C - King Arthur's Birthday Celebration POJ - 3682 King Arthur is an narcissist who intends to spare ...
Swagger UI in AspNetCore WebAPI
Swagger其实包含了三个部分,分别是Swagger Editor文档接口编辑器,根据接口文档生成code的Swagger Codegen,以及生成在线文档的Swagger UI.在AspNetCo ...
RAID 独立磁盘冗余阵列 - redundant array of independent disks
RAID: RAID全称是独立磁盘冗余阵列(Redundant Array of Independent Disks),基本思想是把多个磁盘组合起来,组合一个磁盘阵列组,使得性能大幅提高. RAID ...

MySQL的delete误操作的快速恢复方法

MySQL的delete误操作的快速恢复方法的更多相关文章

随机推荐

热门专题