[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:
Backports
Related
is related to SERVER-31910 blacklist mongos_validates_writes.js ... Closed
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:

  • a movePrimary failed after updating the sharding catalog but before dropping the collection from the old primary
  • orphaned chunks from the previous collection still exist
  • a user manually created the collection directly on the shard


 Comments   
Comment by Githook User [ 21/Nov/17 ]

Author:

{'name': 'Esha Maharishi', 'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com'}

Message: SERVER-31909 Recipient shard should fail migration if it already has the collection with a different UUID

(cherry picked from commit 545c11242d737bf1a8ec19c2f2d7a7f14cc08f46)
Branch: v3.6
https://github.com/mongodb/mongo/commit/db79fdfb42475212dcc902a00420bf693b980d17

Comment by Githook User [ 21/Nov/17 ]

Author:

{'name': 'Esha Maharishi', 'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com'}

Message: SERVER-31909 Recipient shard should fail migration if it already has the collection with a different UUID
Branch: master
https://github.com/mongodb/mongo/commit/545c11242d737bf1a8ec19c2f2d7a7f14cc08f46

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?

Generated at Thu Feb 08 04:28:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.