It is possible for commands like _recvChunkStatus to be called prior to MigrationDestinationManager::start() having been called on that node. For example, there may be a primary failover on the recipient shard where the new primary of the recipient shard has never participated in a chunk migration and the primary of the donor shard runs _recvChunkStatus. The donor shard expects to learn the recipient shard has abandoned the chunk migration through the _recvChunkStatus response.
long long _getNumCloned() { return _migrationCloningProgress->getNumCloned(); } long long _getNumBytesCloned() { return _migrationCloningProgress->getNumBytes(); }
Returning 0 from MigrationDestinationManager::_getNumCloned() and MigrationDestinationManager::_getNumBytesCloned() will probably suffice.
- is caused by
-
SERVER-67183 Higher throughput Chunk Migration - reimplement for fetching and insertion
- Closed