Hi Mats
Can I write binlog using the injector interface directly in the normal
processing thread, rather than using a seperated thread?
The code of injector thread of NDB seems very complex. Oh my god, it
will be a hard task.
On Fri, Nov 20, 2009 at 4:45 PM, Mats Kindahl <mats@stripped> wrote:
>
>
> Yuan Wang wrote:
>> Hi Mats
>>
>> Thank you for your kind reply. But how to handle binlog in the engine?
>> Could you be so kind to give me some hints?
>
> Hi Yuan,
>
> The only self-logging engine that MySQL has is NDB. It keeps a separate injector
> thread which receives events from the NDB cluster and inject them into the
> binlog using the injector interface.
>
> If you take a look at ha_ndbcluster_binlog.cc, you can see how it works.
>
> Best wishes,
> Mats Kindahl
>
>>
>> On Fri, Nov 20, 2009 at 4:06 PM, Mats Kindahl <mats@stripped> wrote:
>>> Hi Yuan,
>>>
>>> No, you are understanding it correctly, each statement is a transactional
> unit
>>> and all rows are cached until the statement completes.
>>>
>>> You might be able to use the "self-logging" flag to indicate that the
> storage
>>> engine is going to handle the logging itself.
>>>
>>> Best wishes,
>>> Mats Kindahl
>>>
>>> Yuan Wang wrote:
>>>> We are developed a storage engine using row based replication. This
>>>> engine is non-transactional and will use row level locking. The row
>>>> locks will only be holded for a very short time, just to protect a
>>>> single row from concurrent update. If a statement updates multiple
>>>> rows, the engine will lock the first row, update it, unlock it, and
>>>> lock the second row, update it, unlock it, etc. So the following
>>>> senario is possible:
>>>>
>>>> statement 1: update row1;
>>>> statement 2: update row2;
>>>> statement 1: update row2;
>>>> statement 2: update row1;
>>>>
>>>> That is. The final state of row1 is statement 2's, and the final state
>>>> of row2 is statement 1's. For proper replication, the binlog events
>>>> should be written is the following order:
>>>>
>>>> statement 1's update of row1;
>>>> statement 2's update of row2;
>>>> statement 1's update of row2;
>>>> statement 2's update of row1;
>>>>
>>>> However based on the manual, it seems that multiple binlog events of
>>>> the same statement will be cached and be written as a whole unit when
>>>> the statement finished.
>>>>
>>>> This will lead to improper replication. So I'm curious to know is this
>>>> the case or I misunderstanded.
>>>>
>>> --
>>> Mats Kindahl
>>> Senior Software Engineer
>>> Database Technology Group
>>> Sun Microsystems
>>>
>
> --
> Mats Kindahl
> Senior Software Engineer
> Database Technology Group
> Sun Microsystems
>
