I’m looking at the M10 dedicated tier and it says the pricing includes “3 replica sets”. I see MongoDB docs about replica sets and I think I understand the basic concept: it’s like a fancy load balancer.
However, I’m unclear how replica sets integrate with Realm and specifically Realm Sync. Are replica sets something I can take advantage of when using Realm Sync via the Swift SDK? If so, are there any changes I need to make to the client code?
Is the M10 tier cheaper if I don’t use replica sets at all? Thanks.
Not really, at least not as their main purpose: Replication is a way to increase resilience and ensure your data is available and consistent at any time, no matter if a server needs to step down. While writing can only happen on the primary, it is possible to offload tasks to secondaries: you can find a lot of examples in the courses available on MongoDB University.
Not directly through the Realm SDK, as that’s a client framework: you can however configure the backend to perform better by tweaking the Data Source Configuration, according to your use case. This is especially true if you’re running backend-side logic, like Triggers or Functions, that may well work by reading data from secondaries, leaving the primary with more resources to operate Device Sync.
At this time, this is not an option, and would be unadvisable to do so, for the reasons outlined above: Three Members Replica Sets are also the bare minimum for the functionality to work, large production systems have usually more nodes.
Ah, I see. I have no functions or triggers running for this client. Is it the case that device sync does not benefit from replica sets? That is, sync must be run by the Primary node only? If so, the benefit of replica sets is reduced to fault tolerance, correct?
Does the pricing in M10 that includes 3 replica sets cover spreading the sets over different physical data centers?
One factor to keep in mind, however, is that the App Services app (that includes services like Device Sync) doesn’t run on your cluster, but on specific VM(s), deployed on the same range of providers, but not necessarily the same region: more info in the docs.
To maximise performance, then, it’s important to keep your cluster in a region as close as possible (the same, ideally) to the one you choose for the app. While it’s possible to have the app and the cluster run on different providers, it’s a common misconfiguration, as it introduces lag and inter-provider traffic costs.