[SERVER-22970] Background index build produces an index with mismatched index keys and documents Created: 04/Mar/16 Updated: 20/May/19 Resolved: 21/Apr/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Storage |
| Affects Version/s: | 3.0.11, 3.2.5, 3.3.4 |
| Fix Version/s: | 3.0.12, 3.2.6, 3.3.5 |
| Type: | Bug | Priority: | Blocker - P1 |
| Reporter: | Robert Guo (Inactive) | Assignee: | Kyle Suarez |
| Resolution: | Done | Votes: | 0 |
| Labels: | code-only, fuzzer-blocker | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Backport Completed: | |||||||||||||||||||||||||||||
| Steps To Reproduce: | This bug appeared a few times when running jstests/noPassthroughWithMongod/index_multi.js on a standalone mongod with WiredTiger. |
||||||||||||||||||||||||||||
| Sprint: | Integration 12 (04/04/16), Integration 13 (04/22/16) | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||
| Description |
|
Issue Status as of May 4, 2016 ISSUE SUMMARY This bug may affect background-built index builds only, and only in combination with update operations. USER IMPACT
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 AFFECTED VERSIONS
FIX VERSION After upgrading to one of these versions, all background-built indexes need to be rebuilt to avoid this issue. Original descriptionAfter doing a background index build, it's possible for there to be more index keys than documents in a compound, non-multikey index.
This is caused by multiple index entries pointing to the same document.
Index spec:
Here is a summary of affected versions and storage engines (where "yes" means we have been able to reproduce the index corruption):
|
| Comments |
| Comment by Ramon Fernandez Marina [ 07/Jun/16 ] |
|
vtomasr5, yes, a full initial sync of a node in a replica set will rebuild all indexes on that node and address the issue described in this ticket. Note that you'll need to resync all 15 nodes (5 shards x 3 rs/shard) to rebuild the background indexes in all nodes. You may also want to consider this other procedure to rebuild your indexes if your oplog is big enough. For additional support-related discussion please post on the mongodb-user group. See also our Technical Support page for additional support resources. Thanks, |
| Comment by Vicenç Juan Tomàs [ 07/Jun/16 ] |
|
Hi, We are running a big sharded cluster with 5 shards (3 nodes each rs) and we have a large number of background indexes created. We've updated to 3.0.12 and we've been thinking to rebuild the indexes due to this bug one by one. The size of the majority of the collections makes impossible to rebuild the indexes without affecting the business. We know that a full data re-sync its doable and it regenerates all the indexes. My question is: Will a full resync fix the indexes created in background mode? Thanks! |
| Comment by Kyle Suarez [ 29/Apr/16 ] |
|
Author: {u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'ksuarz@gmail.com'}Message: |
| Comment by Githook User [ 21/Apr/16 ] |
|
Author: {u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'ksuarz@gmail.com'}Message: There are two distinct fixes that must be done together:
|
| Comment by Githook User [ 21/Apr/16 ] |
|
Author: {u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'ksuarz@gmail.com'}Message: There are two distinct fixes that must be done together:
|
| Comment by Eric Milkie [ 13/Apr/16 ] |
|
I would file a separate ticket just for that task, so we don't forget. |
| Comment by Robert Guo (Inactive) [ 13/Apr/16 ] |
|
jstests/noPassthroughWithMongod/index_multi.js will be disabled after |