0

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?

1
  • Think about what has access to those credentials; only something that does can be generating this error. For bonus points, try swapping the credentials used by your web services, and see if the source uid of the RESETs changes.
    – BMDan
    Apr 12, 2011 at 12:55

3 Answers 3

2

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.

1
  • Thanks for the suggestion. I eventually wrote it off as a mis-constructed query as I could not find any source.
    – sreimer
    Sep 1, 2011 at 3:55
0

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.

1
  • It's reported as coming from all of our web servers. I'm not saying it's not code related, but it doesn't seem to be explicitly called. I'm wondering if there is an automatic mechanism triggering this.
    – sreimer
    Mar 23, 2011 at 21:22
0

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.

1
  • tcpdump was run on 3306 to get only MySQL traffic. The actual queries were rebuilt from that dump using mk-query-digest. I am doing some deeper analysis with the dump.
    – sreimer
    Mar 24, 2011 at 3:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .