一、数据库在进行数据更改操作时,会出现数据误操作导致数据异常的情况,所以数据安全是重中至重,对于数据库服务,必须开启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
参数说明,--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 核实查看。