[SERVER-33890] Insertion into system.indexes on mongos causes 6 index builds on shard Created: 14/Mar/18 Updated: 29/Oct/23 Resolved: 16/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Matthew Saltz (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Steps To Reproduce: |
|
||||||||||||
| Sprint: | Sharding 2018-04-23 | ||||||||||||
| Participants: |
| Description |
|
Attempting to create an index on a sharded collection using insertion into system.indexes fails with the following error:
It forward the insertion to the shard six times. Each time the shard creates the index, but then uasserts due to an epoch mismatch on system.indexes and reverts the index build.
The shard does not end up with the index built. It seems acceptable for insertion into system.indexes to fail on mongos, but it would be better to not do index builds on the shard before failing. |
| Comments |
| Comment by Githook User [ 16/Apr/18 ] | ||||
|
Author: {'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com'}Message: | ||||
| Comment by Matthew Saltz (Inactive) [ 16/Apr/18 ] | ||||
|
Code review: https://mongodbcr.appspot.com/201170001/ | ||||
| Comment by Tess Avitabile (Inactive) [ 16/Apr/18 ] | ||||
|
Actually, before closing this ticket, we should unblacklist cannot_create_system_dot_indexes.js from sharded_causally_consistent_jscore_passthrough. This would also give use test coverage to ensure this does not regress. | ||||
| Comment by Tess Avitabile (Inactive) [ 16/Apr/18 ] | ||||
|
You are correct, this does not currently fail on master. It also does not fail on the 3.6 branch. It does fail on this commit, which was the state of the master branch when I filed the ticket. I think it is safe to close this as Gone Away, unless the Sharding team is interested in figuring out what caused or fixed this, or adding a test to ensure this does not regress. | ||||
| Comment by Matthew Saltz (Inactive) [ 13/Apr/18 ] | ||||
|
I'm observing the same behavior on master. The test passes for me. I just added it to the sharding directory and ran it with the sharding suite and it passed. tess.avitabile was there any extra setup involved with this? Maybe something has gotten fixed since this ticket was created? | ||||
| Comment by Kaloian Manassiev [ 13/Apr/18 ] | ||||
|
If it worked in 3.6 it should work in 4.0 as well. However I just tried to run the attached repro script and it passes for me. I do see 3 indexes being built, but the first two are for the config.cache.chunks collection:
Does this bug still exist at all? | ||||
| Comment by Matthew Saltz (Inactive) [ 12/Apr/18 ] | ||||
|
kaloian.manassiev Should we make this work or just explicitly disallow creating indexes on sharded collections this way? |