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

Update with key too large to index crashes WiredTiger/RockDB secondary

XMLWordPrintableJSON

    • Fully Compatible
    • ALL
    • Hide

      Initiate a replicaset with a 2.6 primary and a 3.0 WT secondary.

      //generate 2048 chars string
var s="a"; for (i=0;i<11;i++) s+=s; print(s.length);

//build index
db.foo.ensureIndex({"doober": 1})

//insert 
db.foo.insert({_id: "hi", "doober": "doo"})

//enable write failure on long index on PRIMARY and SECONDARY
db.getSiblingDB('admin').runCommand( { setParameter: 1, failIndexKeyTooLong: true } )

//expect update failure
db.foo.update({_id: "hi" }, { $set: {"doober": s}})

//disable write failure on long index on PRIMARY and SECONDARY
db.getSiblingDB('admin').runCommand( { setParameter: 1, failIndexKeyTooLong: false } )

//crash secondary
db.foo.update({_id: "hi" }, { $set: {"doober": s}})
      Show
      Initiate a replicaset with a 2.6 primary and a 3.0 WT secondary. //generate 2048 chars string var s= "a" ; for (i=0;i<11;i++) s+=s; print(s.length); //build index db.foo.ensureIndex({ "doober" : 1}) //insert db.foo.insert({_id: "hi" , "doober" : "doo" }) //enable write failure on long index on PRIMARY and SECONDARY db.getSiblingDB( 'admin' ).runCommand( { setParameter: 1, failIndexKeyTooLong: true } ) //expect update failure db.foo.update({_id: "hi" }, { $set: { "doober" : s}}) //disable write failure on long index on PRIMARY and SECONDARY db.getSiblingDB( 'admin' ).runCommand( { setParameter: 1, failIndexKeyTooLong: false } ) //crash secondary db.foo.update({_id: "hi" }, { $set: { "doober" : s}})
    • Quint Iteration 3.1.2

      Issue Status as of Apr 29, 2015

      ISSUE SUMMARY
      MongoDB 3.0 secondaries running non-MMAPv1 storage engines (i.e.: WiredTiger, RocksDB) may fail to properly handle updates involving keys longer than 1024 bytes if the key is indexed.

      Setting failIndexKeyTooLong to false has no effect.

      USER IMPACT
      A secondary receiving an update involving a key longer than 1024 terminates if there's an index on that key. If enough secondaries are affected the replica set may become unavailable.

      WORKAROUNDS
      It is highly recommended that users do not use keys longer than 1024. When upgrading from 2.6, please upgrade directly to version 3.0.3 or higher.

      AFFECTED VERSIONS
      MongoDB versions 3.0.0, 3.0.1, and 3.0.2 are affected by this issue.

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

      Original description

      If you have a 2.6 PRIMARY and a WT or RocksDB SECONDARY, you can crash the SECONDARY by updating an indexed key with > 1024 characters.

            Assignee:
            mathias@mongodb.com Mathias Stearn
            Reporter:
            dynamike Michael Kania
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: