Continuent Community

Hi,

I was just in an online presentation, and it briefly touched upon the next version of the tungsten replicator due later this year.

It was said that this new version would support multi-master replication, but that this multi-master replication wouldn't support (initially) conflict resolution, and that it was up to the application to do this.

I was just wondering to what level the tungsten replicator would help with the conflict resolution. I was just wondering how much (if any) of the job of conflict management would the replicator do. Will it *detect* the conflicts and notify us when they occur, even if it isn't able to actually go ahead and try to resolve them? I am not a big fan of automatic conflict resolution, as this is normally achieved by assigning some arbitrary "metric" to each cluster node, and then using that as a priority level of which database to "favour" in times of detection. That doesn't always yield the best selection, as to determine what data to prioritise usually requires actually looking at (and understanding) the data itself.

Even if there is no automatic conflict resolution, I would hope that if there were conflicts, that these would get detected, and a notification sent to us - so that the conflict doesn't go silently unactioned. And maybe also a quick and easy way to resolve the conflicts manually (kind of like a commandline version of the conflict viewer in MS SQL)

What would be really cool would be some kind of conflict management plugin system, where we could create our own logic for how to deal with any conflicts ourselves, that provides access to the actual data involved in the conflict

Regards,
Rob

Hi Robin,

Thanks for attending the presentation yesterday. It's very nice to hear from you again.

As I mentioned yesterday, we don't plan to attack conflict resolution immediately. Instead, the roadmap for multi-master replication looks like the following:

1.) Implement multiple replication services in a single Tungsten Replicator. This allows us to have a single replicator that functions as a master with respect to its local data source and a slave with respect to one or more other data sources. Without this capability you would have to install multiple replicators, which is ugly.

2.) Handle multi-master restart/failover. Let's say you set up two masters replicating bi-directionally over a WAN using independent replicator services. Each master has a local slave as well, so the topology looks like the following:

(M1 Slave) <--- (M1 Master) <---> (M2 Master) ---> (M2 Slave)

We now have to handle the case where one or the other master fails over to its local slave without losing our position or becoming confused. This allows us to handle maintenance and recover from failures.

3.) Add management language. We have an improved management language called "Camel" (Cluster Management Language) that allows you to define and manage the topologies conveniently through Tungsten Manager. This is just as important as the first two items.

This is all part of what we are billing as Tungsten 2.0, which will release in late Q3. It's driven by work with a couple of big SaaS vendors in the San Francisco/Bay Area.

Part of the reason that conflict resolution is not in is that we are looking at this problem a little more broadly and adding support for topologies where you have reference data generated in a central location that flows into other databases that themselves have updates. (Imagine a SaaS with a configuration database that feeds reference data to customer databases.) It's a pretty common topology and in fact seems to come up more commonly than the bi-directional case.

That said, conflict resolution is next on the list and would work exactly as you describe: there would be a plug-in designed to detect conflicts and allow call-out logic to decide what to do with them. At least that's our idea for now.

If you have a particular problem and want to fund development we would be very interesting in talking. Otherwise, that's our current priority for development.

Cheers, Robert