Yuan Wang wrote:
> Hi Mats
>
> Can I write binlog using the injector interface directly in the normal
> processing thread, rather than using a seperated thread?
Yes, that should work. However, note that the injector takes a lock on the
binlog when committing the "transaction".
> The code of injector thread of NDB seems very complex. Oh my god, it
> will be a hard task.
:)
You only need to check the code that fetches an injector and how it is used. You
can ignore the rest.
Best wishes,
Mats Kindahl
>
> 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
>>
>
--
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
