>>>>> "Scott" == Scott Hess <scott@stripped> writes:
Scott> Mike Wexler <mwexler@stripped> wrote:
>> Sometimes mysqld get stuck with a long running query that locks
>> a critical resource. When this happens, often the first sign
>> will be that you get a refused connection because there are too
>> many busy threads. It would be really nice to be able to do a
>> mysqladmin processlist at this point, but you can't get connect
>> to the server. Would it be possbile to have mysqladmin have a
>> special port that it connects to, so that it can connect even
>> when the server is at max capacity?
Scott> On a related note, it would be very nice if mysqld had a signal on the
Scott> order of "Make the on-disk tables consistent and exit". [But _don't_
Scott> finish queries - selects can be immediately terminated, updates should
Scott> finish the current transaction and then terminate.] There will always be
Scott> bugs, if only because features are always being added. Using mysqladmin to
Scott> shutdown the process is great _if_ you assume that the database is
Scott> listening for connections.
Scott> I realize that if there is a bug, then anything you ask the server to do at
Scott> that point might be wrong. What I tend to do now is if a mysqld is
Scott> unresponsive, I use iostat (or something similar) to see if anything is
Scott> writing to the disk. If not, mysqld gets a kill -9. If something is busy
Scott> with the disk, I'll generally give mysqld a second, and third, chance to
Scott> respond, but there have been times when I had to kill -9 even in that
Scott> state. I'd have rather sent it a kill that had half a chance of letting it
Scott> clean up after itself.
Note that MySQL reserves an extra connection for a user with the
'process_list' privilege. If the normal users doesn't have this
privilege set, you can always go in as a user with this privilege and
If you send a normal kill signal to mysqld, it will send a kill signal to
all threads to make them quickly abort what they are doing and then it
should go down gracefully. I shall look into introducing another signal
that will not abort threads that are updating the tables..
PS: Sorry for the late reply; I am still trying to catch up with the
mails that piled up during my vacation.