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

v3.2 no-op applyOps doesn't wait for majority writeConcern before returning.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.2.9
    • Fix Version/s: 3.2.14
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Sharding 2017-05-29, Sharding 2017-06-19
    • Linked BF Score:
      0

      Description

      SERVER-24630 was introduced in v3.2.9 and made mongos/shard servers store the committed optime returned from commands to the config server, rather than the last seen optime.

      In the v3.2 shard applyOps command code we aren't properly waiting for majority write concern on no-ops / failures. This scope guard was wrapped around running applyOps on the server so that we would always update the last seen optime, regardless of applyOps results (SERVER-22933). But in v3.2, the waitForWriteConcern is done here in the same scope before the scope guard can fire. This wasn't a problem in v3.4 because the waitForWriteConcern code happened to get moved out of scope, so the scope guard is working correctly. The backport to v3.2, however, was not correct.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: