工欲善其事必先利其器
想要详细了解数据库误删后的恢复操作,得先了解一些基本的信息
目录
首先呢,想要恢复误删的数据库,可以先从日志入手,而在数据库的InnoDB搜索引擎中有三种日志:Undo Log 日志、Redo Log 日志、Binlog 日志,三种日志中,我们需要通过Binlog日志来进行数据库的恢复
Binlog 日志详解
一、Binlog 记录模式
Redo Log 是属于InnoDB引擎所特有的日志,而MySQL Server也有自己的日志,即常说的Binary log(二进制日志)简称:Binlog。Binlog是记录所有数据库表结果变更以及表数据修改的二进制日志,而不会记录SELECT和SHOW这类的操作。Binlog日志以时间的形式进行记录,还会包含语句所执行的消耗时间。开启Binlog日志后,会有以下两个最为重要的使用场景:
① 主从复制:在主库中开启Binlog功能,这样主库就可以把Binlog传送给从库,从库在拿到Binlog后,就可以实现数据恢复,从而达到主从数据的一致性。
② 数据恢复:通过mysqlbinlog工具来恢复数据。
Binlog文件名默认为“主机名_binlog-序列号”格式,譬如:stu_binlog-000001,当然也可以在配置文件中指定名称。文件记录模式有 STATEMENT、ROW 和 MIXED 三种,具体的含义如下:
① ROW(row-based replication,RBR):日志中会记录每一行数据被修改的情况,然后在slave端对相同的数据进行修改。
优点:能清楚的记录每一个行数据的修改细节,并能完全实现主从数据同步和数据的恢复。
缺点:批量操作,会产生大量的日志,尤其是 alter table 会让日志暴涨。
② STATEMENT(statement-based replication,SBR):每一条被修改数据SQL都会记录到master的Binlog中,slave在复制的时候SQL进程会解析成和原来master端执行过的相同的SQL再次执行。简称SQL语句复制。
优点:日志量小,减少磁盘IO,提升存储和恢复速度
缺点:在某些情况下会导致主从数据不一致,譬如:last_insert_id()、now()等函数时
③ MIXED(mixed-based replication,MBR):以上两种模式的混合使用,一般会使用STATEMENT模式保存Binlog,对于STATEMENT模式无法复制的操作则使用ROW模式来保存Binlog,MySQL会根据执行的SQL语句来选择写入的模式
二、Binlog 文件结构
MySQL的Binlog文件中记录的是对数据库的各种修改操作,用来表示修改操作的数据结构是Log event,不同的修改操作对应不同的log event,比较常用的log event有:Query event、Row event、Xid event等。Binlog文件的内容就是各种log event的集合。
Binlog文件中的 Log event结构如下图:
timestamp 4字节 | 事件开始的执行时间 |
Event Type 1字节 |
指明该事件的类型 |
server_id 1字节 | 服务器的server ID |
Event size 4字节 | 该事件的长度 | </