I’m working on a scenario with one central CB instance and several remote CB instances.
The replica is managed with Inter Sync Gateway. Each remote SG defines two distinct replicas connected to the central SG: a push and a pull. I’d like to be aware about how the conflicts can be generated and how to prevent them.
My remote instances are very unstable so it could be very likely that the same document can be modified centrally and locally, but the locally is “offline”.
I know that quering the _replicationStatus admin rest api return the number of found conflits. Is there a way to get exacly the document key with conflict using the admin rest api or looking in the bucket documents? Moreover, looking at the same central document and local document metadatas, how can I understand that is present a probable conflict? There is a lot of information in the xattrs._sync: rev, sequence, history (with revs and parents …).
I’ve understood that the push replica doesn’t manage any conflit resolution. Our client should have the EE, so I’m wondering if is possible to define a simply “Conflict Resolution Policy” on the push replica, or if the push replica conflict resolution limitation is present also when a “Conflict Resolution Policy” is defined?
The documentation suggests to move the local push to the central SG, transforming in a pull. Ok, but I’d like to better understood how the Automatic Conflict Resolution, let’s say the default, works? How it’s elected the winner? Maybe it will be clear after the explanation about the above points, at the moment I’ve not understood how to infer the “most recent” document looking at the metadata both sides.
Thanks a lot for you colllaboration,
As you’ve noted, conflict resolution occurs as part of a pull replication. The configuration you’ve got - push and pull replications running on the remote clusters - should be fine; the pull replication on the remote SG instances can perform conflict resolution.
A conflict is going to occur when the document is updated in both the remote and the central cluster. Sync Gateway identifies that conflict based on the document revision’s revision history (stored as revision ID). You shouldn’t need to introspect xattrs._sync - that’s primarily internal information used by Sync Gateway to manage replication. The revision ID is available via SG’s REST API, if needed.
Automatic conflict resolution is based on the most frequently updated conflict, and not “most recent”. Specifically, in the case of a conflict, the revision with the most mutations (represented by the generation in the revision ID) will be picked as the winner.
I’d like to share just more considerations to better focus on the best approach. Considering your suggestion to keep the architecture as-is, the conflit will be resolved at remote side once the central will generate an update on the document. My original problem, that lead me to open this thread, was that the same document has been modified both side during a remote offline period. The most updated document was the remote one. But, once the remote returned online, then I suppose that it tried to push the update to the central obtaining a conflit, that keep on the central the old document. So, after trying without any success to update the remote one (the conflit continue to occur), I’ve copied the entire document body from the remote to the central (with the console) and then the conflit disappears, probably because the remote pull correctly manage as expected.
My first doubt is: How can I get exactly all the documents involved in a conflit? I need a way to be aware about them, I know the count from the replica status, but I don’t know their ID.
Moreover, if I move the push from remote to central, transforming in a pull, I’ll be more confident that any document modification will be always synched because the pull is able to apply the configured resolution type, is it correct?
Thanks for your help.
any news about the last questions?
I’ll really appreciate any help or suggestion.
Thanks for the kind collaboration,