工作场景
MySQL 数据库每晚 12:00 自动完全备份。
某天早上上班，9 点的时候，一同事犯晕 drop 了一个数据库!
需要紧急恢复!可利用备份的数据文件以及增量的 binlog 文件进行数据恢复。

数据恢复思路
利用全备的 SQL 文件中记录的 CHANGE MASTER 语句，binlog 文件及其位置点信息，找出 binlog 文件中增量的那部分。
用 MySQLbinlog 命令将上述的 binlog 文件导出为 SQL 文件，并剔除其中的 drop 语句。
通过全备文件和增量 binlog 文件的导出 SQL 文件，就可以恢复到完整的数据。
 

实例说明
首先，要确保 MySQL 开启了 binlog 日志功能。在 /etc/my.cnf 文件里的 [mysqld] 区块添加，如下图，然后重启 MySQL 服务。
1.在 ops 库下创建一张表 customers
 

2.现在进行全备份
参数说明：
-B：指定数据库
-F：刷新日志
-R：备份存储过程等
-x：锁表
–master-data：在备份语句里添加 CHANGE MASTER 语句以及 binlog 文件及位置点信息
3.再次插入数据
 

4.此时误操作，删除了 test 数据库
此时，全备之后到误操作时刻之间，用户写入的数据在 binlog 中，需要恢复出来!
5.查看全备之后新增的 binlog 文件

这是全备时刻的 binlog 文件位置，即 mysql-bin.000002 的 106 行，因此在该文件之前的 binlog 文件中的数据都已经包含在这个全备的 SQL 文件中了。
6.移动 binlog 文件，并导出为 SQL 文件
剔除其中的 drop 语句，查看 MySQL 的数据存放目录，由下面可知是在 /var/lib/mysql 下，将 binlog 文件导出 SQL 文件，并 vim 编辑它删除其中的 drop 语句。
注意：在恢复全备数据之前必须将该 binlog 文件移出，否则恢复过程中，会继续写入语句到 binlog，最终导致增量恢复数据部分变得比较混乱。
7.恢复数据
查看数据库，看看 ops 库在不在。
 

此时恢复了全备时刻的数据。接着，使用 002bin.sql 文件恢复全备时刻到删除数据库之间，新增的数据。
再次查看数据库，发现全备份到删除数据库之间的那部分数据也恢复了!!

以上就是 MySQL 数据库增量数据恢复的实例过程!
最后，总结几点：
本案例适用于人为 SQL 语句造成的误操作或者没有主从复制等的热备情况宕机时的修复。
恢复条件为 MySQL 要开启 binlog 日志功能，并且要全备和增量的所有数据。
恢复时建议对外停止更新，即禁止更新数据库。
先恢复全量，然后把全备时刻点以后的增量日志，按顺序恢复成 SQL 文件，然后把文件中有问题的 SQL 语句删除(也可通过时间和位置点)，再恢复到数据库。