[SERVER-30375] make renameCollection attach databaseVersion and shardVersion=UNSHARDED Created: 27/Jul/17 Updated: 30/Oct/23 Resolved: 21/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.5.10 |
| Fix Version/s: | 3.7.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Kaloian Manassiev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Sharding 2017-08-21, Sharding 2017-09-11, Sharding 2017-10-02, Sharding 2017-10-23, Sharding 2018-03-26 |
| Participants: |
| Description |
|
renameCollection is not supposed to be allowed to run on sharded collections. However, today shardCollection and renameCollection can run concurrently, and therefore race. So, we can end up in a situation where the UUID in a config.collections entry (propagated from the primary shard through shardCollection) differs from the UUID on the primary shard (after renameCollection). In this case, it is as if the collection has been dropped and recreated as unsharded, but the entry for the old sharded collection doesn't get deleted from config.collections. |
| Comments |
| Comment by Githook User [ 22/Mar/18 ] |
|
Author: {'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 21/Mar/18 ] |
|
Author: {'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}Message: |
| Comment by Esha Maharishi (Inactive) [ 08/Mar/18 ] |
|
Assigning to kaloian.manassiev under the "Introduce Database Versioning" project, to make renameCollection attach both shardVersion and databaseVersion. |
| Comment by Esha Maharishi (Inactive) [ 16/Aug/17 ] |
|
Another way to do this might just be to make renameCollection versioned (i.e., attach ChunkVersion::UNSHARDED()). |
| Comment by Esha Maharishi (Inactive) [ 27/Jul/17 ] |
|
Marked as "Needs Triage" because it's more Collection Lifecycle-y, and doesn't cause UUID corruption so much as an unreachable collection. |
| Comment by Esha Maharishi (Inactive) [ 27/Jul/17 ] |
|
Also consider making renameCollection take the same distlock as movePrimary, since otherwise: 1) if user thought both db's were on the same shard, but movePrimary has been called on another mongos: this mongos will accept the rename and send it to the primary shard of the source db. 2) if the user thought both db's were on separate shards, but movePrimary has been called on this mongos: the rename will succeed, perhaps against the user's expectation |
| Comment by Esha Maharishi (Inactive) [ 27/Jul/17 ] |
|
Marked as "minor" backwards-breaking change, since it will mean renameCollection and shardCollection cannot run concurrently. |