-
Type:
Bug
-
Resolution: Done
-
Priority:
Blocker - P1
-
Affects Version/s: 3.0.11, 3.2.5, 3.3.4
-
Component/s: Index Maintenance, Storage
-
Labels:
ISSUE SUMMARY
While a background index build is in progress, document updates modifying fields contained in the the index specification may, under specific circumstances, cause mismatched index entries to appear.
This bug may affect background-built index builds only, and only in combination with update operations.
USER IMPACT
This bug may affect the behavior of queries that use an affected index, which may return incorrect results. Symptoms that indicate a background-built index is affected by this bug include:
- find() queries covered by the index may:
- return documents that don't match the query predicate
- display documents that no longer exist in the collection
- display more than one document with the same _id field
- count() commands may return incorrect counts
- remove() commands may remove documents that don't match the query predicate
Operations that do not use affected indexes are not impacted by this bug.
Note that collection data consistency is unaffected by this bug, only index entries may be affected.
WORKAROUNDS
There are no workarounds for this issue. While not all deployments using background-built indexes will be impacted, all users running the affected configurations should upgrade to a version containing the fix and rebuild all background-built indexes to make sure they're not impacted by this bug.
AFFECTED VERSIONS
- MongoDB 3.0 with the WiredTiger storage engine
While a background index build is in progress, any document updates modifying fields contained in the the index specification that happen at the same time as the background index build is reading those same documents will result in mismatched index entries. Technical details about this but can be found inSERVER-22970andSERVER-23807.
- MongoDB 3.2 with MMAPv1 and WiredTiger storage engines
While a background index build on a set of fields is in progress, any document updates modifying fields contained in the index specification may result in mismatched index entries if the background index build has already processed the documents to be updated, or if such documents are being processed by the index build at the same time. Technical details about this bug can be found inSERVER-22970,SERVER-23807andSERVER-23655.
FIX VERSION
The fix is included in the 3.2.6 production release. A fix for MongoDB 3.0 for users of the WiredTiger engine is included in the 3.0.12 production release.
After upgrading to one of these versions, all background-built indexes need to be rebuilt to avoid this issue.
Original description
After doing a background index build, it's possible for there to be more index keys than documents in a compound, non-multikey index.
> db.index_multi.find().count()
10000
> db.index_multi.find().hint("field52_1_field53_1").count()
10001
This is caused by multiple index entries pointing to the same document.
> db.index_multi.find({_id: 5468}, {_id:1}).showRecordId()
{ "_id" : 5468, "$recordId" : NumberLong(5469) }
> db.index_multi.find({_id: 5468}, {_id:1}).hint("field52_1_field53_1").showRecordId()
{ "_id" : 5468, "$recordId" : NumberLong(5469) }
{ "_id" : 5468, "$recordId" : NumberLong(5469) }
Index spec:
{
"v" : 1,
"key" : {
"field52" : 1,
"field53" : 1
},
"name" : "field52_1_field53_1",
"ns" : "test.index_multi",
"background" : true
}
Here is a summary of affected versions and storage engines (where "yes" means we have been able to reproduce the index corruption):
| version | MMAPv1 | WiredTiger |
|---|---|---|
| 2.6.12 | No | - |
| 3.0.11 | No | Yes |
| 3.2.5 | Yes | Yes |
| 3.3.4 | Yes | Yes |
- depends on
-
SERVER-23655 CollectionInfoCache is not invalidated when starting an index build
-
- Closed
-
-
-
- Closed
-
- is depended on by
-
-
- Closed
-
- is related to
-
-
- Closed
-