Michael Widenius wrote:
>
> Hi!
>
> <cut>
>
> sasha> Unfortunately, I do not see any way to kill the zombies any sooner without
> sasha> either slowing down replication, or having the slave establish another
> sasha> connection to the master just to kill a thread that has exited. We could,
> of
> sasha> course, try a read with a short timeout on the socket after each update to
> check
> sasha> for COM_QUIT, but this would slow things down too much - you will pay the
> sasha> penalty on each update. Another possiblity to open another connection and
> kill
> sasha> the zombie, but this is not that good of an idea either - if you decided
> to
> sasha> STOP the slave during network congestion, for example, and establishig
> another
> sasha> connection would take a long time, you will sit there for a couple of
> minutes
> sasha> waiting for STOP SLAVE to return.
>
> sasha> Monty, do you see any better/workable alternatives?
>
> How about if the slave would when it starts to replicate request that
> all other replications from that slave should be killed?
>
> That would be easy to do (at least on Unix); Just do a
> thr_alarm_kill() on all slave threads that comes from the same
> hosts.
I have now fixed this to kill all slaves. Except I do my own murder instead of
calling thr_alarm_kill() - thr_alarm_kill() will iterate through the thread
list, which is unneeded, since I already have got the thread, plus another
problem is that it wants to lock LOCK_thread_count mutex, and I have already
locked it it to iterate through thread list.
--
Sasha Pachev
+------------------------------------------------------------------+
| ____ __ _____ _____ ___ http://www.mysql.com |
| /*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sasha Pachev |
| /*/ /*/ /*/ \*\_ |*| |*||*| sasha@stripped |
| /*/ /*/ /*/\*\/*/ \*\|*| |*||*| Provo, Utah, USA |
| /*/ /*/ /*/\*\_/*/ \*\_/*/ |*|____ |
| ^^^^^^^^^^^^/*/^^^^^^^^^^^\*\^^^^^^^^^^^ |
| /*/ \*\ Developers Team |
+------------------------------------------------------------------+
