Passively handle parsing field "waiting" in config.mongos

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: 7.0.0-rc0
    • Component/s: None
    • None
    • Cluster Scalability
    • ALL
    • Hide

      Reproducing this involves getting a pre-2.4 config.mongos document. The hard way should be verified before closing this issue.

      The hard way (customer scenario):

      • Run a pre-2.4 version of mongod
      • Ensure config.mongos documents are written
      • Switch to a 7.0+ version of mongod and perform an initial-sync
      • Expect a failure with missing field "waiting"

      The easy way (mock documents):

      • Write dummy config.mongos documents missing the "waiting" field
      • Run a 7.0+ version of mongod and perform an initial-sync
      • Expect a failure with missing field "waiting"
      Show
      Reproducing this involves getting a pre-2.4 config.mongos document. The hard way should be verified before closing this issue. The hard way (customer scenario): Run a pre-2.4 version of mongod Ensure config.mongos documents are written Switch to a 7.0+ version of mongod and perform an initial-sync Expect a failure with missing field "waiting" The easy way (mock documents): Write dummy config.mongos documents missing the "waiting" field Run a 7.0+ version of mongod and perform an initial-sync Expect a failure with missing field "waiting"
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      From HELP-92917.

      Background

      The field waiting was added with version 2.4 of mongod (released 2013). If a customer is running a pre-2.4 version of mongod, then documents will likely exist without the waiting field.

      The customer in the linked HELP-92917 ticket sees an error doing a default initialSync when adding a new RS member. Their workaround was to do the file-based initialSync, which unblocked them and allowed them to add the RS member (although without compaction, which was desired by the customer).

      The issue is that this field is parsed as required in type_mongos.cpp#L83, and this causes a uassertStatusOK to be thrown, which crashes the server process with a std::terminate.

      Proposal

      This field should be parsed passively, as other customers who upgraded from pre-2.4 will likely run into this issue.

      The only class that writes this document is router_uptime_reporter.cpp#L114, and it is hard-coded to true with comment:

      // balancer is never active in the router. Here for backwards compatibility only.

      Therefore, if the field does not exist, we can simply return a default true value.

            Assignee:
            Nandini Bhartiya
            Reporter:
            Jordan Glassley
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: