[SERVER-48365] Migration manager recovery should handle a refined shard key Created: 21/May/20  Updated: 29/Oct/23  Resolved: 21/Jul/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.4.1, 4.7.0

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Pierlauro Sciarelli
Resolution: Fixed Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4
Sprint: Sharding 2020-07-13, Sharding 2020-06-01, Sharding 2020-06-15, Sharding 2020-06-29, Sharding 2020-07-27
Participants:
Linked BF Score: 27

 Description   

As part restarting the balancer on step up, the migration manager reschedules migrations with entries in config.migrations, finding the moved chunk by searching the latest routing table for each migration's minimum boundary. After a shard key refine, this may lead to comparing boundaries with a different number of fields, which can lead to spurious overlap or failure to overlap, triggering incorrect recovery or an unhandled exception. Instead the bounds should be extended to account for the refined key.



 Comments   
Comment by Githook User [ 18/Aug/20 ]

Author:

{'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}

Message: SERVER-48365 Migration manager recovery should handle a refined shard key

(cherry picked from commit c25095e9a3b3bd3de3f56274ba023823ae83085b)
Branch: v4.4
https://github.com/mongodb/mongo/commit/b55e4c716bc0e23384751f942488fde28f65725b

Comment by Githook User [ 21/Jul/20 ]

Author:

{'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}

Message: SERVER-48365 Migration manager recovery should handle a refined shard key
Branch: master
https://github.com/mongodb/mongo/commit/c25095e9a3b3bd3de3f56274ba023823ae83085b

Generated at Thu Feb 08 05:16:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.