maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

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. ;)

Hm.

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

    BEGIN; INSERT INTO t1 VALUES (...); COMMIT;

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
uniformly?

 - Kristian.