![](https://secure.gravatar.com/avatar/e116f298afc14b2ee30632c823110d84.jpg?s=120&d=mm&r=g)
Hi!
On Wed, 19 May 2010 15:05:55 +0200, Sergei Golubchik
Yes, it only describes how the data get to the redundancy service, but not what happens there. I intentionally kept the details of redundancy out, to be able to satisfy a wide range of different implementations.
For example, if I'd put a global transaction ID explicitly in the model, then MySQL replication would not fit into it - it has such a concept only implicitly, as you have noted.
So, what I did was, as Robert Hodges put it, "pushed the can down the road", and let the redundancy service to take care of the transaction ids.
But perhaps I'm biased and the model I've described is influenced by MySQL replication more than it should've been ?
Oh, not really. I just wanted to note that while you were proposing a useful framework, you did not touch actual replication/redundancy specifics. Speaking of current MySQL replication, I was skeptical from the beginning that it will fit into new redundancy service in its current unmodified form. It is simply too integrated with the server for that (just think of all those HAVE_REPLICATION ifdefs). That's why I proposed to keep them side by side and not try to unify them. It would be a shame to adapt new replication architecture to existing MySQL replication. I believe it should go the other way around. And seriously, mapping an integer to a file offset is a student's play and is a minor tweak compared to making MySQL replication a module of a new redundancy service. So it is just a matter of administrative decision - will _MariaDB_ replication have explicit global transaction IDs or not. Regards, Alex -- Alexey Yurchenko, Codership Oy, www.codership.com Skype: alexey.yurchenko, Phone: +358-400-516-011