← Back to team overview

maria-developers team mailing list archive

Re: Ideas for improving MariaDB/MySQL replication


Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx> writes:

> On Mon, 15 Mar 2010 10:57:41 +0100, Kristian Nielsen
> <knielsen@xxxxxxxxxxxxxxx> wrote:

>> What I am wondering at the moment is if the concept of global
> transaction
>> ID
>> should be a part of the new API, or if it is really an implemtation
> detail
>> of
>> the reduncancy service.

> I'd go about it in the following way. We have an SQL server proper. And it
> has a state (database). And it is a state of the server that we want to be
> redundant (replicate, log, whatever). The particular server state is
> identified by a global transaction ID. From here is follows that global
> transaction ID should be the same regardless of the plugin.
> It is also quite clear that each plugin will be using its own ID format
> internally. E.g. binlogger will be obviously using file offsets and Galera
> will be using 64-bit signed integers. Then plugins will just have to
> implement their own mapping to the ID defined in API. Which in most cases
> will be trivial.
> Having a unified global transaction ID is unbelievably good, especially
> when you have cascading replication, where each cascade can use its own
> plugin. It is so good that you will never ever have any troubles with it,
> and no troubles with global transaction ID amounts to nirvana. ;)


So in such cascading replication scenario, the changeset would actually keep
its identity in the form of the global transaction ID?

So if on master1, the user does


this might get global transaction ID (UUID_master1, 100)

This might get replicated to a slave1 with multiple masters. The slave1 might
then end up with three changesets, the one from master1, another from master2,
and a third made by the user directly on slave1:

    (UUID_master1, 100)
    (UUID_master2, 200)
    (UUID_slave1, 50)

So what if we now want to cascade replicate from slave1 (now as a master) to
slave2? Would slave2 then see the same three global transaction IDs?

    (UUID_master1, 100)
    (UUID_master2, 200)
    (UUID_slave1, 50)

That does not seem to work, does it? Seems to me slave1 would need to assign
each changeset a new global transaction id in order for slave2 to know in
which order to apply the changesets? In particular, whether to apply
(UUID_slave1, 50) before or after (UUID_master1, 100).

So I think I misunderstood you here?

Or did you mean that the _format_ of the global transaction ID should be the
same across all plugins, so that in a cascading replication scenario where
servers are using different replication plugins, the IDs can be treated

 - Kristian.

Follow ups