-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Fully Compatible
-
Sharding NYC 2022-05-16, Sharding NYC 2022-05-30, Sharding NYC 2022-06-13, Sharding 2022-06-27, Sharding 2022-07-11
The section should cover the following:
- Non-retryable internal transactions
- Retryable internal transactions
- How retryablity works
- The “stmtId”, “preImageOpTime”, “postImageOpTime”, “needsRetryImage” fields in the inner oplog entries inside each applyOps oplog entry.
- How each retryable write statement generates only one operation entry with its stmtId; any other operation entries have stmtId=-1.
- How each internal session can only have one retryable findAndModify.
refreshFromStorageIfNeeded() and RetryableTransactionParticipantCatalog. - How concurrent retries are prevented (i.e. RetryableTransactionInProgress).
- Session migration during chunk migration and resharding
- Retryability contract.
- How retryable internal transaction oplog entries are converted to retryable write oplog entries.
- How retryablity works
- split from
-
SERVER-55346 Architecture Guide updates for Running distributed transactions internally in a sharded cluster
- Closed