MySQL数据回滚-误更新和删除时快速恢复

前面的内容也提到过update或delete误更新删除了数据后如何恢复。实际生产环境中常常因各种不同场景导致一些办法有效一些办法无效，当然，最有效的办法依然是备份！

本文聊聊一种场景：误更新和删除时快速恢复。要快速恢复，必然离不开工具的支持，这里以一款开源工具binlog2sql说明下如何快速恢复数据（工具地址：https://github.com/danfengcao/binlog2sql ，功能测试请选择测试环境）。

虽然啰嗦，依然想再提醒下：

后悔药数据恢复再次提醒：

1，首先需要说明的是，生产环境下慎重执行删除操作，除非你确实明白自己在做什么，否则不执行危险动作。

2，有条件的情况下，依靠系统来管理数据和数据库，尽可能降低潜在的管理的风险。

3，数据库有Update、Delete、Insert、Truncate、Drop类操作，先在测试环境执行一次，看结果和预期是否相符。生产环境执行前，先对要操作的表做一个备份，以防万一。

4，备份，备份，备份。

以下一些内容来自工具的使用说明文档

本工具起效的前提：

log_bin = mysql-bin.log

binlog_format = row

1，安装：略

2，binlog2sql的使用参数说明：(具体使用方法请见)

mysql连接配置

-h host; -P port; -u user; -p password

解析模式

--stop-never 持续同步binlog。可选。不加则同步至执行命令时最新的binlog位置。

-K, --no-primary-key 对INSERT语句去除主键。可选。

-B, --flashback 生成回滚语句，可解析大文件，不受内存限制，每打印一千行加一句SLEEP SELECT(1)。可选。与stop-never或no-primary-key不能同时添加。

解析范围控制

--start-file 起始解析文件。必须。

--start-position/--start-pos start-file的起始解析位置。可选。默认为start-file的起始位置。

--stop-file/--end-file 末尾解析文件。可选。默认为start-file同一个文件。若解析模式为stop-never，此选项失效。

--stop-position/--end-pos stop-file的末尾解析位置。可选。默认为stop-file的最末位置；若解析模式为stop-never，此选项失效。

--start-datetime 从哪个时间点的binlog开始解析，格式必须为datetime，如'2016-11-11 11:11:11'。可选。默认不过滤。

--stop-datetime 到哪个时间点的binlog停止解析，格式必须为datetime，如'2016-11-11 11:11:11'。可选。默认不过滤。

对象过滤

-d, --databases 只输出目标db的sql。可选。默认为空。

-t, --tables 只输出目标tables的sql。可选。默认为空。

步骤简介：

解析SQL:

python binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p'admin'-dtest -t test3 test4 --start-file='mysql-bin.000002'

回滚SQL：

python binlog2sql.py --flashback -h127.0.0.1 -P3306 -uadmin -p'admin'-dtest -ttest3 --start-file='mysql-bin.000002'--start-position=763 --stop-position=1147

希望大家没有机会使用！