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 in
>> 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 pre-bug30703)
>
> 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'.
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.
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).
>> 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.
cheers,
Andrei
