[SERVER-73564] Handle ShardingStateRecovery for catalog shard Created: 02/Feb/23  Updated: 29/Oct/23  Resolved: 08/Feb/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

Issue Links:
Related
related to SERVER-60110 Get rid of ShardingStateRecovery once... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding NYC 2023-02-06, Sharding NYC 2023-02-20
Participants:

 Description   

ShardingStateRecovery will perform a majority write on the config server during shard stepup if a chunk migration or movePrimary was in progress on the previous primary to advance configTime. If this runs on a config server acting as a shard, the write will hang. In 7.0 binaries, the vector clock is used to provide the same guarantees as ShardingStateRecovery, so the majority write is unnecessary for a shard config server, since a config server can only act as a shard in FCV 7.0 and higher. Thus we can avoid the hang by skipping the write on a config server.



 Comments   
Comment by Githook User [ 08/Feb/23 ]

Author:

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

Message: SERVER-73564 Skip ShardingStateRecovery logging write on a config server shard
Branch: master
https://github.com/mongodb/mongo/commit/db91fd2530ba2c41fc0900d6a86004e56a2f0ccf

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