Resharding catch-up critical section and commit boundary
Parent: Shard Key Design and Resharding as Cost Levers · Published reference · snapshot 2026-10-29
↓ Facts as markdownall context files
Source-anchored research for Resharding catch-up critical section and commit boundary. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Write blocking and commit are separate gates: the coordinator first blocks incoming writes and waits for recipients to contain all changes. A recipient in strict-consistency has those changes in its temporary collection; the coordinator commits after all required shards reach consistency. (medium confidence) [source]
How it works
- commitReshardCollection can trigger write blocking earlier than the automatic remaining-time threshold. It trades a potentially longer application write wait for earlier completion; issuing it does not mean the data cutover has already finished. (medium confidence) [source]
- Donor majority replication lag can consume the critical-section timeout during shard-version refresh and configTime persistence, leaving too little time for recipient oplog catch-up. SERVER-104303 documents this mechanism; commit-monitor source includes donor and recipient replication lag in its estimate when the corresponding controls are enabled. (medium confidence) [source]
- The inspected commit-monitor source treats missing recipient remaining-time metrics as an unbounded estimate, because a recipient may have failed over before restoring its metrics; it does not infer that entering the critical section is safe. (low confidence) (verified as of 2026-10-27) [source]
Measurements and reference values
- MongoDB documents a 500 ms remaining-work estimate threshold starting in 8.2, also available in 8.1.2 and 8.0.13. This is a trigger for entering the critical section, not a measured maximum write-block duration. (medium confidence) (verified as of 2026-10-14) [source]
Problems, failure modes and limitations
- The coordinator waits for all shards to reach strict consistency before committing, instructs shard primaries to rename the temporary collection, and has donors drop the old collection. abortReshardCollection cannot end the operation once it reaches the commit phase. (low confidence) [source]
- The documented operator cancellation boundary is the commit phase: abortReshardCollection returns an error after that phase has been reached. Do not assume that an abort remains available throughout cutover. (medium confidence) [source]
- SERVER-104303 documents why donor majority-replication lag can consume the critical-section timeout: shard-version refresh and configTime persistence involved majority waits before donors could enter blocking. The upstream commit monitor contains corresponding donor-lag accounting. This is a documented failure mechanism, not evidence that every modern release remains affected. (medium confidence) (verified as of 2026-10-27) [source]
Comparisons and alternatives
- Resharding metrics include totalCriticalSectionTimeElapsedSecs for elapsed critical-section time and donorState for the donor state. The currentOp command documentation recommends the $currentOp aggregation stage instead of the deprecated command. (low confidence) (verified as of 2026-10-14) [source]
- GenexDBS recommends scheduling resharding during relatively low workload, monitoring replication lag and resource pressure, and checking application tolerance for the write-blocking period; this is operational advice rather than a measured cutover latency guarantee. (low confidence) [source]
Facts and statements
- Recipients apply donor oplog changes written after cloning; write blocking allows the remaining catch-up work to finish before cutover. (medium confidence) [source]
- Recipients apply donor oplog changes made after cloning; source writes can continue before cutover blocking. Percona's MongoDB 5.0 experiment independently demonstrated a successful insert while resharding was running. (medium confidence) [source]
- In the inspected upstream master commit monitor, remaining-time estimation accounts for donor majority-replication lag before write blocking and recipient majority-replication lag before strict consistency, unless explicitly disabled. A missing recipient estimate prevents the monitor from concluding that critical-section entry is safe. (low confidence) (verified as of 2026-10-27) [source]
- Monitor phase state and critical-section elapsed time alongside remaining-time estimates. MongoDB documents donor/coordinator blocking-writes states and recipient strict-consistency; Percona's historical test shows that elapsed and estimated remaining time are separate observations. (medium confidence) [source]
- The inspected upstream master coordinator waits for strict consistency before its commit sequence. After calling _commit, its post-commit sequence waits for majority durability before telling participants to commit. This code ordering distinguishes the coordinator's durable decision from subsequent participant completion; it does not establish a bound on cutover latency. (low confidence) (verified as of 2026-10-27) [source]
- GenexDBS recommends monitoring replication lag, resource pressure, and application tolerance for the final write interruption during resharding. Treat this as practitioner planning advice; its approximate two-second wording is not a measured latency bound or a version-specific guarantee. (low confidence) (verified as of 2026-08-04) [source]
Children
- Resharding strict-consistency readiness (frontier)
- Resharding critical-section latency estimation (frontier)
- Resharding abort and commit recovery (frontier)
Frontier under this node: Resharding abort and commit recovery, Resharding critical-section latency estimation, Resharding strict-consistency readiness