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

Direct read/write retries to another mongos if possible

    XMLWordPrintableJSON

Details

    • Epic
    • Status: Designing
    • Major - P3
    • Resolution: Unresolved
    • None
    • Server Selection
    • None
    • Not Needed
    • Hide

      Details TBD

      Show
      Details TBD
    • 0
    • 0
    • 0
    • 100
    • Hide

      Engineer: Dmitry Rybakov
      Summary: When encountering a retryable error, direct the retry attempt to a different mongos if possible.

      2023-05-12

      • Design work started
      • Decided against adapting unified test format to accommodate special test needs for this project due to implementation complexity involved
      Show
      Engineer: Dmitry Rybakov Summary: When encountering a retryable error, direct the retry attempt to a different mongos if possible. 2023-05-12 Design work started Decided against adapting unified test format to accommodate special test needs for this project due to implementation complexity involved

    Description

      There are several scenarios in which it would be useful to redirect reads or writes to a different mongos.

      1. A MongoDB sharded cluster deployment may find itself in a situation when a mongos reports itself as being healthy but is unable to execute any queries. The driver has attempted to retry the failing queries, but in a number of cases selected the same mongos that failed in the first place which caused the retry to also fail (for the same reason as the original attempt) and be propagated to the application.
      2. Currently when the driver is in sharded topology, server selection spec requires a random server to be selected for each operation. This permits the same failed mongos to be selected for both an operation and its retry, with the result that the query fails, even when there are healthy mongoses in the deployment that could have successfully executed the query.

      The suggested improvement is for the driver, when in sharded cluster topology, to:

      • Track whether a server selection request is for the first attempt or for a retry,
      • Track the server used for the first attempt,
      • When selecting the server for the retry, if there are multiple eligible mongoses, select randomly from mongoses other than the one used for the first attempt.
      • bonus nice to have: determine if a mongos is healthy before making said attempt and if unhealthy, exclude from selection

      Attachments

        Issue Links

          Activity

            People

              dmitry.rybakov@mongodb.com Dmitry Rybakov
              oleg.pudeyev@mongodb.com Oleg Pudeyev (Inactive)
              Jeffrey Yemin Jeffrey Yemin
              Rachelle Palmer Rachelle Palmer
              Tom Selander Tom Selander
              Votes:
              6 Vote for this issue
              Watchers:
              27 Start watching this issue

              Dates

                Created:
                Updated: