[SERVER-41683] The `movePrimary` collection cloner should not be checking for collection options match Created: 13/Jun/19  Updated: 29/Oct/23  Resolved: 03/Jul/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.13, 4.0.10, 4.2.0-rc1
Fix Version/s: 4.3.1

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Janna Golden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2019-07-01, Sharding 2019-07-15
Participants:
Case:
Linked BF Score: 27

 Description   

Cloning collections as part of movePrimary currently checks that the collection options match between the source and the destination shards. This comparison is not fully correct, because it is possible that the two nodes might have different storage engines and/or options for the storage engines.

Instead of binary-comparing the entire options object, the cloner should instead just check for UUID match.

This will effectively be the "algorithm" of the cloner.

For each collection from the source:

  1. If collection doesn't exist on the destination, then create and clone it
  2. If the collection exists on the destination and:
    1. Is sharded on the source, then fail the clone
    2. Is not sharded on the source, then just compare the UUIDs and if they don't match, fail the clone


 Comments   
Comment by Githook User [ 05/Jul/19 ]

Author:

{'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}

Message: SERVER-41683 Blacklist move_primary_clone_test.js from last stable suite
Branch: master
https://github.com/mongodb/mongo/commit/726813dc00dd0fa8f9abc575745229ec2b69830e

Comment by Githook User [ 03/Jul/19 ]

Author:

{'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}

Message: SERVER-41683 Only check UUID in movePrimary collection cloner
Branch: master
https://github.com/mongodb/mongo/commit/7584ab9b19d154146925f6b5e57d364e80dd8fb6

Comment by Esha Maharishi (Inactive) [ 13/Jun/19 ]

kaloian.manassiev, sounds good to me, after I spoke to Eric I was also thinking we could keep just the UUID check.

However, steps 2.1 and 2.2 in the ticket description seem backwards to me, did you mean:

2. If the collection exists on the destination and:

      1. Is sharded not sharded on the source, then fail the clone // the collection on the destination is a garbage collection. in 4.0, we had discussed making movePrimary just drop it, but decided to instead fail the movePrimary and let the user decide what to do.

      2. Is not sharded sharded on the source, then just compare the UUIDs and if they don't match, fail the clone // it's normal for a sharded collection to be on the destination, since the destination might own chunks

Comment by Kaloian Manassiev [ 13/Jun/19 ]

esha.maharishi, I know you and milkie discussed that we should completely remove the checks in step 2.2 above and I think this is fine, because nothing depends on UUIDs for unsharded collections, but also I am thinking that a UUID mismatch means that there is some leftover older instantiation of a collection and that it is good to bring that information forward to the operator.

And in general the UUID uniquely identifies a collection in a cluster, so it would be good to preserve it.

Let me know what you think.

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