前言
2021年3月8号，一个美好的日子-三八妇女节，而我今天却删库了，真的是无语，早晨经历了50分钟的拥堵车程（10km的路程），然而都阻挡不住自己周一来公司删库的步伐，唉，都没有勇气跑路了…
言归正传，讲真的，意识到自己的这步操作后的我，首先给领导阐明原因，然后也正是领导的一言，让我醍醐灌顶，如梦惊醒，下来便开始磨刀霍霍的恢复数据。
恢复操作
step1：先用完整的数据备份恢复
由于我们生产环境上是由数据库的备份脚本的（每天定时备份），所以获取到备份sql，然后再生产环境上执行。
备份服务器上：
cd /u01/databak/42/202103080400
scp 20210308_040001-wg_wenhai_data.sql.gz 数据库服务器ip:/root/
数据库服务器上：
gunzip 20210308_040001-wg_wenhai_data.sql.gz
登录mysql中执行：
use wg_wenhai_data
source /root/20210308_040001-wg_wenhai_data.sql
step2：通过mysqlbinlog在binlog中查看的日志
说明：基于binlog恢复，虽然按照时间可以恢复，但是通过在时间后对应的end_log_pos也是可以恢复的，下面也会给大家展示。
基于时间点恢复
1）mysqlbinlog查看详细位置
mkdir /root/log
mysqlbinlog --base64-output=decode-rows -vvv /u01/mysql/mysqlbinlog/mysql-bin.000155 > /root/log/mysql-bin.000155.log
2) 基于时间恢复的命令如下
mkdir /root/log/sql
mysqlbinlog /u01/mysql/mysqlbinlog/mysql-bin.000155 --start-datetime='2021-03-08 0:00:00' --stop-datetime='2021-03-08 9:40:43' > /root/log/sql/binlog-date.sql
基于binlog日志的position id进行恢复
1）mysqlbinlog查看详细位置
2） 根据恢复的时间点获取position id值
恢复的先决条件是基于在还原数据库前，删库的时间点，由于我是在生产环覆盖了数据库，所以必须要找到在覆盖的数据库在binlog中创建初始库的动作。这也就是为什么选择position id的位置，因为绿框中就是覆盖的开始命令。
可以看到凌晨和9点40分43的position id分别是97506871和269167350。
mysqlbinlog --start-position=97506871 --stop-position=269167350 /u01/mysql/mysqlbinlog/mysql-bin.000155 > /root/log/sql/binlog.sql
对比两种方式的文件差异：发现，发现虽然文件大小并没有完全一致，但是insert、update、delete的数量一致，所以可以直接执行恢复即可。
step3：通过mysqlbinlog在binlog中查看的日志
mysql -uusername -ppassword -h127.0.0.1
source /root/log/sql/binlog-date.sql
