List:Commits« Previous MessageNext Message »
From:He Zhenxing Date:March 4 2011 3:34am
Subject:Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779
View as plain text  
Sven Sandberg wrote:
> On 03/03/2011 10:58 AM, He Zhenxing wrote:
> >>>> Actually I think this is a very good idea. Shall we create a fourth
> >>>> component? We will then have:
> >>>>
> >>>> Store
> >>>> Send
> >>>> Receive
> >>>> Reapply
> >>>>
> >>>> Perhaps with other names, perhaps prefixed by rpl.
> >>>>
> >>>> Sounds good?
> >>>>
> >>>> The only problem is commands like SHOW SLAVE STATUS and CHANGE
> MASTER,
> >>>> which are as much part of Receive (IO thread) as of Reapply (SQL
> >>>> thread). Where should those be?
> >>>>
> >>>
> >>> Yes, that would be ideal, this was my original goal to achieve when
> >>> designing the interfaces. but I think should make this as the next goal
> >>> because this would introduce more refactoring of the code.
> >>
> >> OK. It may be good to spell out this in the WL so that we know we are
> >> working in this direction.
> >>
> >>>
> >>> And I think SHOW SLAVE STATUS and CHANGE MASTER should still belong to
> >>> the Slave component, which will use the Receive and Reapply component.
> >>
> >> So we will actually have five components?
> >> Store
> >> Send
> >> Receive
> >> Reapply
> >> Slave (interface on top of Receive + Reapply)
> >>
> >> Is this your idea?
> >>
> >
> > Yes, and a Master, which will be on top of the Send component.
> 
> OK, so to summarize we have four low-level interfaces:
> 
>   Store
>   Send
>   Receive
>   Reapply
> 
> Then, we have two interfaces on top of these four:
> 
>   Master is on top of Send
>   Slave is on top of Receive + Reapply
> 
> If I understood right, Slave is needed for the few commands that are 
> shared by SQL thread and IO thread. What is Master needed for? Won't all 
> master functionality be in the Send component?
> 

Currently, Master need to handle slave register, which are not be part
of Send component. And in the future, we may add more feature to Master.

I think Store, Send, Receive and Reapply are re-usable components, which
will only provide the mechanism to read/write binlog (Store), transmit
events over network (Send), receive events from network (Receive) and
execute events (Reapply). All other replication logics such as
reading/saving configuration, starting/stopping threads, use one thread
or multi-thread for execution, etc, will be handled be the Slave or
Master component.

> /Sven
> 


Thread
bzr commit into mysql-trunk branch (hezx:3710) WL#5779He Zhenxing2 Mar
  • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779Sven Sandberg2 Mar
    • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779Sven Sandberg2 Mar
      • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779He Zhenxing3 Mar
    • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779He Zhenxing3 Mar
      • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779Sven Sandberg3 Mar
        • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779He Zhenxing3 Mar
          • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779Sven Sandberg3 Mar
            • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779He Zhenxing3 Mar
              • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779Sven Sandberg3 Mar
                • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779He Zhenxing4 Mar
    • Re: bzr commit into mysql-trunk branch (hezx:3710) WL#5779He Zhenxing3 Mar