0

I got a deployment with three nodes:

A: priority 2, vote 1
B: priority 1, vote 1
C: priority 0, vote 1

In normal case, A is Primary, B/C are Secondary. Assume the at a time point, B got oplog the timestamp of which is 100, C got 110. Then A crash, What will happen exactly?

As describe in this document, Priority 0 Replica Set Members will never become primary, so I think B will become primary, but what about the data. I'm using MongoDB 4.4 BTW.

Thanks for any input.

1

1 Answer 1

1

Expected Behaviour

In your MongoDB 4.4 scenario with:

  • A: preferred primary down
  • B: only available candidate for primary
  • C: dedicated secondary with newest oplog

The expected outcome is that:

  • B will become the new primary.
  • C will rollback writes to the last oplog state in common with B so replication can resume.

... and when A eventually recovers, it will rejoin as a secondary until it catches up with B and can trigger an election to become primary again.

By default, any documents rolled back will be saved as BSON files in the <dbpath>/rollback/<collectionUUID>/ directory on the affected replica set member. You can manually reconcile the rollback files with current data if applicable.

Improving Resilience

If you want to minimise potential for rollbacks I recommend setting C to the same priority as B and using a w:majority write concern.

The w:majority write concern ensures acknowledgement from a majority of data-bearing voting members of the replica set (which includes C in the starting config of priority:0, vote:1). Setting B and C to priority:1 allows whichever member has the newest oplog entry to become primary in the event the preferred primary A is unavailable.

For a less optimal configuration you could set C to a non-zero priority lower than B (eg 0.5). In theory that would let C briefly become primary (assuming it had a later oplog entry than B) until B caught up and triggered an election due to the higher priority. In practice I think it would be better to minimise elections.

Quoting MongoDB 4.4: Replica Set Elections docs on Member Priority:

After a replica set has a stable primary, the election algorithm will make a "best-effort" attempt to have the secondary with the highest priority available call an election. Member priority affects both the timing and the outcome of elections; secondaries with higher priority call elections relatively sooner than secondaries with lower priority, and are also more likely to win. However, a lower priority instance can be elected as primary for brief periods, even if a higher priority secondary is available. Replica set members continue to call elections until the highest priority member available becomes primary.

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.