![](https://secure.gravatar.com/avatar/e116f298afc14b2ee30632c823110d84.jpg?s=120&d=mm&r=g)
Alex Yurchenko
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 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
On Fri, 19 Mar 2010 13:16:30 +0100, Kristian Nielsen
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