I'm looking to setup a environment with 3 MongoDB (1 x Primary and 2 x Secondary nodes) in different regions and wondering if:

  1. Is there any recommendations on latency (in ms) limitations for the synchronization of the data?
  2. Is there a way to avoid issues due high latency?
  3. Best practices are very welcome

2 Answers 2


In general, if your data nodes are hosted in different geographical regions, latency between them will be considered high.

Write concern

High latency will make the replication process slower, which means that using the write concern of w:1 is highly recommended in order to prevent performance degradation. On the other hand, if the majority of your nodes were hosted in the same data center, you'd be fine with using w: majority, which would improve your data safety without compromising performance.

Read preference

Given that you use w:1, you should use the read preference of primary or primaryPreferred. If you allowed reading from the secondaries, there would be no guarantee that the data read is up-to-date, which would lead to errors, such as contact locking inconsistencies.

On the other hand, if you had low latency between all replica set nodes, and given that you used w:3 (or whatever your total number of nodes would be), then you could consider the read preference of secondary, secondaryPreferred or nearest. Although, this would only be recommended in read-heavy environments, which most Sitecore installations are not.


To prevent issues caused by high latency, use the write concern w: 1 and the read preference primary or primaryPreferred.

Further reading


To answer your questions:

  1. Every latency you have, is always too much latency. You would always prefer to not have too much latency. What I would do is set up the replicaset and check which one causes the most latency and the set up that specific note to never becoming the primary. It can still vote but will never have the upper hand in become a primary, therefor causing no trouble.

  2. You can never really avoid having latency issues because you are depending on what the datacenter has to offer you. I nice feature is the OPS manager of Mongodb. It will monitor your replicaset and it will gives you information and possible fixes if there are issues. We have a replicaset located in one location, but I figured out the hard way, if the replicaset is not available, your site will continue to work anyway, so no problems for that.

  3. Best practices there are enough. Indeed focus on your Write and Read concerns having them to be the best for your platform. If you never want to lose any data in your replicaset, I would recommend you to use w:majority Then you will always have the data written the database on the majority of your replicaset. If you use w:1 it will only be cached in memory and at the fail of an instance, your data will still be lost.

Another advise, when spreading out a replicaset over 2 datacenter ill cause you to have 1 server in 1 datacenter and 2 servers in another datacenter. If the datacenter containing the 2 servers collapses, your single server will never take over your replicaset as it will not get 2 vote to become the primary. If you are really thinking of separating the replicaset over more than 1 datacenter, you should think of more instances or maybe "hidden" instances to make sure your votes are dividend to always reach a majority vote counting.

  • "If you use w:1 it will only be cached in memory" — actually, provided that you use j: true, your data will be saved to the on-disk journal. Data won't be lost if you restore the node to a running state. Commented Oct 14, 2016 at 13:19
  • You are true about that, but with a server crash, you cannot imply your data to still be present where you left it. Commented Oct 14, 2016 at 13:27
  • What I meant was that in many cases, the journal operations will be applied to the working set once you restart mongod, and your data won't necessarily be lost just because you used w:1. But of course, using a proper replication setup is far superior in many ways. Commented Oct 14, 2016 at 13:29
  • 1
    You are true about that, but I would not recommend to use it, because when your mongo instance will crash, it still has it's journals. But when the node comes back, and isn't the primary node anymore, you will have a change of the journal being overwritten if you only use w:1 j: true does not by itself guarantee that the write will not be rolled back due to replica set primary failover.(docs.mongodb.com/manual/reference/write-concern/#wc-w) Commented Oct 14, 2016 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.