数据库误删后的恢复操作_2
--lock-all-tables 适用于MyISAM存储引擎
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。--single-transaction InnoDB
--flush-logs为结束当前日志，生成新日志文件；
--master-data=2 选项将会在输出SQL中记录下完全备份后新日志文件的名称，
如果选项赋值为2，那么CHANGE MASTER TO 语句会被写成一个SQL comment（注释），从而只提供信息;
如果选项赋值为1，那么语句不会被写成注释并且在dump被载入时生效。如果没有指定，默认值为1。
--routines，-R
导出存储过程以及自定义函数。
--single-transaction（单事务）大概保证了在dump期间，如果其他innodb引擎的线程修改了表的数据并提交，对该dump线程的数据并无影响
它只适用于事务表，例如 InnoDB 和 BDB。本选项和 --lock-tables 选项是互斥的，因为 LOCK TABLES 会使任何挂起的事务隐含提交。
一、场景
（1）MySQL数据库每晚04:00自动完全备份。
（2）9点的时候，我drop了一个数据库！
（3）可利用备份的数据文件以及增量的binlog文件进行数据恢复。
二、恢复思路
（1）利用全备的sql文件中记录的CHANGE MASTER语句，binlog文件及其位置点信息，找出binlog文件中增量的那部分。
（2）用mysqlbinlog命令将上述的binlog文件导出为sql文件，并剔除其中的drop语句。
（3）通过全备文件和增量binlog文件的导出sql文件，就可以恢复到完整的数据。
三、前提
----------------------------------------
首先，要确保mysql开启了binlog日志功能
在/etc/my.cnf文件：
log-bin=mysql-bin
然后重启mysql
四.现在进行全备份
mysqldump -uroot -p -B db2 --flush-logs|gzip >./db22.sql.gz
删除数据库db2
cp /usr/local/mysql/data/mysql-bin.000008 ./
gzip -d db22.sql.gz
mysqlbinlog -d db2 mysql-bin.000008 >t22.sql
mysql -uroot -p <db22.sql
329 mysql -uroot -p
330 mysql -uroot -p <t22.sql
