List:Commits« Previous MessageNext Message »
From:He Zhenxing Date:March 11 2009 3:23am
Subject:Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703
View as plain text  
Andrei Elkin wrote:
> He Zhenxing,
> 
> >> >> - 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'.
> >> 
> >
> > 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.
> 

OK

> >
> > 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
> > problem.
> 
> 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.
> 

Seems I misunderstood you, I had thought that you meant that the
supports might want to have two states.

So that's great, let's go with three states for Slave_IO_running.

> 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
> >> 

OK, this is reasonable.

But there is one problem, it will cause contradict behavior between 6.0
and 5.1/5.0 on this, I am not quite sure if this bug (#30703) should be
backported or not.

> >
> > 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 12.6.2.7 `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
> mentioned sense.
> 

Yes, that's what I mean, but if we have the three states, then this is
not necessary.

> 
> > 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
> fixes approved.
> 
> 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.
> 

OK, Let the users and supports try this out and decide

> 
> 
> cheers,
> 
> Andrei
> 
> 
> >
> >> 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 :)
> 
> 

Thread
bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703Guangbao Ni4 Mar
  • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703Alfranio Correia10 Mar
    • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703Guangbao Ni10 Mar
      • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703Andrei Elkin10 Mar
        • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703He Zhenxing10 Mar
          • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703Andrei Elkin10 Mar
            • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703He Zhenxing10 Mar
              • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703Andrei Elkin10 Mar
                • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703He Zhenxing11 Mar
        • Re: bzr commit into mysql-6.0-bugteam branch (gni:3101) Bug#30703He Zhenxing10 Mar