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?
/Sven
