MySQL中truncate误操作后的数据恢复案例

2024-07-24 12:46:08

字体：大中小

来源：转载

供稿：网友

实际线上的场景比较复杂，当时涉及了truncate, delete 两个操作，经确认丢数据差不多7万多行，等停下来时，差不多又有共计1万多行数据写入。这里为了简单说明，只拿弄一个简单的业务场景举例。

测试环境： Percona-Server-5.6.16
日志格式： mixed 没起用gtid

表结构如下：

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时间程序写入：

insert into tb_wubx(name) values(‘张三'),(‘李四');insert into tb_wubx(name) values(‘隔壁老王');

–t2时间某个人员失误

truncate table tb_wubx;

–t3时间程序写入

insert into tb_wubx(name) values(‘老赵');update tb_wubx set name='老赵赵' where id=1;

现在表里的数据情况：

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开始，原来写入的数据应该是：

+—-+———–+| id | name |+—-+———–+| 1 | 张三 |+—-+———–+| 2 | 李四 |+—-+———–+| 3 | 隔壁老王 |+—-+———–+

如果没生truncate table操作，实际的数据应该为：

+—-+———–+| id | name |+—-+———–+| 1 | 张三 |+—-+———–+| 2 | 李四 |+—-+———–+| 3 | 隔壁老王 |+—-+———–+| 4 | 老赵赵 |+—-+———–+

而且线上的恢复那个表时和序序开发人员了解才知道，原来那个id和缓存及其它地方有依赖，因为id乱了，也会造成程序错乱。这个时间修复id在程序层错乱的事，留给开发人员了关建是给他们讲明白恢复的结果是什么样，我们的关建任务是把数据恢复出来。好，接下来的工作是开始从binlog中恢复数据。
利用: show binary logs; 查看当的log文件分布，然后利用show binlog events in ‘binary log文件'; 查看log文件的内容，目的是找到truncate发生的日志位置。

上一篇：在MySQL中生成随机密码的方法

下一篇：MySQL中修改库名的操作教程