Data consistancy

Working with Data
1

I have 5 nodes in total - 3 in EU (1 primary and 2 secondary) and 2 in US (both secondary).
If the transaction writes the data in primary, how much time does it take to update the secondary nodes with data written in primary node?
Will the time taken to update all the secondary nodes are same irrespective of the region?

2

Hi @Chaitanya_Tilwankar ,

The replication is asynchronous therefore its hard to say the exact timing , and it depends on many factors like network and compute speed.

What you can control is the write concern which will only acknowledge a write when it happens on specific number of nodes , based on majority/tag or number.

Ty
Pavel

3

Thanks Pavel. A basic question but in the deployment I mentioned above, will all the instances (say 5) of my server be connected to only the primary node? And only when primary goes down, then all those connections will move to next node taking over and acting as primary?

4

So if you use a connection for replica set you will be connected to all nodes , when writes are only happening on Primary. Once a new primary is elected for any reason writes will be redirected there…

Now for reads you have a setting called readPreference where you can read from secondary or nearest nodes. This is only for read operations.

Thanks

5

Welcome to the MongoDB Community @Chaitanya_Tilwankar !

By default secondaries will either sync from the current primary or a closer secondary using Chained Replication. All members of a replica set also send regular heartbeats to each other.

In your deployment scenario with replica set members in the EU and US, it is likely that replica set members will choose a local sync source where possible to minimise the network latency (EU from the primary in EU, one of the US members from EU and the other US member from the US) .

As Pavel mentioned, client applications will be connected to all members of your replica set and automatically discover changes in topology.

The default write concern for MongoDB 5.0+ drivers is w:majority, which would require write acknowledgement from 3 members of your replica set (assuming all 5 are voting).

Your deployment may have a few broad latency characteristics:

  • If all replica set member are healthy, majority writes can be acknowledged by the 3 members in your primary data centre in EU.

  • If any of your EU replica set members are unavailable, majority writes will require acknowledgement from one of your replica set members in the US so majority write latency will likely increase.

Since you refer to EU as your primary data centre and only have two members in the US (which would not be able to sustain or elect a primary in the event of a network partition) I assume that the US members will have lower priorities. If you also made the US members non-voting this would provide more predictable majority write latency: there would be 3 voting members (all in EU) and the strict majority required to acknowledge majority writes would be 2. In this scenario you could also use Replica Set Tag Sets with a custom write concern to ensure important writes are acknowledged by members both regions.

Regards,
Stennie