[SERVER-31909] Recipient shard should fail migration if it already has the collection with a different UUID Created: 10/Nov/17 Updated: 30/Oct/23 Resolved: 21/Nov/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.0-rc3 |
| Fix Version/s: | 3.6.0-rc5, 3.7.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||
| Sprint: | Sharding 2017-11-13, Sharding 2017-12-04 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 0 | ||||||||||||
| Description |
|
If a recipient shard has an entry for the collection, it does not ask the donor for the UUID. So, it can accept a chunk from a different incarnation of the collection, resulting in a UUID inconsistency between the sharding catalog and the collection on the recipient shard. This garbage state from a previous incarnation of a collection can exist on a recipient for a variety of reasons, such as:
|
| Comments |
| Comment by Githook User [ 21/Nov/17 ] |
|
Author: {'name': 'Esha Maharishi', 'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com'}Message: (cherry picked from commit 545c11242d737bf1a8ec19c2f2d7a7f14cc08f46) |
| Comment by Githook User [ 21/Nov/17 ] |
|
Author: {'name': 'Esha Maharishi', 'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com'}Message: |
| Comment by Andy Schwerin [ 11/Nov/17 ] |
|
Users shouldn't manually create collections on the individual shards. If they did that in 3.4, and the names collided, they'd just end up with data corruption as data from the"local" version of the collection that overlapped the owned chunks of the sharded collection got overwritten. |
| Comment by Esha Maharishi (Inactive) [ 10/Nov/17 ] |
|
schwerin, do we want to do that, rather than fail migrations to that shard, log warnings, and make the user manually clean up? I say this mainly for the last case I described, "a user manually created the collection directly on the shard." Do we want to automatically wipe out their data, or let them figure out what to do? |
| Comment by Andy Schwerin [ 10/Nov/17 ] |
|
Shouldn't the recipient shard destroy the old version of the collection in its possession, rather than fail the migration? |