![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
Hi, Alex! On May 13, Alex Yurchenko wrote:
On Thu, 13 May 2010 16:36:41 +0200, Sergei Golubchik
wrote: * there's no explicit global transaction ID here, but I presume there can be a filter that adds it to events. That would work, as long as replication decides on the commit order (which is does, even now in MySQL/MariaDB).
Well, I cannot really argue against what you're proposing, as it is all nice.
However, as a side note, my impression is that you're proposing generic message passing architecture, not a replication/redundancy model. The difference is that you can implement all these producer-consumer interfaces, but it is not enough to make a redundancy service - you'll be just passing messages around. Global transaction ID is not just "nice-to-have". It is a cornerstone of the redundancy model that we proposed in that it defines a state if the database, thus making it possible to talk about a database state, comparing states, recovering a state, transferring a state and so on. There (perhaps) can be other redundancy models, but your proposal seems to deal solely with message passing, filtering and protocol encapsulation, with no redundancy in any recognizable form.
This is not to say that your proposal is not good - as a middle-level implementation detail it may be the way to go. Just wanted to point out that it is not enough for redundancy/replication system. And I'd be seriously curious to see how you could make it without pulling in global transaction IDs (at least implicitly, as it is done in the current MySQL replication)
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 ? Regards, Sergei