MySQL权限处理的一个小bug

最近碰到了一个奇怪的权限问题，问题的背景是业务同学反馈在下班后，有一个数据表出现了阻塞，导致后续的业务流程都产生了拥堵，在对这个问题进行分析发现，业务同学所谓的拥堵，阻塞是数据库连接出了问题。当然我们进行了一些深入的沟通，对整个问题的情况有了一个更为清晰的了解。

6:30左右，业务同学发现程序端产生了阻塞，程序端正在处理的操作是一个create table的操作。

6:40左右，业务同学尝试通过客户端工具连接到数据库来手工执行，但是发现连接超时，根据业务同学反馈，之前是能够正常连接的。

6:50左右，业务同学开始呼叫DBA进行处理。

7:00左右，DBA就位后，什么都没做，就魔法般的解决了问题。

对于业务同学的印象，是数据库不够稳定，因为另外一套环境也出现了类似的问题，这是一个很纠结的情况，我们如同哆啦A梦般的存在，但是实际上什么都没有做就解决了问题。

当然在我的职业生涯中，对待问题我是不相信神奇的力量，事出有因，我希望找到那些看起来简单的问题的答案。

从业务同学的反馈时间点开始，我尝试找到一些相关的日志来看看，从数据库的处理来看，是不大可能阻塞DDL中的create操作的，无论服务器压力大小，这算是DDL里面最正常的需求了，绝对不应该阻塞几十分钟。

幸运的是，我很快找到了相关的binlog日志，简单解析之后，看到了下面的内容。

从内容来看，情况和业务同学反馈的时间点是吻合的，业务逻辑会自动创建相关的时间表，而下一次create则是在20多分钟之后，这里的问题就来了，为什么创建两张表的过程中会有这些权限处理的语句出现?

看这些权限处理的语句还是比较规范的，而且从执行日志来看不大像是人工执行的，因为整个权限的处理涉及的语句条数还比较多，从执行上来看，像是工具生成的。

我查看了下相关时间范围内的工单数据，发现在那个指定的时间段里，确实有同事在处理几个相关的工单，带着这个信息和同事确认，才发现这两件看起来不相关的事情还是有关联的。

业务同学反馈，有两套环境都出现了类似的问题，和工单数据比对发现，情况是完全相符的，在出现问题的时间段里产生了阻塞。

我们来仔细看一下这条语句：

GRANT USAGE ON *.* TO 'srv_datasync_rwh'@'192.168.18.%' IDENTIFIED WITH 'MySQL_native_password' AS '*5EEBC522DE487B0D5C2506C65412F9C337F70C40'

这条语句是对于192.168.18端的客户端开通相应的权限，而这个grant语句其实是类似MySQL 5.7的create user语句，带着这个问题继续下钻，发现原来这个数据库中本身是存在用户'srv_datasync_rwh'@'192.168.18.%' 的，在这里，相当于工具重新生成了完整的授权语句，对已经存在的用户进行了重新授权，这个操作的代价有点类似于权限重置。

而这个问题在测试环境中模拟是直接复现不了的，整个问题和触发的上下文环境也有相关性，同时对涉及到权限处理的完整过程中产生了额外影响，有点类似于在购物网站中，一边在购物下单，另一边在同时做密码重置，这是一种较为模糊的临界状态。

总体来说，这个权限问题还是相对可控的，我们需要修复运维工具自动生成的语句的逻辑，对于5.7版本的使用create user，grant这种组合授权模式。

个人新书 《MySQL DBA工作笔记》