Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-11387

Docs for SERVER-32635: Provide a framework to ensure a last stable binary version mongos crashes when attempting to connect to a latest featureCompatibilityVersion sharded cluster for all last stable binary versions >= 3.8

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 3.7.3
    • None
    • None
    • None

    Description

      Documentation Request Summary:

      This ticket makes the mongos crash when it communicates with a server that has been upgrade both a binary and feature compatibility version higher than itself. So a mongos v4.0 talking to a v4.2 mongod with feature compatibility version 4.2 – a v4.2 mongod with FCV 4.0 will not cause a crash, to be clear.

      This kind of scenario can happen when a user forgets to upgrade the mongos binary and then calls setFCV(upgrade), leaving the still downgraded mongos unable to communicate. Rather than the mongos logging incompatible server version errors endlessly, we've chosen to crash it.

      Engineering Ticket Description:

      If a last-stable binary version mongos attempts to point to a latest featureCompatibilityVersion sharded cluster, the mongos will spin, repeatedly attempting to connect and failing with IncompatibleServerVersion errors. Instead, the mongos should crash in this scenario. This framework should be available for all last-stable binary versions >= 3.8. This implementation should not cause a latest binary version mongos to crash upon attempting to connect to a last stable binary version node.
      A proposed implementation for the framework follows:
      The validateWireVersion function in protocol.cpp can be modified to have a new error code that is returned when the client's maximum wireVersion is less than the server's minimum wireVersion. If the client is a mongos and it sees this error upon calling validateWireVersion, it will crash. The client can use the isMongos() function to determine whether it is a mongos.This low-level implementation is justifiable because a last-stable mongos should crash upon any attempts to connect to a latest featureCompatibilityVersion node in the cluster. This implementation assumes a mongos will only be a client to other members of the same sharded cluster and not to members of a different sharded cluster.

      Attachments

        Activity

          People

            kay.kim@mongodb.com Kay Kim (Inactive)
            kay.kim@mongodb.com Kay Kim (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:
              5 years, 32 weeks, 5 days ago