On Fri, 19 Mar 2010 13:16:30 +0100, Kristian Nielsen <kniel...@knielsen-hq.org> wrote: > Alex Yurchenko <alexey.yurche...@codership.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
