这是周五下午的事情了（也就是20170602日），开发人员通过navicat，把生产环境中，一个最重要之一的数据库完整干掉了，他本心是不让新来的同事看到这个库，以为只是删除一个连接而已，结果差点酿成大悲剧。@#￥@#￥！#R$@#

下图是事故发生的时候的binlog日志截图：

可以看到在2017-06-02 16:53:12时候，有一条drop database hyd2_to_hyd4的语句，这句语句之后整个世界都安静了。

下面说下恢复整个过程吧。

1，首先，最重要的是把这个事故告知产品经理和运营人员，让他们和客户解释原因，先稳定客户。

2，保护binlog日志，登陆惠易定mysql数据库，停止mysql服务器，把binlog目录备份一份

3，copy备份文件回服务器，解压全备文件，通过innobackupex 回滚日志，

一份

3，copy备份文件回服务器，解压全备文件，通过innobackupex 回滚日志，命令如下：

innobackupex --user=root --password=waglo127net --socket=/webdata/opt/local/mysql33060/misc/mysql.sock  --apply-log recovery/

4，把回滚后的全备文件copy到mysql的根目录下并更名data,更改权限为:chown -R mysql:mysql data/

5,在启动myqld服务之前通过iptables 屏蔽应用程序的访问,

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited

上面，只允许本机的应用访问，外部访问一律拒绝.

6,还原binglog，找到drop database hyd2_to_hyd4 之前的postions点，这个就是还原的终止点，起始点,innobackupex 已经打印出来了。

7，通过如下与进行 binlog回放恢复

./bin/mysqlbinlog  --start-position=301242844 --stop-position=820525157 huiyiding.001221|mysql -u root -p -S /webdata/opt/local/mysql33060/misc/mysql.sock 

8，完成后验证数据，没有问题的话，重启下iptables，去掉之前iptables的限制，一切搞定。

后记：出现这种事情，应该检讨权限分配机制，给开发人员权限正式库上，也就是select权限足矣。

那天晚上，我带上了两个主要开发人员，去了欢乐海岸酒吧，泡了两个小时，也算去压压惊吧，谢天谢地，没有造成太大后果。记下这次事故，留以自律自戒吧。