[SERVER-24397] Refactor and improve applyChunkOpsDeprecated Created: 03/Jun/16  Updated: 06/Dec/22  Resolved: 17/Dec/21

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

Type: Improvement Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt Dependency
has to be done after SERVER-22659 Implement commitChunkMigration comman... Closed
Assigned Teams:
Sharding
Participants:

 Description   

The CommitChunkMigration command will be calling the applyOps command. Its needs are not met by the current applyChunkOpsDeprecated, which expects a precondition and adds a majority write concern by default.

Two changes:
1) Refactor applyChunkOpsDeprecated so CommitChunkMigration can use it.
2) Swap this command failure check catalog_manager_replica_set.cpp#L1597-L1636 with the more robust check here migration_source_manager.cpp#L382-L451

The second change will make sure applyChunkOpsDeprecated refreshes to the latest optime before querying the config.chunks collection. This way it knows to wait for the applyOps writes, and won't potentially miss them if they haven't propagated to a secondary by the time of the query to check on them. Using refreshMetadataNow allows us to check that the metadata was updated by the absence of the old chunk metadata, rather than requiring us to know what the new chunk metadata is, which will be unknown for moveChunk, since the config server generates it via CommitChunkMigration command, and should give merge and split more flexibility for future changes as well.


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