Inter-Sync Gateway Replication not working as expected

Mobile Sync Gateway
1

I have two sync gateways: Active and Passive. There is a replication running between them. When I create or update a document in the database of the Active Gateway it is replicated in the database of the Passive Gateway. However, if the same document is updated in the database of the Passive Gateway then the replication is not working anymore. I guess there is a conflict but my settings prefer remoteWins. Here is the config of my Active Gateway:

{
“databases”:{
“my-database”:{
“replications”:{
“my-repl-pushAndPull”:{
“direction”:“pushAndPull”,
“continuous”:true,
“purge_on_removal”:true,
“remote”:“https://remoteUser:password@remote.cluster.com”,
“filter”:“sync_gateway/bychannel”,
“query_params”:[“remote_channel” ],
“conflict_resolution_type”: “remoteWins”
}
}
}
}
}

Version: Enterprise 2.8

How can I make my replications work when I make changes or delete a doc on the passive side?

2

That is something I’d expect to work, especially with the config you’ve provided.
Just to check, the document you’re updating on the passive side remains in the filtered remote_channel channel right?

You should be able to tell from the logs on the active side if conflict resolution is happening.

3

Yeah, I also. expect it to work. There are no conflicts(409) in the logs of the active gateway(nor in the passive). I am changing some dummy field of the document so it stays in the channel. I’ve tried both conflict_resolution_type localWins and remoteWins in case I get it wrong. For some reason after update on the passive side the replication is not working and there is nothing indicating problems in the logs.

4

What do the stats say?

5

Hi Priya,
These are the stats after replicating one of the documents successfully and failing to replicate another one due to conflicts probably
{
“global-cont-pushAndPull2”:{
“sgr_num_attachment_bytes_pushed”:0,
“sgr_num_attachments_pushed”:0,
“sgr_num_docs_pushed”:1,
“sgr_num_docs_failed_to_push”:1,
“sgr_push_conflict_count”:1,
“sgr_push_rejected_count”:0,
“sgr_deltas_sent”:0,
“sgr_docs_checked_sent”:2,
“sgr_num_connect_attempts_pull”:1,
“sgr_num_reconnects_aborted_pull”:0,
“sgr_num_attachment_bytes_pulled”:0,
“sgr_num_attachments_pulled”:0,
“sgr_num_docs_pulled”:0,
“sgr_num_docs_purged”:0,
“sgr_num_docs_failed_to_pull”:0,
“sgr_deltas_recv”:0,
“sgr_deltas_requested”:0,
“sgr_docs_checked_recv”:0,
“sgr_num_connect_attempts_push”:1,
“sgr_num_reconnects_aborted_push”:0,
“sgr_conflict_resolved_local_count”:0,
“sgr_conflict_resolved_remote_count”:0,
“sgr_conflict_resolved_merge_count”:0
}
}

It seems like “conflict_resolution_type”: “remoteWins” is not resolving that.