前提：对mysql库进行全备和增量备份（全备就是对hive库进行完全备份，增量备份就是将mysql的binlog日志进行备份）
情景说明：由于误操作，将包含有多张表的数据库给误删了
要求：恢复误删的数据库
具体模拟故障过程与恢复操作步骤如下：
（1）首先创建hive库，创建一个before1表，插入一条记录，创建一个after1表，插入3条记录
mysql> use hive;
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
+------+
3 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)
（2）对hive库做个完全备份（记录日志位置，并设置字符集）
mysqldump -uroot -pxxx -h10.191.22.247 -F -R --master-data=2 --default-character-set=utf8 --single-transaction -B hive |gzip >/tmp/mysql_$(date +%F).sql.gz
（3）在hive库中的after1表新增2条记录，并更新2条记录，刷新日志
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
| 555 |
| 666 |
+------+
5 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)
mysql> flush logs;
（4）在hive库中的after1表新增2条记录，误操作，drop数据库hive
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
| 555 |
| 666 |
| 77 |
| 88 |
+------+
7 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)
mysql> drop database hive;
（5）恢复被误删除的hive库
（5.1）先记录下当前数据库的日志号，并刷新日志，当前最新日志为29
（5.2）将没有备份的日志都备份到其他目录下
cp /mnt/sata01/mysql/mysql-bin.000028 ./
cp /mnt/sata01/mysql/mysql-bin.000029 ./
（5.3）恢复hive的完全备份
gzip -d mysql_2018-12-18.sql.gz
mysql -uroot -pxxx <mysql_2018-12-18.sql
查看完全备份时的日志号和日志位置：
more mysql_2018-12-18.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000028', MASTER_LOG_POS=154; //可以看到完全备份时的日志是28，位置是154.那么可以从28日志的154位置开始往后进行恢复
根据查看到的日志位置，对154后面剩余的日志进行应用：（注意--start-position=154参数的使用）
mysqlbinlog --start-position=154 --database hive mysql-bin.000028|mysql -uroot -pRootlyl123@ -v hive
将删除hive库之前的日志29，30都进行恢复：（还有一个问题，现在不确定drop库的操作在不在29和30的日志里，所以需要在库里或库外查看一下日志里面的具体操作）
对于DCL操作，如建库删库都能在库里查看日志的事件，如果是DDL操作，在库里看日志事件是看不出来的
在库里查看：（发现该删库操作在End_log_pos 733之前）
mysql> show binlog events in 'mysql-bin.000029';
| mysql-bin.000029 | 597 | Write_rows | 161 | 637 | table_id: 142243 flags: STMT_END_F |
| mysql-bin.000029 | 637 | Xid | 161 | 668 | COMMIT /* xid=13757124 */ |
| mysql-bin.000029 | 668 | Anonymous_Gtid | 161 | 733 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000029 | 733 | Query | 161 | 825 | drop database hive |
| mysql-bin.000029 | 825 | Anonymous_Gtid | 161 | 890 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
在库外查看：如果想找DDL操作，需要到库外，对日志进行分析来查找：
mysqlbinlog -d hive --base64-output=decode-rows -v mysql-bin.000029 >29.sql
vi 29.sql //在里面过滤查找drop关键字，发现删除位置操作在733处
【SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 733
#181218 11:51:53 server id 161 end_log_pos 825 CRC32 0xd623fa5d Query thread_id=83772 exec_time=0 error_code=0
SET TIMESTAMP=1545105113/*!*/;
drop database hive
/*!*/;
# at 825
#181218 11:53:28 server id 161 end_log_pos 890 CRC32 0xe5188448 Anonymous_GTID last_committed=3 sequence_number=4 rbr_only=no
】
恢复所有数据到733前，即恢复hive库到删除操作之前：
mysqlbinlog --stop-position=733 --database hive mysql-bin.000029|mysql -uroot -pRootlyl123@ -v hive //注意stop-position参数的使用
（6）查看数据库，发现数据库和里面的表数据已经都回来了
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
| 555 |
| 666 |
| 77 |
| 88 |
+------+
7 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)