位置: 编程技术 - 正文
MySQL中truncate误操作后的数据恢复案例
编辑：rootadmin推荐整理分享MySQL中truncate误操作后的数据恢复案例，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:,内容如对您有帮助，希望把文章链接给更多的朋友！
实际线上的场景比较复杂，当时涉及了truncate, delete 两个操作，经确认丢数据差不多7万多行，等停下来时，差不多又有共计1万多行数据写入。 这里为了简单说明，只拿弄一个简单的业务场景举例。
测试环境： Percona-Server-5.6.日志格式： mixed 没起用gtid
表结构如下：
基于某个时间点有一个备份或是有全量的binlog是能恢复数据的一个唯一保证。 例如我们的备份就是一个表结构创建语句,binlog pos相关信息： mysql-bin. , 4，然后进行了如下：
?t1时间 程序写入：
?t2时间 某个人员失误
?t3时间 程序写入
现在表里的数据情况：
可以见truncate table操作后，表的自增id又变更为从1开始，原来写入的数据应该是：
如果没生truncate table操作，实际的数据应该为：
而且线上的恢复那个表时和序序开发人员了解才知道，原来那个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 （相当于恢复了备份，过程省略）
我这里有一个备份文件就是那个创建表的sql语句，位置是mysql-bin. , 4在这个案例里我只用cover住mysql-bin.这个文件。
看到这个表刚开始就发生一次truncate, 那其实也可以说明我就恢复刚开始那个truncate到后来那个误操作的truncate table的语句之间的数据就是丢失的数据。这个恢复可以从mysql-bin. pos: 4到mysql-bin. pos: 即：
恢复结果如下：
恢复完成。
在MySQL中生成随机密码的方法 cat/dev/urandom|LC_ALL=Ctr-dc"[:alnum:]"|fold-w|head-Si1N9kUyuZddzsRXFgxAcaDRBRT4PxbuGk6LkX4dN5Xod1TOyrcBxAjlKRjwJR2TxunhQedXagL9RraDEZgfhYQxCurm5eZF参数说明：如果需要特别复杂的
MySQL中从库延迟状况排查的一则案例 今天给一个客户巡检的情况下发从库没有业务的情况mysqld的cpu的一个core占用%.查主库慢查询也没有关于写的SQL.可以说是典的单进程复制把一个cpu占满
在MySQL中使用mysqlbinlog flashback的简单教程 简介：mysqlbinlogflashback功能是淘宝彭立勋(
