![MySQL RESET](https://linux22.com/image/543817/MySQL%20RESET%20.png)
在使用 tcpdump 和 Maatkit 工具审计我们的数据库上运行的查询时,排名第一的查询是
RESET [int]
从 MySQL 命令行运行此语句会导致错误,因为 RESET 只应接受参数 master、query cache 和 slave。
我们的代码库中不存在此语句。我们确实运行了 MySQL Enterprise Monitor,但报告的用户不是我们的监控用户。我们还使用带有 mysqli 连接驱动程序的 Zend 框架,但未找到对此语句的任何调用。
您知道这可能是什么吗?
答案1
我怀疑这是 mk-query-digest 误解了 TCP 流量。由于数据包乱序、数据包丢失、重传等原因,作为旁观者重建流量从来都不是一门精确的科学。当 mk-query-digest 看到的内容中存在大量错误时,它有时会以虚假的方式解释流量,并似乎找到了可能不存在的东西。
我建议手动深入研究 tcpdump 输出。这很繁琐,而且协议很难手动解码,但如果您将一些数据转储到文件中,然后对其进行 mk-query-digest,mk-query-digest 将告诉您在文件中它找到打印出来的样本查询的字节偏移量。这应该可以让您缩小到一个数据包,并且使用 MySQL 内部手册中的协议文档,您应该能够查看该数据包是否真的是所谓的 RESET。我相信 RESET 可能与二进制(准备好的语句)协议有关,如果它是真实的;如果它是伪造的,我就猜不到了。
答案2
您使用的是 tcpdump,因此您可以通过查找该数据包来自哪个工作站来缩小范围。如果是所有工作站,那么您的假设就有问题。
答案3
如果您使用 tcpdump 观察它,您应该能够知道登录的用户和源端口。前者使您能够逐个更改凭据,直到有问题的查询更改它们使用的登录名,此时您将知道它们的来源。源端口让您知道远程 UID 是否为零(如果源端口小于 1024),并且它还使您能够使用netstat -ntp
(*nix) 或netstat -nto
(Windows) 来确定哪个 PID 实际生成了查询。