[SERVER-54094] Avoid taking strong lock on collection as part of donor shards in resharding choosing minFetchTimestamp Created: 28/Jan/21  Updated: 06/Dec/22  Resolved: 12/Jun/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: [DO NOT USE] Backlog - Sharding NYC
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-54047 Resharding permits transactions to co... Closed
Assigned Teams:
Sharding NYC
Participants:
Story Points: 5

 Description   

Donor shards taking a collection S lock in generateMinFetchTimestamp() on the collection being resharded is a heavy-handed way to wait for all earlier writes on the collection to have finished. Despite the intention to only block writes, in the absense of lock-free reads, the collection S lock would lead to readers also being block. This is because a collection IX lock request which queues up after the S lock request will cause any subsequent collection IS lock requests to also queue.

Donor shards must guarantee after the minFetchTimestamp value that all oplog entries for writes on the collection being resharding contain a "destinedRecipient" field. An alternative approach would be (1) to wait for any prepared transactions to commit or abort and (2) to throw a WriteConflictException for any other write on the collection being resharded that started before the minFetchTimestamp value.


Generated at Thu Feb 08 05:32:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.