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

More eligible nodes for hedged nearest reads

    • Fully Compatible
    • Service Arch 2020-02-24, Service Arch 2020-03-09, Service Arch 2020-03-23, Service Arch 2020-04-06, Service Arch 2022-05-30, Service Arch 2022-06-13, Service Arch 2022-06-27

      For reads with readPreference nearest, we only consider nodes within the acceptable latency window (currently the ping time of the closest node, up to the ping time of the closest node + 15ms). This can often select only a single node (if the replica set members are in distinct physical locations more than 15ms apart).

      This is less than ideal when considering implicit read hedging, in that hedging can only be performed against the originally returned list of eligible nodes. I.e. if you have 1 closest node, and use read preference nearest, you would never actually hedge any reads.

      The proposal here is to alter the behavior of read preference nearest, for the purposes of read hedging, to submit hedged reads to nodes outside the latency window. My suggestion is to essentially recompute what "nearest" would be, after removing the first node from consideration. I.e. if my replica set looked like: [ Closest(5ms), Next(100ms), NextAgain(105ms) ], that you would submit the initial read to Closest, then randomly dispatch the hedged read to Next or NextAgain.

            Assignee:
            shameek.ray@mongodb.com Shameek Ray
            Reporter:
            mira.carey@mongodb.com Mira Carey
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: