← Back to team overview

maria-developers team mailing list archive

Re: Ideas for improving MariaDB/MySQL replication


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
>> 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
>> global transaction ID along.
>> The above issues are of course resolvable one way or another. It is
>> not obvious what is easier: fix the engine or implement a workaround
>> you consider it in all entirety)
> Well, we want to fix all engines we can, and leave an option for
> 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
> we
> know the global transaction ID. And once the transaction is
> we
> cannot add anything to it, so cannot add the global transaction ID. Or
> 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

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.


Follow ups