For details, see http://www.softtreetech.com/idbaudit.htm

For more details contact SoftTree Technologies

Another approach is to have a different user for each “application” that connects. It isn’t quite as good since you can’t see what process opened the connection, but it does mean you can monitor which applications are doing what if you know that application A corresponds to a certain user. I used it to see which applications aren’t releasing connections.

Something that might help solve all problems would be the ability to pass a token in when opening a connection. Such as this

conStr = "blah=blah;token=" + this.Process.Id;
con = new MySqlConnection(con);

Then, you could see in MySQL process list the token associated with the connection. This would help me greatly as then you could even indicate in the token which function/subroutine the connection was opened from if tha twas the level of granularity required.

Tobin

This article isn’t about knowing what your connection ID is, or what your connection is doing. This article is about being a DBA and seeing a connection that is doing something ridiculous, or hung, or just staying open for three days. You don’t want to just kill the connection. You want to find the code that made the connection, and fix it. OK, you can easily find out the connection ID (in fact, by definition, you should already know that information before any of the rest of my article is of any use to you), and the machine where the connection was made. But can you find out the program on that machine that made the connection? Let’s pretend you can (probably impossible for most of you). And if it’s “/usr/sbin/apache2,” what then?

The connection is not the source of the trouble. Knowing the connection ID is trivial, and doesn’t get you anywhere. The program that made the connection is the problem, and that is what you need to find out. That is the point of this article. The further point of this article is that you cannot find this information from within MySQL. You have to do some sort of technique such as the ones I suggest here.

Returns the connection ID (thread ID) for the connection. Every connection has its own unique ID.

Thanks! No, because SHOW PROCESSLIST doesn’t say what program connected and what its UNIX process ID is. When you have a bunch of cloned machines and programs all running the same queries, and one of them is causing trouble, knowing what queries it’s running doesn’t narrow it down.

In fact, we even found the need to add more information in — a few days ago I tweaked the connection code to add the REQUEST_URI in cases where the connection was coming from our intranet, because tracing back to the UNIX process ID just tells us /usr/bin/apache2, and it really helps to know exactly what code is using the connection.

As if that weren’t enough, I even added one more thing in: what Class::DBI module made the connection.

All these things have been absolutely indispensable for finding badly behaved code and dealing with it. Much of the code was written by people who freely admit they knew nothing about transactions, and sprinkled BEGIN and COMMIT through the code without knowing what they meant. It’s pretty disconcerting when that code goes into wider production and the mysterious side effects begin piling up. “Hey! I just entered that information and now it disappeared! Where did it go?”

Definitely not something SHOW PROCESSLIST can even start to do. But your needs may be different from ours.