Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-89619

Avoid serving stale data with primary read preference + majority read concern on old primary during an unplanned election

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 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.

            Assignee:
            Unassigned Unassigned
            Reporter:
            kaitlin.mahar@mongodb.com Kaitlin Mahar
            Votes:
            0 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated: