[SERVER-39935] _getNextSessionMods shouldn't transfer oplog entries for transaction commits during cloning Created: 01/Mar/19  Updated: 29/Oct/23  Resolved: 20/Mar/19

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

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Blake Oler
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2019-03-11, Sharding 2019-03-25
Participants:
Linked BF Score: 15

 Description   

During the cloning phase of a migration, in addition to transferring CRUD ops, the donor shard transfers the oplog entries associated with new retryable writes to the recipient shard, so the writes can still be retried if the migration succeeds. This is done by adding the opTimes of retryable write oplog entries to the donor shard cloner's SessionCatalogMigrationSource in WriteUnitOfWork commit handlers registered in insert/update/delete op observers and returning the entries associated with those times when the recipient shard calls _getNextSessionMods on the donor.

When transactions are committed, a commit transaction op observer fires that runs the CRUD op observers for each write in the transaction. Currently these CRUD observers are run with the opTime of the commit oplog entry and will add this opTime to the migration cloner's SessionCatalogMigrationSource, if it exists, leading _getNextSessionMods to transfer the commit oplog entry to the recipient shard.

This can lead to migration failures when the recipient checks out the TransactionParticipant associated with the commit, because the migrating thread assumes the txnId is for a retryable write and will throw InvalidOptions if the recipient was involved in the transaction and its TransactionParticipant isn't in the expected state for a retryable write (i.e. kNone).

Only the oplog entries for retryable writes need to be transferred, so this can be fixed by never passing an opTime from a transaction statement to the SessionCatalogMigrationSource in MigrationChunkClonerSourceLegacy.



 Comments   
Comment by Githook User [ 20/Mar/19 ]

Author:

{'email': 'blake.oler@mongodb.com', 'name': 'Blake Oler', 'username': 'BlakeIsBlake'}

Message: SERVER-39935 Don't pass in optime when migrating transaction statements
Branch: master
https://github.com/mongodb/mongo/commit/38c94f316b167e4b54b54ba8d12dbec33c7c5165

Generated at Thu Feb 08 04:53:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.