maria-developers team mailing list archive

[Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx>]

On Fri, 19 Mar 2010 13:16:30 +0100, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx> writes:
> 
>> This is an interesting option indeed. However
>> 1) the mapping itself should be durable, so every plugin must design
the
>> way to recover it in the case of crash.
>> 2) global transaction ID better be integral part of the server state,
>> otherwise it will complicate state snapshot transfer. E.g. it will be
>> insufficient to just use mysqldump or copy db files, you'll need to
carry
>> global transaction ID along.
>>
>> The above issues are of course resolvable one way or another. It is
just
>> not obvious what is easier: fix the engine or implement a workaround
(if
>> you consider it in all entirety)
> 
> Well, we want to fix all engines we can, and leave an option for
backwards
> compatibility with engines we cannot.
> 
> The problem is not so much if it is easy to fix the engine, the question
> is if
> it is possible? We have to pre_commit the transaction in the engine
before
> we
> know the global transaction ID. And once the transaction is
pre-committed,
> we
> cannot add anything to it, so cannot add the global transaction ID. Or
is
> there a way around this?
> 

I think that you were absolutely right here from the start: redundancy
service has to maintain the mapping local_trx_ID->global_trx_ID. I just
forgot that we will expose local transaction ID to the redundancy service
anyways.

Notice however possible many-to-1 relation between redundancy plugins and
RS and therefore - global transaction ID. So I'd suggest that a unit other
than redundancy plugin would maintain this mapping.

Alex