On 20 November 2015 at 14:18, vikas452 <vikas452@xxxxxxxxx> wrote:
Hi
We are setting 4 node BDR replication setup at our end.
BDR Version is 0.8.0-2014-12-28-15f97b3.
I am continuously getting following logs in the log file.
CONFLICT: remote UPDATE on relation public.agents originating at node
6208111525856296403:1:16384 at ts 2015-11-19 00:02:01.861176+05:30; row
was previously updated at node 0:0. Resolution: last_update_wins_keep_local;
Can somebody help me with this?Any solution to avoid such conflicts.
Avoid issuing updates to tuples on multiple nodes, at least before the prior update has replicated.
BDR is asynchronous. If you have asynchronous multi-master and you perform simultaneous actions on two nodes, when the changes replicate there can be conflicts. Some form of resolution is required.
Async multi-master is hard. The docs try to address these topics. I would value your comments on them in terms of which parts are clear, which are hard to follow, etc, after a detailed reading.
The docs have been significantly updated for the 0.10.0 development version, so I suggest going to those for the conflict resolution coverage. See:
Your comments would be appreciated.
Also is there any way to set the value of bdr.bdr_conflict_resolution.
I want to test last_update_wins_keep_remote as the conflict resolution type.
The conflict resolution strategy used here is "last update wins", i.e. the most recent change is the one that is kept. In this case the most recent change was the one made locally, so the remote change is discarded.
You can't force last_update_wins_keep_remote, that doesn't make sense. If you force keeping the remote tuple it isn't a last-update-wins resolution anymore.
What you can do is define a custom conflict handler that always keeps the remote tuple on one node and the local tuple on the other, based on inspecting the local node id. You *must* make sure the resolution is consistent on all nodes or data will diverge. I do not recommend doing this.
