-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
-
Sharding 2021-03-08, Sharding 2021-03-22
-
1
The RecipientStateMachine skips constructing a ReshardingTxnCloner for itself when the recipient shard is also a donor shard. The intention was to allow retryable writes started before the resharding operation to remain retryable during the resharding operation. However, this approach is insufficient because a recipient shard may write the kIncompleteHistoryStmtId entry due to the config.transactions entry of another donor shard that had also participated in the same retryable write.
void ReshardingRecipientService::RecipientStateMachine::_initTxnCloner( OperationContext* opCtx, const Timestamp& fetchTimestamp) { auto catalogCache = Grid::get(opCtx)->catalogCache(); auto routingInfo = catalogCache->getShardedCollectionRoutingInfo(opCtx, _recipientDoc.getNss()); std::set<ShardId> shardList; const auto myShardId = ShardingState::get(opCtx)->shardId(); routingInfo.getAllShardIds(&shardList); shardList.erase(myShardId); for (const auto& shard : shardList) { _txnCloners.push_back( std::make_unique<ReshardingTxnCloner>(ReshardingSourceId(_id, shard), fetchTimestamp)); } }
- is depended on by
-
SERVER-55683 Remove waiting for minimum duration from the resharding coordinator
- Closed
- is related to
-
SERVER-54626 Retryable writes may execute more than once in resharding if statements straddle the fetchTimestamp
- Closed
-
SERVER-52921 Integrate config.transactions cloner for resharding into RecipientStateMachine
- Closed
- related to
-
SERVER-55214 Resharding txn cloner can miss config.transactions entry when fetching
- Closed