今年愚人节给了我一个很好地教训。自己平时工作习惯有待优化。我的电脑安装了Navicat for mysql，同时连接了服务器的mysql
和本地的mysql。当我打算更新本地mysql的数据库和服务器mysql同步的时候，脑残了，没有备份先删除了。本来应该有的程序是这个样
备份本地数据库然后删除所有表，然后将服务器的表转存下来然后导入。

1.进入本地连接
2.打开要更新的数据库
3.转存数据库为sql文件
4.ctrl+a 所有表
5.delete
6.您确认删除61个表吗? enter

　　可能是自己太自信了吧，而且以前也没出现什么错误。就直接从第4步开始。当我按下enter的一瞬间我崩溃了，我删除的不是本地的数据库里面的所有表，而是生产服务器上面的所有表。wtf?从此以后就抖了5分钟。赶紧进行下面的流程。

　　1.跟领导汇报“老板出大事儿了，我把数据库删了，所有用户都不能上线了，我正在想办法紧急恢复。目前最坏的打算是恢复到3.27日的数据。”（我的最新备份是3.27日）

　　2.老板：“好，赶紧……”(老板挺好呵呵，简短解说这是脑补的情景)

---

　　开始网上搜索解决方案。找到了一种方法叫使用binlog来回复数据库，前提是你已经开启了binlog

• 登陆mysql，查看log_bin是否开启(on:开启，off:关闭)

#mysql -u root -pmysql > show variables like "%log_bin%";

　　很好，说明有希望恢复数据库。加上我3.27日的全备份。那么好办了。

• 查看最后一个日志 下面两个都可以

mysql > show binary logs;

mysql > show master status;

• 我的日志是 mysql-bin.000024 那么把3.27之后的mysql所有操作日志导出来放到一个test.sql中。

　　（退出mysql使用root用户操作）

# /www/server/mysql/bin/mysqlbinlog --start-datetime="2020-03-27 16:50:00" /www/server/data/mysql-bin.000024 -r /www/test.sql

• 得到的test.sql 就是从2020-03-27 16:50:00 之后的所有记录了
  然后翻看这个记录查找我删除所有数据表的那个点位在哪儿。你会看到你熟悉得sql

这个是我最后一次备份之后的第一个执行语句

　　

这是我手贱删除数据表之前最后的语句 记录下at后面的两个起始位置

• 最后关键的地方就是通过 这个mysql_bin 把备份之后到删除之前的语句给导出来，就是 25180773 到 26194058
  两个点位之间的所有sql语句了。

[root@localhost ~]# /www/server/mysql/bin/mysqlbinlog --start-position=25180773 --stop-position=26194058 /www/server/data/mysqlbin.000024 > sql2.sql

• 好了sql2.sql出来了 那么它和我3.27日的备份合在一起就是最新的数据库了。

• 导入3.27的备份之后再导入sql2.sql 就可以了，所有的数据都不进去了那么赶紧备份一下最新的数据库吧。

　　特别提示：为了数据安全，这些事儿你应该是把所有的mysql_bin.0000** 这些所有的文件下载到本地通过虚拟机来完成的。

　　我在“犯罪现场”没有充足的准备。第一没遇见过这个情况没有经验。第二怕自己弄不好把日志文件覆盖掉就死翘翘了。

　　所以在万能的某宝上花了200大洋找大神给我导出来了最新的sql文件，我导入到服务器的。

　　以上操作是我把“犯罪现场”的所有文件下载下来之后，偷摸学经验吃一堑长一智自己在虚拟机还原了当时的环境。记录这次教训学习此次经验。

　　特别特别提示：不要把服务器的数据库随随便便连到你的本地，使用phpmyadmin就没有上面的一切。