![](https://secure.gravatar.com/avatar/c0f2404e2771a56ca8539ee0a404b598.jpg?s=120&d=mm&r=g)
Hi Seppo,
On 1/29/10 4:36 AM PST, "seppo.jaakola@codership.com"
Thanks Robert, this is comprehensive enough :)
I'll just address the consistency checking requirement here, as I believe this is quite widely accepted goal as well.
Tungsten uses a special consistency table for passing consistency checking information and which is treated in a special way in the replication. This kind of consistency checking can be managed by replication system configuration and it does not necessarily require any new calls in the replication API (except the configuration, which must be there anyway).
Tungsten consistency checking technology works very well, and there is no need to "fix it" in any way. However, this method is not directly usable for multi master replication, because the target node(s) may have committed some transactions not yet seen in the originating master node, and these new transactions can interfere with the consistency check query.
I'm sure I should really know this already, but does your statement amount to saying the consistency check needs to execute in total order with other change sets? Or are there other data visibility issues along the lines of non-repeatable reads that would cause you to get different answers on different servers?
To support multi-master topologies, the Replication API could support consistency checking directly. At first look, it seems that (at least) two calls would be needed for it: * replication_prepare_consistency_check(), to start checking transaction with consistent snapshot. * replication_check_consistency(query, result), to run a wanted select query in prepared transaction and comparing results in all the nodes.
But how to trigger the consistency checking? That's a question, that does not touch replication API directly, but affects the SQL layer. There could be a totally new consistency check command or SELECT query could have a new option for triggering consistency check. Consistency call could be also passed as comment (for select), like: SELECT MD5(...) FROM ...; /* replication-consistency-check */
But, I don't want to dive any deeper in this specification at this point. Just wanted to bring to the attention the possibility of opening consistency checking in replication API and SQL layers. And that multi-master consistency checking requires special attention.
Cheers, Seppo
-- http://www.codership.com seppo.jaakola@codership.com
Quoting Robert Hodges
: