-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
Sharding NYC 2022-03-21
For a retryable findAndModify statement that executes during a chunk migration, retryability is handled as follows.
- If the findAndModify is executed with enableFindAndModifyImageCollection=false, prior to adding the opTime for the write to the transfer mods session migration queue, the MigrationChunkClonerSourceLegacy explicitly adds the pre/post image opTime to the queue. This enables the _fetchNextNewWriteOplog() to return the pre/post image oplog entry immediately before the oplog entry for the write without an additional pre/post image oplog fetching logic.
- If the findAndModify is executed with enableFindAndModifyImageCollection=true, _fetchNextNewWriteOplog() is responsible for forging a pre/post image oplog entry upon seeing the oplog entry for the write (contains the "needsRetryImage" field).
For a retryable findAndModify statement that executes prior to a chunk migration, retryablity is handled quite differently in that _fetchNextOplogFromSessionCatalog() is responsible for both fetching and forging the pre/post image oplog entry for the write.
While this setup in _fetchNextNewWriteOplog() works for a regular retryable findAndModify, it will not work for a retryable findAndModify executed inside an internal transaction. Upon prepare or unprepared commit, the MigrationChunkClonerSourceLegacy could add the pre/post image opTime that it sees to session migration before adding the prepare or commit opTime to queue, however there is not a way for way to specify which statement the pre/post image opTime corresponds to. Since the SessionCatalogMigrationSource needs to traverse the transaction oplog chain anyway (in SERVER-63494), it is simpler for it to fetch the pre/post image oplog entry in _fetchNextNewWriteOplog() just like it does in _fetchNextOplogFromSessionCatalog(). Therefore, to avoid having separate logic for handling retryable findAndModify that executes inside and outside a transaction, we should do the following:
- Make the MigrationChunkClonerSourceLegacy not add pre/post image opTime to the session migration queue
- Make _fetchNextNewWriteOplog() use fetchPrePostImageOplog() to fetch or forge pre/post image oplog entry for each new write oplog entry here (i.e. remove this duplicated block of code), just like what _fetchNextOplogFromSessionCatalog() does.
- is depended on by
-
SERVER-63494 Transfer history for retryable transactions with more than one oplog entry across migrations
- Closed