[SERVER-74566] Audit all uses of ShardRegistry configShard on config server to verify they are safe to use ShardRemote Created: 02/Mar/23 Updated: 29/Oct/23 Resolved: 27/Mar/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding NYC 2023-04-03 |
| Participants: |
| Description |
|
This project changed getting the config shard from the shard registry on the config server to return a ShardRemote instead of a ShardLocal. This means operations that were previously always process local, may now target other config server nodes. This could be problematic, e.g. if code relies on receiving a replication state change error after a failover, but now will retarget the new primary. We should audit visually and via invariants, etc. that all uses of ShardLocal before |
| Comments |
| Comment by Githook User [ 23/Mar/23 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Jack Mulrow [ 02/Mar/23 ] |
|
There's an invariant in ShardRemote that we always use readConcern majority for "exhaustive" finds on the config server that helped find places that relied on using a ShardLocal. We should think of other invariants / checks we can add to find other places, e.g. anything using local write concern probably expected to use a ShardLocal. |