>> >> - 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.
I am fine with "Connecting" the new state for IO thread.
> 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
Why so dramitic dilemma?!
pre-bug#41613 was not perfect at least from testing
perspective: it has been often necessary to distinguish the fact IO
thread is online and not connected yet, from the fact it's not been started.
Sven and I discussed and conceptually agreed to have such
a connecting state.
bug#41613 adds a new state, and BUG#30703 fixes Slave_running to
comply to the definition below
>> 'Slave_running' is YES iff Slave_IO_Running: Yes and Slave_SQL_Running: Yes
> Totally agree!
Yes Slave_running would remain binary mapping to actual 6 states
of Show Slave Status (SSS).
>> 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.
start slave does not report anything. You know that it's an asynchronous operation
which does not wait for IO to complete with connecting to the master.
The new Connecting state btw can be reported right after `start slave' responed
back to the user.
> 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.
That's what is happening. The docs actually read
in 126.96.36.199 `START SLAVE' Syntax
if `START SLAVE': start-slave. succeeds in starting the slave
threads, it returns without any error. However, even in that case, it
might be that the slave threads start and then later stop
It could be said more explict that START SLAVE is asynchronous in the
> And fix BUG#30703 to be
> consistent with SHOW SLAVE STATUS, I think I can accept this approach.
> What you think?
So we have agreed on the Slave_Running's YES which makes bug#30703
I suggest you to go ahead with the Connecting state, provided that
#support supports either idea of the Slave_Running's YES def and the
Connecting IO to be shown in SSS.
>> 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 :)