MySQL中truncate误操作后的数据恢复案例
MySQL中truncate误操作后的数据恢复案例
实际线上的场景比较复杂,当时涉及了truncate, delete 两个操作,经确认丢数据差不多7万多行,等停下来时,差不多又有共计1万多行数据写入。 这里为了简单说明,只拿弄一个简单的业务场景举例。
测试环境: Percona-Server-5.6.16
日志格式: mixed 没起用gtid
表结构如下:
|
1
2
3
4
5
6
7
8
9
10
11
|
CREATE TABLE `tb_wubx` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(32) DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 CREATE TABLE `tb_wubx` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(32) DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 |
基于某个时间点有一个备份或是有全量的binlog是能恢复数据的一个唯一保证。 例如我们的备份就是一个表结构创建语句,binlog pos相关信息: mysql-bin.000004 , 4,然后进行了如下:
–t1时间 程序写入:
|
1
2
|
insert into tb_wubx(name) values(‘张三'),(‘李四');insert into tb_wubx(name) values(‘隔壁老王'); |
–t2时间 某个人员失误
|
1
|
truncate table tb_wubx; |
–t3时间 程序写入
|
1
2
|
insert into tb_wubx(name) values(‘老赵');update tb_wubx set name='老赵赵' where id=1; |
现在表里的数据情况:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
mysql>select * from tb_wubx;+----+-----------+| id | name |+----+-----------+| 1 | 老赵赵 |+----+-----------+1 row in set (0.00 sec) mysql>select * from tb_wubx;+----+-----------+| id | name |+----+-----------+| 1 | 老赵赵 |+----+-----------+1 row in set (0.00 sec) |
可以见truncate table操作后,表的自增id又变更为从1开始,原来写入的数据应该是:
|
1
2
3
4
5
6
7
8
9
|
+—-+———–+| id | name |+—-+———–+| 1 | 张三 |+—-+———–+| 2 | 李四 |+—-+———–+| 3 | 隔壁老王 |+—-+———–+ |
如果没生truncate table操作,实际的数据应该为:
|
1
2
3
4
5
6
7
8
9
10
11
|
+—-+———–+| id | name |+—-+———–+| 1 | 张三 |+—-+———–+| 2 | 李四 |+—-+———–+| 3 | 隔壁老王 |+—-+———–+| 4 | 老赵赵 |+—-+———–+ |
而且线上的恢复那个表时和序序开发人员了解才知道,原来那个id和缓存及其它地方有依赖,因为id乱了,也会造成程序错乱。这个时间修复id在程序层错乱的事,留给开发人员了关建是给他们讲明白恢复的结果是什么样,我们的关建任务是把数据恢复出来。好,接下来的工作是开始从binlog中恢复数据。
利用: show binary logs; 查看当的log文件分布, 然后利用show binlog events in ‘binary log文件'; 查看log文件的内容,目的是找到truncate发生的日志位置。
另外因为基于备份(由log的启始位置)或是从量log, 如果基于备份有log的起始位置,我们需要处理的log文件是启始位置到发生truncate的日值(后面的数据处理不了,会发生主建冲突的错误造成truncate后的数据不能恢复),
如果是全量日志,需要从创建完mysql后库后的日志去处理到当前的发生truncate的位置(后面数据会因为主建冲突写不进去)
恢复准备工作,创建一个库用于恢复数据,这里创建了一个re_wubx, 及原结构的表: tb_wubx (相当于恢复了备份,过程省略)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
mysql> show binary logs;+------------------+-----------+| Log_name | File_size |+------------------+-----------+| mysql-bin.000001 | 143 || mysql-bin.000002 | 261 || mysql-bin.000003 | 562 || mysql-bin.000004 | 1144 |+------------------+-----------+4 rows in set (0.00 sec) mysql> show binary logs;+------------------+-----------+| Log_name | File_size |+------------------+-----------+| mysql-bin.000001 | 143 || mysql-bin.000002 | 261 || mysql-bin.000003 | 562 || mysql-bin.000004 | 1144 |+------------------+-----------+4 rows in set (0.00 sec) |
我这里有一个备份文件就是那个创建表的sql语句,位置是mysql-bin.000004 , 4
在这个案例里我只用cover住mysql-bin.000004这个文件。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
mysql>show binlog events in 'mysql-bin.000004';+------------------+------+-------------+-----------+-------------+----------------------------------------------------+| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |+------------------+------+-------------+-----------+-------------+----------------------------------------------------+| mysql-bin.000004 | 4 | Format_desc | 753306 | 120 | Server ver: 5.6.16-64.2-rel64.2-log, Binlog ver: 4 || mysql-bin.000004 | 120 | Query | 753306 | 209 | use `wubx`; truncate table tb_wubx || mysql-bin.000004 | 209 | Query | 753306 | 281 | BEGIN || mysql-bin.000004 | 281 | Table_map | 753306 | 334 | table_id: 91 (wubx.tb_wubx) || mysql-bin.000004 | 334 | Write_rows | 753306 | 393 | table_id: 91 flags: STMT_END_F || mysql-bin.000004 | 393 | Xid | 753306 | 424 | COMMIT /* xid=1073 */ || mysql-bin.000004 | 424 | Query | 753306 | 496 | BEGIN || mysql-bin.000004 | 496 | Table_map | 753306 | 549 | table_id: 91 (wubx.tb_wubx) || mysql-bin.000004 | 549 | Write_rows | 753306 | 602 | table_id: 91 flags: STMT_END_F || mysql-bin.000004 | 602 | Xid | 753306 | 633 | COMMIT /* xid=1074 */ || mysql-bin.000004 | 633 | Query | 753306 | 722 | use `wubx`; truncate table tb_wubx || mysql-bin.000004 | 722 | Query | 753306 | 794 | BEGIN || mysql-bin.000004 | 794 | Table_map | 753306 | 847 | table_id: 92 (wubx.tb_wubx) || mysql-bin.000004 | 847 | Write_rows | 753306 | 894 | table_id: 92 flags: STMT_END_F || mysql-bin.000004 | 894 | Xid | 753306 | 925 | COMMIT /* xid=1081 */ || mysql-bin.000004 | 925 | Query | 753306 | 997 | BEGIN || mysql-bin.000004 | 997 | Table_map | 753306 | 1050 | table_id: 92 (wubx.tb_wubx) || mysql-bin.000004 | 1050 | Update_rows | 753306 | 1113 | table_id: 92 flags: STMT_END_F || mysql-bin.000004 | 1113 | Xid | 753306 | 1144 | COMMIT /* xid=1084 */ |+------------------+------+-------------+-----------+-------------+----------------------------------------------------+19 rows in set (0.00 sec) mysql>show binlog events in 'mysql-bin.000004';+------------------+------+-------------+-----------+-------------+----------------------------------------------------+| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |+------------------+------+-------------+-----------+-------------+----------------------------------------------------+| mysql-bin.000004 | 4 | Format_desc | 753306 | 120 | Server ver: 5.6.16-64.2-rel64.2-log, Binlog ver: 4 || mysql-bin.000004 | 120 | Query | 753306 | 209 | use `wubx`; truncate table tb_wubx || mysql-bin.000004 | 209 | Query | 753306 | 281 | BEGIN || mysql-bin.000004 | 281 | Table_map | 753306 | 334 | table_id: 91 (wubx.tb_wubx) || mysql-bin.000004 | 334 | Write_rows | 753306 | 393 | table_id: 91 flags: STMT_END_F || mysql-bin.000004 | 393 | Xid | 753306 | 424 | COMMIT /* xid=1073 */ || mysql-bin.000004 | 424 | Query | 753306 | 496 | BEGIN || mysql-bin.000004 | 496 | Table_map | 753306 | 549 | table_id: 91 (wubx.tb_wubx) || mysql-bin.000004 | 549 | Write_rows | 753306 | 602 | table_id: 91 flags: STMT_END_F || mysql-bin.000004 | 602 | Xid | 753306 | 633 | COMMIT /* xid=1074 */ || mysql-bin.000004 | 633 | Query | 753306 | 722 | use `wubx`; truncate table tb_wubx || mysql-bin.000004 | 722 | Query | 753306 | 794 | BEGIN || mysql-bin.000004 | 794 | Table_map | 753306 | 847 | table_id: 92 (wubx.tb_wubx) || mysql-bin.000004 | 847 | Write_rows | 753306 | 894 | table_id: 92 flags: STMT_END_F || mysql-bin.000004 | 894 | Xid | 753306 | 925 | COMMIT /* xid=1081 */ || mysql-bin.000004 | 925 | Query | 753306 | 997 | BEGIN || mysql-bin.000004 | 997 | Table_map | 753306 | 1050 | table_id: 92 (wubx.tb_wubx) || mysql-bin.000004 | 1050 | Update_rows | 753306 | 1113 | table_id: 92 flags: STMT_END_F || mysql-bin.000004 | 1113 | Xid | 753306 | 1144 | COMMIT /* xid=1084 */ |+------------------+------+-------------+-----------+-------------+----------------------------------------------------+19 rows in set (0.00 sec) |
看到这个表刚开始就发生一次truncate, 那其实也可以说明我就恢复刚开始那个truncate到后来那个误操作的truncate table的语句之间的数据就是丢失的数据。
这个恢复可以从mysql-bin.000004 pos: 4到mysql-bin.000004 pos: 633 即:
|
1
2
3
4
|
mysqlbinlog --rewrite-db='wubx->re_wubx' --start-position=4 --stop-position=633 mysql-bin.000004 |mysql -S /tmp/mysql.sock re_wubxmysqlbinlog --rewrite-db='wubx->re_wubx' --start-position=4 --stop-position=633 mysql-bin.000004 |mysql -S /tmp/mysql.sock re_wubx |
恢复结果如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
mysql -S /tmp/mysql.sock re_wubx;mysql>select count(*) from tb_wubx;+----------+| count(*) |+----------+| 3 |+----------+1 row in set (0.02 sec)mysql>select * from tb_wubx;+----+--------------+| id | name |+----+--------------+| 1 | 张三 || 2 | 李四 || 3 | 隔壁老王 |+----+--------------+3 rows in set (0.00 sec)mysql>insert into tb_wubx(name) select name from wubx.tb_wubx;Query OK, 1 row affected (0.00 sec)Records: 1 Duplicates: 0 Warnings: 0mysql> rename table wubx.tb_wubx to wubx.bak_tb_wubx;Query OK, 0 rows affected (0.04 sec)mysql> rename table re_wubx.tb_wubx to wubx.tb_wubx;Query OK, 0 rows affected (0.03 sec)mysql> select * from wubx.tb_wubx;+----+--------------+| id | name |+----+--------------+| 1 | 张三 || 2 | 李四 || 3 | 隔壁老王 || 4 | 老赵赵 |+----+--------------+4 rows in set (0.00 sec) mysql -S /tmp/mysql.sock re_wubx;mysql>select count(*) from tb_wubx;+----------+| count(*) |+----------+| 3 |+----------+1 row in set (0.02 sec) mysql>select * from tb_wubx;+----+--------------+| id | name |+----+--------------+| 1 | 张三 || 2 | 李四 || 3 | 隔壁老王 |+----+--------------+3 rows in set (0.00 sec) mysql>insert into tb_wubx(name) select name from wubx.tb_wubx;Query OK, 1 row affected (0.00 sec)Records: 1 Duplicates: 0 Warnings: 0 mysql> rename table wubx.tb_wubx to wubx.bak_tb_wubx;Query OK, 0 rows affected (0.04 sec) mysql> rename table re_wubx.tb_wubx to wubx.tb_wubx;Query OK, 0 rows affected (0.03 sec) mysql> select * from wubx.tb_wubx;+----+--------------+| id | name |+----+--------------+| 1 | 张三 || 2 | 李四 || 3 | 隔壁老王 || 4 | 老赵赵 |+----+--------------+4 rows in set (0.00 sec) |
恢复完成。
MySQL中truncate误操作后的数据恢复案例的更多相关文章
- MySQL 误操作后数据恢复(update,delete忘加where条件)【转】
在数据库日常维护中,开发人员是最让人头痛的,很多时候都会由于SQL语句 写的有问题导致服务器出问题,导致资源耗尽.最危险的操作就是在做DML操作的时候忘加where条件,导致全表更新,这是作为运维或者 ...
- MySQL误操作后如何快速恢复数据
基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了 ...
- MySQL 误操作后如何快速恢复数据~!~!~
基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了 ...
- MySQL误操作后如何快速回滚(转)
本文转自http://www.cnblogs.com/dfcao/p/6147970.html#undefined 感谢作者 基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,My ...
- MySQL误操作后如何快速恢复数据?
摘要: 利用binlog闪回误操作数据. 基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如 ...
- MySQL【Update误操作】回滚(转)
前言: 继上一篇MySQL[Delete误操作]回滚之后,现在介绍下Update回滚,操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和bi ...
- mysql中的union操作(整理)
mysql中的union操作(整理) 一.总结 一句话总结: union两侧的字段数和字段类型要是一样的 union可以接多个 orderby和排序可以在最后的union组合之后 1.union简单实 ...
- MySQL中的分页操作结合python
mysql中的分页操作结合python --分页: --方式1: ;-- 读取十行 , --从第十行读取 往后再读十行 --方式2: offset ; --从第二十行开始读取10行 -- 结合pyth ...
- mysql中的正则操作 匹配手机号,匹配中文,替换
mysql中的正则操作 匹配手机号,匹配中文,替换 正则匹配hy_user表内tel字段的电话号码: SELECT * FROM hy_user WHERE tel REGEXP "[1][ ...
随机推荐
- 【报错】The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
提交表单之后, 报错页面显示: HTTP Status 404 – 未找到 Type Status Report 消息 Not found 描述 The origin server did not f ...
- android handler 调用原理
1,调度原理 andriod提供了Handler 和 Looper 来满足线程间的通信.Handler先进先出原则.Looper类用来管理特定线程内对象之间的消息交换(MessageExchange) ...
- 【Jmeter】利用Jmeter+ant+Jenkins 搭建 接口&性能测试 持续集成平台
https://www.jianshu.com/p/6ab73a95d53e https://yq.aliyun.com/articles/664329
- python常用模块---collections、time、random、os、sys、序列号模块
collections模块 在内置数据类型(dict.list.set.tuple)的基础上,collections模块还提供了几个额外的数据类型:Counter.deque.defaultdict. ...
- js本地时间格式化
var myDate = new Date(); //获取当前时间及日期 var year=myDate.getYear(); // 获取当前年份(当前年份-1900) var fyear=myDat ...
- Error: webpack.optimize.UglifyJsPlugin has been removed, please use config.optimizat
按照教程上配置文件如下: var webpack=require('webpack'); var HtmlwebpackPlugin=require('html-webpack-plugin'); v ...
- ReactNative出现错误问题'React/RCTAssert.h' file not found
今天搭建一个rn的项目,项目可以运行但就是报一个错误, 查阅是由于Pods里的React结构改变了,配置没有改过来,所以出现找不到文件的问题 修改search paths 中 header searc ...
- ASE Alpha Sprint - backend scrum 7
本次scrum于2019.11.12在sky garden进行,持续30分钟. 参与人: Zhikai Chen, Jia Ning, Hao Wang 请假: Xin Kang, Lihao Ran ...
- 2018-2-13-win10-uwp-分治法
title author date CreateTime categories win10 uwp 分治法 lindexi 2018-2-13 17:23:3 +0800 2018-2-13 17:2 ...
- Notepad++安装Zen Codingt插件
Zen Coding介绍 Zen Coding是一套面向文本编辑器的插件,它允许通过IDE工具的联想功能(内容辅助)高速度的编辑HTML.XML.XSL和其他结构化的代码格式. Zen Coding由 ...