Andrei Elkin wrote:
> He Zhenxing,
> >> The tree states in show slave status was discussed ago with some
> >> people on #support who accepted the idea.
> >> Guang Bao, Zhen Xing, I think you need to speak to #support people and act
> >> consensus with them according to the two items:
> > agree
> >> - if the 3 states for IO in show slave status is acceptable indeed
> >> - whether SHOW STATUS LIKE 'Slave_running' would report the binary,
> >> and then which of the two binaries:
> >> 1) NO, YES (IO thread is started but not connected, the current
> > If we have to use binary states, then I'd prefer this, because when
> > connecting, the slave IO thread *IS* running and this is consistent with
> > START SLAVE.
> >> 2) NO, YES (IO thread is connected)
> > This would cause inconsistency with START SLAVE, when you see
> > Slave_IO_running or variable Slave_running is 'NO' when connecting, and
> > try START SLAVE IO_THREAD, it will warn that the slave is already
> > running.
> So the problem is how we define YES for SHOW STATUS LIKE 'Slave_running'.
I think it's rather a problem of how we define YES for Slave_IO_running
for SHOW SLAVE STATUS, i.e. whether we should treat RUN_NOT_CONNECTED as
running or not running.
If we think the behavior before BUG#41613 is correct, then we have to
fix BUG#30703 and revert BUG#41613. Otherwise, BUG#30703 is not a
> The interpretation I am about
> 'Slave_running' is YES iff Slave_IO_Running: Yes and Slave_SQL_Running: Yes
> Executing `start slave' is reentrant and besides seeing "in already
> running" there is no issue.
I don't agree, START SLAVE is also used by user, and he/she might run
into following problem: SHOW SLAVE STATUS and SHOW STATUS LIKE
'Slave_running' both reports that the slave IO thread is not running,
and START SLAVE would reports that it is already running.
So now I think maybe we can fix this problem (BUG#41613) by change the
warning message of START SLAVE to report that the slave IO thread has
already started and tring to connecting. And fix BUG#30703 to be
consistent with SHOW SLAVE STATUS, I think I can accept this approach.
What you think?
> Another reason why I would not link the Slave_running's YES definition
> with `start slave' is that it's so from the engineer's perspective,
> but remember SHOW:s are for the users as well.
> And they seem to me won't like Slave_running's YES
> if the IO is not connected (please ask that on #support for sure).
I think you're right, this behavior has existed for a long time. I think
there must be a reason (although I don't know :))
> >> or we would need to reflex the new IO 3 states in
> >> the SHOW STATUS LIKE 'SLAVE_RUNNING'
> > status 'Slave_running' is for both IO thread and SQL thread, so we
> > cannot have the Connecting state for it.
> We can have 2 * 3 states. However I am not sure if we need that.
> Let's be satiesfied with the binary state based on the def above.
I don't like this idea either :)