[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: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Sharding 2019-07-01, Sharding 2019-07-15 | ||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| 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:
|
| Comments |
| Comment by Githook User [ 05/Jul/19 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |
| Comment by Githook User [ 03/Jul/19 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |
| 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:
|
| 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. |