MySQL通过binlog日志回滚数据

一、数据库在进行数据更改操作时，会出现数据误操作导致数据异常的情况，所以数据安全是重中至重，对于数据库服务，必须开启binlog日志服务，保证数据的安全，可逆回滚。
二进制日志的格式有三种形式分别为ROW、Statement以及MiXED
1、STATMENT模式：基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。

优点：不需要记录每一条SQL语句与每行的数据变化，这样子binlog的日志也会比较少，减少了磁盘IO，提高性能。

缺点：在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)

2、基于行的复制(row-based replication, RBR)：不记录每一条SQL语句的上下文信息，仅需记录哪条数据被修改了，修改成了什么样子了。

优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。

缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨。

3、混合模式复制(mixed-based replication, MBR)：以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。
这里我这都我的数据库日志使用ROW格式。

登录数据查看数据库的数据信息：

核实相关的binlog日志的报错路径以及日志是否开启。show variables like "log_bin%";

核实最新的binlog日志信息：show master logs; show binary logs; show master status;

二、下面进行相关的数据恢复实践：

创建测试数据库：

创建数据表：相关的数据是下载网络资源的数据。

将数据删除：

三、通过binlog日志核实删除以及创建数据的时间点或者pos点。
我这里演示通过pos点进行数据恢复。
通过mysqlbinlog 命令核实最近的binlog日志名称进行日志查看。核实具体的时间节点。


确认时间点后，进行数据回滚，相关命令还是通过mysqlbinlog进行数据回滚操作。

mysqlbinlog --no-defaults --start-position="239" --stop-position="736" /var/lib/mysql/ON.000015 | mysql -uroot -p

mysqlbinlog --start-datetime '2019-07-02 21:42:36' --stop-datetime '2019-07-02  21:57:42' /var/lib/mysql/ON.000013 | mysql -uroot -p

执行回滚后会出现如下的信息，回车确认，我这里数据比较少，回滚时间较快。

再次核实相关的数据信息。

注：mysqlbinlog相关的命令参数可以通过mysqlbinlog --help 核实查看。