And while I was at it. I figured out I could do something similar with mysql queries. Instead of turning on full Query-logging in mysql (which probably means a restart of a running production mysql) I could just sniff it
tshark -i eth0 -aduration:60 -d tcp.port==3306,mysql -T fields \ -e mysql.query 'port 3306'
I’ve been using wireshark for awhile now. I ran across this the other day while trying to debug a non-MySQL issue. It was a good reminder of wireshark’s ability to do live dissection of protocol from the command line. I’ve had to do this before while trying to debug NFS issues (specifically, trying to work backwards from a packet to figure out the name of an open file descriptor from a file handle and fsid). Wireshark’s ability to do this on the fly and from the command line is pretty powerful.
Right now I have a need to figure out why MySQL is showing a bunch of aborted connections. I was hoping that mysql.error would give me something intelligent to poke after, but I think this occurs all within the MySQL instance. More digging to do. It’s good to know that I can do some impromptu poking around of the MySQL packet if I without firing up a full wireshark session on the server if I need to.
If you have a need to do this, these two things will be helpful.
Happy sniffing!
