What are the best practices for MongoDB replica set latency?

Question

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

Answer 1

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.

Summary

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

Further reading

• Write concern (MongoDB)
• Read preference (MongoDB)
• MongoDB example architecture (Sitecore)

Answer 2

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.