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

Allow replica set secondary node to batch apply same-node document shard key changes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.1.11
    • Component/s: Replication, Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Sharding 2019-05-06

      Description

      Background:

      1. A primary node writes multiple same-node shard key updates.
      2. A second attempts to replicate, and is behind enough that it decides to batch apply instead of single apply.

      Issue:
      When the secondary attempts to apply each statement separately, it will see that the document shard key is changing, and will uassert because the opCtx is not in a transaction. It wouldn't be in a transaction, because the batch apply has no transaction associated with itself. This individual uassert leads to an fassert from the replication code.

      Fix:
      Add a check to !getOpCtx()->writesAreReplicated() in [this uassert here|https://github.com/mongodb/mongo/blob/406e1642a83d8b810bec41ad293c1b1c8a59a6dd/src/mongo/db/exec/update_stage.cpp#L929, so that we don't require the opCtx to have a transaction number if we are in a secondary node.

        Attachments

          Activity

            People

            Assignee:
            blake.oler Blake Oler
            Reporter:
            blake.oler Blake Oler
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: