MySQL经过binlog日志回滚数据

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

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

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

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

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

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

三、混合模式复制(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;

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

建立测试数据库：

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

将数据删除：

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


确认时间点后，进行数据回滚，相关命令仍是经过mysqlbinlog进行数据回滚操做。
mysqlbinlog --no-defaults --start-position="239" --stop-position="736" /var/lib/mysql/ON.000015 | mysql -uroot -p
参数说明，--start-position #开始的pos时间点。
--stop-position #结束的pos时间
若是是经过日期时间回滚的命令以下：

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 核实查看。