[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 SERVER-71891 are safe to use ShardRemote.



 Comments   
Comment by Githook User [ 23/Mar/23 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-74566 Use ShardLocal in more places that may have relied on it
Branch: master
https://github.com/mongodb/mongo/commit/1439bd4fc4f6d98bf1d51ab8fe608f4ad2235bc8

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.

Generated at Thu Feb 08 06:27:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.