Is it possible to distribute my xDB MongoDB databases over 3 locations?

Question

So I've been reading up on geographically distributed MongoDB setups.

I am juggling around an architectural approach/concept for a project. This is roughly what I am looking at.

• A centralised Content Master setup "somewhere" in the Cloud
• Regional or National Content Delivery servers to
  1. Keep the CD server as close to the visitor as possible/feasible
  2. Allow the CD server to live communicate with regional/national systems

If I understand the linked article above right; I should be able to set up a three-member replica set in the following manner:

• One MongoDB server on regional/national location/datacenter
• One MongoDB server in the global location
• One MongoDB server "somewhere else" in the Cloud

And by doing so, I ensure (or do my best to) maximum availability and resilience for the setup.

So my question is this; this all looks fine and well "on paper". But will it work in real life? I mean with the potentially massive amount of data being dumped into the local xDB; do I risk that the other 2 members simply never catch up as there isn't enough "bandwidth in the world" to handle the replication?

Answer 1

Sitecore-specific replica set considerations

Your question is partially answered here:

What are the best practices for MongoDB replica set latency?

That question discusses how latency affects a replica set and how to set it up properly for xDB.

As a short summary, you should set up xDB to only read from the primary node of your replica set. This will ensure that all CD servers see the same consistent data set.

Replica set data synchronization

Main article: https://docs.mongodb.com/v3.2/core/replica-set-sync/

Since all of your instances will read and write from the same MongoDB server, replication rates should only bother you in case of a failure. If your primary node fails, you don't want other nodes to be far behind on replication—otherwise, they won't be able to become the new primary.

Luckily, that is rarely an issue. Secondary members copy the oplog from their sync source (normally, the primary node) and apply these operations in an asynchronous process. Oplog entries are often more lightweight than actual data modifications—think of the size of an update query vs the size of data it modifies. Even if your application mostly creates new data (which is what xDB does), syncs are done in bulks, which means they're more efficient network-wise.

You can always check how big the lag is between your nodes and take measures, such as ensuring there's enough bandwidth between your servers. But this is almost never an issue. One important thing to consider, though, is whether your primary node's inbound bandwidth is much faster than the outbound bandwidth. This may cause increased replication lag in some situations.

As a summary, a geographically distributed replica set is a very good idea and is unlikely to give you synchronization problems.