Home / server / Questions / 251058
Accepted
sreimer
Asked: 2011-03-24 13:03:34 +0800 CST

MySQL RESET [integer]

  • 772

In an audit of queries running on our databases using tcpdump and Maatkit tools, the number one query is

RESET [int]

Running this statement from the MySQL command line results in an error as RESET should only accept parameters master, query cache and slave.

This statement does not exist in our code base. We do run MySQL Enterprise Monitor but the reported user is not our monitoring user. We also use the Zend framework with the mysqli connection driver but failed to find any call to this statement.

Any ideas as to what this could be?

mysql tcpdump maatkit zend

3 Answers

  1. Best Answer

    I suspect that this is mk-query-digest misinterpreting the TCP traffic. Reconstructing the traffic as an observer on the sidelines, due to out-of-order packets, dropped packets, retransmits, and so on, is never an exact science. When there are a lot of errors in what mk-query-digest sees, it can sometimes interpret the traffic in spurious ways and appear to find things that might not exist.

    I would suggest digging into the tcpdump output manually. It is tedious, and the protocol is hard to decode manually, but if you dump some data to a file and then mk-query-digest it, mk-query-digest will tell you the byte offset in the file where it finds the sample query it prints out. This should let you narrow in on one packet, and with the protocol docs from the MySQL internals manual, you ought to be able to see if that packet really is the alleged RESET. I believe that the RESET is probably related to the binary (prepared statement) protocol, if it's real; if it's spurious, I have no guesses.

    • 2

  2. You're using tcpdump, so you can narrow this down by finding which workstation(s) this is coming from. If it's all of them, then there's something wrong with your assumptions.

    • 0

  3. If you're watching it with tcpdump, you should be able to know the user who's logging in and the source port. The former gives you the ability to change credentials one-by-one until the problematic queries change which login they use, at which point you'll know their source. The source port lets you both know whether the remote UID is zero (if src port is <1024), and it also gives you the ability to use netstat -ntp (*nix) or netstat -nto (Windows) to determine which PID is actually generating the query.

    • 0