说说我的"丰功伟绩"吧,事情是这样的(真实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的忠告