The current iteration of chunk migration was built with the assumption that cloning can happen in parallel with prepared transactions on the collection, however this is not what happens in practice.
As part of default command behavior, the moveChunk command will block on reads for documents that are in the prepare state. If any documents in the initial index scan are in prepared transactions, the index scan will block on the completion of those transactions to read these documents.
This means that the beginning of the chunk migration clone phase will infinitely block in the presence of transactions that:
- Have documents that exist in the chunk being migrated, and
- Are already in the prepare state before the chunk cloner started.
This ticket is to evaluate if this behavior is acceptable, and if not, figure out a way around this behavior. If we decide to allow the moveChunk command to ignore prepare conflicts, then we will need additional machinery to track these prepared transactions.
- is related to
-
SERVER-71028 MigrationChunkClonerSourceLegacy::nextCloneBatch should ignore prepare conflict
-
- Backlog
-
- related to
-
SERVER-68361 LogTransactionOperationsForShardingHandler::commit misses transferring documents from prepared and non-prepared transactions changing a document's shard key value
-
- Closed
-
-
-
- Closed
-
-
SERVER-78415 Avoid sending unrelated operations from transactions to recipient shard during chunk migration
-
- Backlog
-