← Back to team overview

maria-developers team mailing list archive

Re: Ideas for improving MariaDB/MySQL replication

 

Hi, Alex!

On May 13, Alex Yurchenko wrote:
> On Thu, 13 May 2010 16:36:41 +0200, Sergei Golubchik <serg@xxxxxxxxxxxx>
> 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



Follow ups

References