[SERVER-17882] Update with key too large to index crashes WiredTiger/RockDB secondary Created: 02/Apr/15  Updated: 19/Sep/15  Resolved: 09/Apr/15

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Replication, WiredTiger
Affects Version/s: 3.0.0
Fix Version/s: 3.0.3, 3.1.2

Type: Bug Priority: Major - P3
Reporter: Michael Kania Assignee: Mathias Stearn
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Steps To Reproduce:

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}})

Sprint: Quint Iteration 3.1.2
Participants:

 Description   
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.



 Comments   
Comment by Githook User [ 16/Apr/15 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-17882 Expand failIndexKeyTooLong handling to updates

(cherry picked from commit 760b3e17afda69aa224b03bddbdcc0c256a60afc)
Branch: v3.0
https://github.com/mongodb/mongo/commit/788d9084fc1e43a2710e3054b2ffee1574b8a479

Comment by Daniel Pasette (Inactive) [ 14/Apr/15 ]

Backport was waiting for 3.0.2 to be released. Should be complete within the next week or so.

Comment by Michael Kania [ 13/Apr/15 ]

When will this be backported to 3.0?

Comment by Michael Kania [ 13/Apr/15 ]

This is the same patch we did internally(https://github.com/mongodb-partners/mongo/commit/8f5b3ce5c4611299248ad7e5749c658e126b90a1), and it appears to be working fine. Thanks for fixing it.

Comment by Githook User [ 09/Apr/15 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-17882 Expand failIndexKeyTooLong handling to updates
Branch: master
https://github.com/mongodb/mongo/commit/760b3e17afda69aa224b03bddbdcc0c256a60afc

Comment by Ramon Fernandez Marina [ 02/Apr/15 ]

Thanks for your report dynamike. I'm able to reproduce the behavior you describe using 2.6.9 and 3.0.1 and I'm investigating.

Cheers,
Ramón.

Generated at Thu Feb 08 03:45:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.