-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Blocker - P1
-
Affects Version/s: None
-
Component/s: mongodump
-
5
-
Tools and Replicator
-
0.75
-
Not Needed
Problem
SERVER-127688 (9.0) adds a maxEstimatedScanBytes server parameter that rejects queries at plan time when the plan requires an unbounded COLLSCAN on a collection whose logical size exceeds the threshold. Rejected queries fail with NoQueryExecutionPlans.
mongodump issues exactly such a query for every collection it dumps: an empty filter, no sort, no limit, and no hint. When an operator enables the knob, mongodump cannot dump any collection larger than the threshold:
{{writing `t.big` to `dumpA/t/big.bson`
Failed: (NoQueryExecutionPlans) error enumerating plans for query: ... ::
Query rejected by maxEstimatedScanBytes: plan requires an unbounded COLLSCAN
on a collection that exceeds the configured size threshold}}
There are two distinct failure sites:
- The dump query itself, DeferredQuery.Iter via DumpIntent (mongodump/mongodump.go).
- The pre-dump document count. DeferredQuery.Count (common/db/query.go) uses EstimatedDocumentCount for the common case — metadata only, unaffected — but falls through to CountDocuments, an aggregation, when the intent is a view. Aggregations are rejected by the knob too, so mongodump --viewsAsCollections fails earlier and with a more confusing message: error getting count from db: (NoQueryExecutionPlans) ....
The knob defaults to -1 (disabled), so nothing is broken out of the box. This is pre-emptive work for operators who enable it.
Solution
Send hint: {$natural: 1} on unfiltered dump queries. The server treats an explicit $natural hint as an opt-in declaration that the full scan is intentional and skips the rejection, metering it separately under serverStatus.metrics.query.maxEstimatedScanBytes so the operator retains visibility (query_planner_params.cpp: "A $natural hint in the command overrides the rejection.").
This is a no-op for plan selection — with an empty filter and no sort the planner already chooses a forward COLLSCAN, so the hint only declares what mongodump already does. The hint must not be applied when -query/-queryFile is set, since that would force a COLLSCAN over an index that could serve the predicate.
Two call sites:
- mongodump/mongodump.go — set findQuery.Hint when len(dump.query) == 0.
- common/db/query.go — plumb q.Hint into the CountDocuments options. DeferredQuery.Hint is public but currently populated by no caller, so this is additive.
Alternatives considered
Disabling the knob from mongodump (setParameter: {maxEstimatedScanBytes: -1}{}) was rejected. It requires the setParameter privilege, which the built-in backup role does not grant; it is per-process, so it would need fanning out across replica set members and shards; it changes global config for every other client; and it cannot be undone reliably — if mongodump is killed mid-dump, the operator's guardrail stays disabled indefinitely. Query settings (pqs_settable: true) remain available as an operator-side workaround for anyone on a build before this ships.
Testing
TestMongoDumpMaxEstimatedScanBytes sets the knob and dumps a collection above the threshold, plus a view over it to cover the count path. Skips below 9.0 and on mongos (setParameter does not propagate from mongos to shards). Verified to fail on both subtests without the fix.
- is depended on by
-
TOOLS-4313 mongoexport fails against servers with maxEstimatedScanBytes set
-
- Closed
-