数据库误删除后的两种恢复方法（一）日志操作篇

工欲善其事必先利其器

想要详细了解数据库误删后的恢复操作，得先了解一些基本的信息

目录

Binlog 日志详解

一、Binlog 记录模式

二、Binlog 文件结构

三、Binlog 写入机制

四、Binlog文件操作

1、查看Binlog的状态

2、开启Binlog功能

3、查看都有哪些日志文件

4、查看当前正在操作的日志

5、查看当前日志中有哪些事件 

6、删除日志文件的三种方式

7、查看和修改日志文件的有效期

8、查看日志文件的详细信息

9、对删除数据库的恢复具体操作

---

首先呢，想要恢复误删的数据库，可以先从日志入手，而在数据库的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字节	该事件的长度