-
Type: Improvement
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
None
-
Sharding NYC
-
5
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.
- is related to
-
SERVER-54047 Resharding permits transactions to commit after minFetchTimestamp without having destined recipient filled in
- Closed