Alex Yurchenko <alexey.yurche...@codership.com> writes:
> On Mon, 15 Mar 2010 10:57:41 +0100, Kristian Nielsen
> <kniel...@knielsen-hq.org> 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.
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
