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

logOp / OperationObserver should always check shardversion

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 2.6.10, 3.0.2, 3.1.1
    • Affects Version/s: 3.0.1
    • Component/s: Sharding
    • None
    • Fully Compatible
    • ALL
    • Sharding 2 04/24/15

      Proposed title: logOp / OperationObserver should always check shardversion

      Issue Status as of Apr 02, 2015

      ISSUE SUMMARY
      Sharded write operations that affect single documents (i.e. updates without the multi option, or remove operations with justOne=True), should always ensure that write operations are being applied directly to the correct shard to avoid loosing some write operations during chunk migration.

      USER IMPACT
      Could cause a limited set of operations that modified orphaned data to report success, inaccurately.

      In 3.0.0 and 3.0.1, if you encounter this issue using a command that writes data but is not insert, update, or delete, (e.g. findAndModify, mongod itself may may terminate on this issue.

      WORKAROUNDS
      None.

      AFFECTED VERSIONS
      2.6+ and 3.0+

      FIX VERSION
      The fix is included in the 3.0.2 production release.

      Original description

      If a shard's notion of its shard version for a collection changes after a single-document operation has established the operation's expected shard version for the collection on that shard, any call to logOp() by that operation should trigger a shard version error and rollback of the operation.

      Multi-document operations, such as multi:true updates and justOne: false deletes are inherently unversioned in the current protocol, and so shard version mismatches for those operations should not result in error propagation.

      – from original description –
      The shard needs to send a version error as a response when the shard version changed right after a non-multi update (the writes that failed to be included in the transfer mod phase of the migration).

            Assignee:
            randolph@mongodb.com Randolph Tan
            Reporter:
            randolph@mongodb.com Randolph Tan
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: