Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-1969

Ignore read preference for $out/$merge on secondaries if any servers are pre-5.0

    XMLWordPrintableJSON

Details

    • Spec Change
    • Status: Closed
    • Major - P3
    • Resolution: Done
    • None
    • CRUD
    • Needed
    • Hide

      In mongodb/specifications@747b748, the rules were applying a read preference for aggregations using $out and $merge was changed. Previously, drivers were instructed to attempt using the read preference and only fall back to a primary if a pre-5.0 secondary was selected.

      This was changed to require drivers to always disregard the read preference if there is any evidence of a pre-5.0 server. If there are either no available servers or all servers are 5.0+ (or load balanced, where we assume 5.0+), drivers can utilize the read preference.

      Spec tests have not been changed, as this clarification really only changes behavior for mixed version clusters or a replica set consisting of a single pre-5.0 primary, neither of which are tested.

      Show
      In mongodb/specifications@747b748 , the rules were applying a read preference for aggregations using $out and $merge was changed. Previously, drivers were instructed to attempt using the read preference and only fall back to a primary if a pre-5.0 secondary was selected. This was changed to require drivers to always disregard the read preference if there is any evidence of a pre-5.0 server. If there are either no available servers or all servers are 5.0+ (or load balanced, where we assume 5.0+), drivers can utilize the read preference. Spec tests have not been changed, as this clarification really only changes behavior for mixed version clusters or a replica set consisting of a single pre-5.0 primary, neither of which are tested.

    Description

      Currently the specification says:

      - If an explicit (i.e. per-operation) read preference is specified for an
        aggregation with a write stage, drivers MUST attempt to use it. If that would
        result in a pre-5.0, secondary server being selected, drivers MUST instead
        select a server using a primary read preference.
      - If no explicit read preference is specified but a default read preference is
        available to inherit (e.g. from the Collection), drivers MUST attempt to use
        it. If that would result in a pre-5.0, secondary server being selected,
        drivers MUST instead select a server using a primary read preference.
      

      Defining it precisely in terms of available and eligible servers (the language of the server selection specification) would be more prescriptive and reduce differences in driver implementations. Something like this:

      If an explicit (i.e. per-operation) or default (i.e., specified on a collection object) 
      read preference is specified for an aggregation with a write stage, 
      drivers use this logic to determine the list of eligible servers to consider:
       
      If there are any *available* pre-5.0 servers, drivers MUST fall back to using primary 
      read preference to determine the list of *eligible* servers.  
      Otherwise, drivers MUST apply the read preference to determine the list of *eligible* servers.
      

      Examples (all with secondary read preference):

      1. a 5.0 primary and no secondaries -> apply read preference (no eligible servers)
      2. a 5.0 primary and a 5.0 secondary -> apply read preference (one eligible server)
      3. no available servers -> apply read preference (no eligible servers)
      4. a 4.4 primary and a 5.0 secondary -> fallback to primary (one eligible server)

      Attachments

        Issue Links

          Activity

            People

              jmikola@mongodb.com Jeremy Mikola
              jeff.yemin@mongodb.com Jeffrey Yemin
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: