刚出炉的一个MySQL故障

说说我的"丰功伟绩"吧，事情是这样的（真实IP地址我使用192.168段的IP代替）：

1、业务方找我开通192.168.180.%段的两个IP地址对MySQL数据库的访问权限，提了一个权限开通的工单，但是工单上把IP段的网段给写错了，写成了192.168.181.%

2、因为工单系统是自动化的，我就直接在界面上执行了。分为两步，分别是开通系统防火墙、分配192.168.181.%段的访问账号，也就是：

grant select.... on db.table to user@'192.168.181.%';

我很快执行完并反馈业务方，工单已经执行完毕，可以检查权限了。

3、结果业务方反馈180.%段的IP地址无法访问MySQL数据库服务（当然不能访问了，IP地址都写错了，怎么能访问啊）

4、经过检查，业务方发现自己的权限开通工单上面填写的IP地址有错误。重新填写了一个权限开通的工单,这次IP写对了，写的是192.168.180.%。

5、我执行完这个工单之后，确认业务方已经可以访问MySQL数据库服务，顺手将上一个执行错误的权限开通工单分配的账号user@'192.168.181.%'给drop掉了。也就是执行了：

drop user user@'192.168.181.%'；

6、结果就是这么一个drop，造成了故障，我以为181.%段就是我刚刚才配置的账号，殊不知原本这个181.%段上还有别的应用服务器在连接，导致所有的应用服务器都不能访问数据库了。线上数据直接断开了。

7、10分钟后，发现服务无法访问了，业务方给我打电话迅速告知问题。5分钟内赶到电脑前，重新执行了181.%段地址的grant语句，问题解决。

就这么一个问题，今天一天的好心情都没了，真是的。在这里，我以自己为出发点先直接的总结总结这次事故吧：

1、下班时间内，不应该执行drop user这种危险的操作

2、在执行drop user操作之前，应该提前检查系统防火墙以及当前连接，也就是show processlist确认没有连接之后，再进行drop user的操作。

3、办事情不能大意，不能因为刚刚分配的账号有问题就直接删除，这种顺手操作的行为一定要从根上杜绝。

4、权限控制的方式可以考虑优化，这种按照网段开通权限的方法可能确实存在一些问题。

希望大家引以为戒。任何随手的操作都可能带来很大的影响，在数据库中进行drop操作的时候，一定要谨慎。

-----一位年轻DBA的忠告