[SERVER-59023] Resharding can fail with NamespaceNotSharded following a primary failover on a recipient shard Created: 02/Aug/21 Updated: 29/Oct/23 Resolved: 30/Aug/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 5.0.0 |
| Fix Version/s: | 5.0.4, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Max Hirschhorn |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-234-M3, PM-234-T-oplog-apply | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v5.0
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Sharding 2021-08-09, Sharding 2021-08-23 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Story Points: | 2 | ||||||||||||||||||||||||||||||||||||
| Description |
|
A secondary which steps up to be primary won't necessarily have loaded the collection metadata for temporary resharding collection. This can lead assertCanExtractShardKeyFromDocs() to throw a NamespaceNotSharded exception when the ReshardingOplogApplier attempts to write to the temporary resharding collection. The ReshardingCollectionCloner and ReshardingOplogApplier rely on assertCanExtractShardKeyFromDocs() to ensure an update doesn't write an invalid shard key value (e.g. an array value) under the new shard key pattern. We must either
|
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 21/Sep/21 ] |
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Adds a retry once on StaleConfig exception helper to enable the (cherry picked from commit 7cfe35e4384af3c25aef161ab4c8133c50474395) |
| Comment by Githook User [ 30/Aug/21 ] |
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Adds a retry once on StaleConfig exception helper to enable the |
| Comment by Max Hirschhorn [ 09/Aug/21 ] |
|
I discussed this ticket with Kal and Tommaso. Kal didn't want to introduce a new, named error code and pointed out that IGNORED is sufficient for ensuring the collection metadata is known by the shard. The plan is to do the following:
|