-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Replication
As discussed on SERVER-53813 (which covers a different but related issue), during an unplanned election we can transiently have two primaries. If a user is interacting with a replica set through multiple mongoses (or multiple driver MongoClient instances), they can end up reading stale data, even when using majority read/write concern and primary read preference, as follows:
1. mongos1 or client1 is aware of the new primary, and performs a majority committed write on it
2. mongos2 or client2 is not yet aware of the new primary, and performs a majority RC + primary read preference read on the old primary, and reads data which does not reflect the new write
With a single mongos/client, electionId is used to differentiate which primary is newer.
This is not a bug, however it would be a nice improvement if we could prevent this issue.
- related to
-
SERVER-53813 Avoid serving stale majority reads on new primary after election
- Closed