We are having a scenario where couch base cluster cb1 is connected to sync gateway sg1 and couch base cluster cb2 is connected to sync gateway sg2.
We have sync gateway to sync gateway replication running between sg1 and sg2.
The application is connected to sg1. but in some circumstances we need to switch the application from sg1 to sg2. Ideally the data will eventually consistent because the replication is running between them.
What is the best strategy to use while switching URLs of sync gateways.
Should we only stop the replication and change url and then restart the sync or should we create a new manager, database, Replication object with the new URL.
Ideally the data will eventually consistent because the replication is running between them.
Correct, and it should be relatively low latency. If you see much higher latency than expected, can you please report an issue?
Should we only stop the replication and change url and then restart the sync or should we create a new manager, database, Replication object with the new URL.
If you create a new database it will (needlessly) resync all of the data from the Sync Gateway. All that you should need to do is to:
Stop existing replicator pointing to sg1
Create and start a new replicator pointing to sg2
What I would expect to happen is to have a lightweight “catch up” process with sg2, since it might not have any checkpoint stored on sg2 in sg2’s “_local/{client-hash}” docs, if it’s the first time connecting to sg2. So it will “walk” the complete changes feed, but it will not be syncing any actual revisions, since it will already have them. So on the pull replication, I’d expect to see lots of _changes and _revs_diff requests, but very few _bulk_get requests.
I think the suggestion you provided is also correct for peer to peer. Where application was syncing to sg1 and it goes off line, and on other tablet the same application is running. Now these two can sync data with each other by changing the sync gateway URL.
I do see lot of _revs_diff calls because right now, as it only do it for 100 documents at once. Is it possible to increase this number?
So that if the sync between cb1 and cb2 is good then _revs_diff wont give new docs. We want to have this _rev_diff calls to finish faster then they do right now in Android.
Secondly the check points are stored a local documents on sync gateway which doesn’t sync across sync gateways. Is it a possibility to sync them through sync gateway so that walk through is not required?
Or is it a possibility to save this in normal documents which can sync?
Will we have same mechanism of _rev_diff in 2.0 also, Or will it be faster. Right now our application have number of documents ranging from 20k to 80k. Having 100 revisions per call makes it very slow. Please suggest.
Try increasing that, which will control how many changes are pulled in each iteration, which will directly affect how many documents are in the _revs_diff call.
Secondly the check points are stored a local documents on sync gateway which doesn’t sync across sync gateways. Is it a possibility to sync them through sync gateway so that walk through is not required?
Yes, that’s correct. That is by design, and since the two SG instances are eventually consistent, it wouldn’t be safe to do so without risking missing mutations.
Will we have same mechanism of _rev_diff in 2.0 also, Or will it be faster. Right now our application have number of documents ranging from 20k to 80k. Having 100 revisions per call makes it very slow. Please suggest.
Currently the SG ↔ SG replication doesn’t work with the 2.0 replication protocol. That would be a great enhancement though! Thanks for bringing that up.
changes_feed_limit for SG <–> SG worked perfectly.
Till now we haven’t found any issue in sync gateway replication apart from the point that it only works on Admin port.
But the issue is when we do sync between Sync gateway and couch base lite after change of sync gateway URLs(when the couch-base server is changed), For the first time _rev_diff call between lite and gateway takes time because of the number of calls. And yes we doesn’t get _bulk_get because the SG<–>SG is spontaneous.
trying to reduce _rev_diff between sync gateway and couch-base lite and surely some help is required.
Yes you are correct. SG<-> SG replication is bi-directional and writes can happen on both sync gateways. And we dont have issue with that. The data does sync to the applications.