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

(v3.2) applyChunkOpsDeprecated should do a write before trying to confirm the migration commit (applyOps) succeeded despite errors

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Sharding
    • None
    • Fully Compatible
    • ALL
    • Sharding 2017-05-08, Sharding 2017-05-29

    Description

      BF-5149 (v3.2 failure) is an fassert in the migration critical section, where the shard cannot tell whether the commit was successful or not. This is because it tries to check whether the applyOps succeeded or not by doing a followup query. However, this query can be sent to secondaries, and the shard does not always have the latest config opTime to make sure what is seen on the secondary is the latest information.

      v3.4 changes the behavior by trying to do a successful write to the config primary, so as the acquire the latest config opTime, before sending the query that can target secondaries. We could add the same thing to v3.2.

      This solution doesn't cover all edge cases. For v3.6, we intend to do SERVER-26886 to eliminate the fassert potential, but we don't currently have any intentions for backport of such a fix.

      Attachments

        Activity

          People

            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: