-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
ALL
-
CAR Team 2026-05-11
-
None
-
None
-
None
-
None
-
None
-
None
-
None
clearJumboFlag bumps the collection placement version every time it clears the flag, even though the bump serves no purpose: the only consumer of the jumbo field is the configsvr-side balancer, and the balancer's in-memory routing entry could be updated directly (the matching markAsJumbo path already does this).
Additionally, if shards become authoritative, any operation that bumps the shard version needs to be coordinated by the shard while it holds the critical section in a recoverable operation. In other words, if we decide to keep the shard version bump, clearJumboFlag would need to become a DDL coordinator.
Background
ShardingCatalogManager::clearJumboFlag issues a single update against config.chunks that clears the chunk's jumbo field and, in the same update, sets the chunk's lastmod to a freshly computed ChunkVersion(major+1, 0) (L2031-L2046). The bump propagates as a major-version change to every mongos and shard via the standard routing-table refresh path.
Why the bump is not necessary
- The only consumer of jumbo is the configsvr-side balancer. A repo-wide search for getJumbo / isJumbo returns four call sites, all in balancer_policy.cpp (L80, L489, L613, L815). Mongos's routing for queries, the shard's filtering metadata, and the CSR's view of ownership all ignore the field entirely.
- The matching set-jumbo path deliberately avoids a version bump. splitOrMarkJumbo already mutates the configsvr's in-memory chunk via markAsJumbo() and persists {jumbo: true} to config.chunks without touching lastmod. The comment inline acknowledges that "a subsequent incremental refresh will not see it. However, it is being marked in memory, so subsequent balancer iterations will not consider it for migration." The clear path can mirror this exactly.
- The bump is not just unnecessary — it is semantically wrong. The increment is a major bump (major+1, 0). Major bumps signal ownership / topology changes (chunks moved, split, merged); nothing about chunk topology has changed when the jumbo flag is cleared. If a bump ever had to stay, a minor bump would be defensible — a major bump never was.
- is depended on by
-
SERVER-121209 Make _configsrvSetAllowMigrations commit authoritatively
-
- In Progress
-