Alex Yurchenko <alexey.yurchenko@codership.com> writes:
On Mon, 15 Mar 2010 10:57:41 +0100, Kristian Nielsen <knielsen@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.