Re: Postgres BDR Conflict Issue

On 20 November 2015 at 14:18, vikas452 <vikas452(at)gmail(dot)com> 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:

http://bdr-project.org/docs/next/conflicts.html

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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services