On this page本页内容
MongoDB 4.2 removes support for the deprecated MMAPv1 storage engine.
If your 4.0 deployment uses MMAPv1, you must change the deployment to WiredTiger Storage Engine before upgrading to MongoDB 4.2. For details, see:
MongoDB removes the following MMAPv1 specific configuration options:
Removed Configuration File Setting | Removed Command-line Option |
---|---|
storage.mmapv1.journal.commitIntervalMs | |
storage.mmapv1.journal.debugFlags | mongod --journalOptions |
storage.mmapv1.nsSize | mongod --nssize |
storage.mmapv1.preallocDataFiles | mongod --noprealloc |
storage.mmapv1.quota.enforced | mongod --quota |
storage.mmapv1.quota.maxFilesPerDB | mongod --quotaFiles |
storage.mmapv1.smallFiles | mongod --smallfiles |
storage.repairPath | mongod --repairpath |
replication.secondaryIndexPrefetch | mongod --replIndexPrefetch |
Starting in version 4.2, MongoDB processes will not start with these options. Remove any MMAPv1 specific configuration options if using a WiredTiger deployment.
MongoDB removes the following MMAPv1 parameters:
newCollectionsUsePowerOf2Sizes
replIndexPrefetch
MongoDB removes the MMAPv1 specific touch
command.
MongoDB removes the MMAPv1 specific options:
noPadding
and usePowerOf2Sizes
for collMod
verbose
for collStats
flags
for create
paddingFactor
, paddingBytes
, preservePadding
for db.createCollection()
.MongoDB ignores the MMAPv1 specific option async
for fsync
.
group
CommandStarting in version 4.2, MongoDB removes the group
command (deprecated since version 3.4) and its mongo
shell helper db.collection.group()
.
Use db.collection.aggregate()
with the $group
stage instead.
eval
CommandStarting in version 4.2, MongoDB removes the eval
command. The eval
command has been deprecated since version 3.0.
The associated MongoDB 4.2 mongo
shell methods db.eval()
and db.collection.copyTo()
can only be run when connected to MongoDB 4.0 or earlier.
copydb
and clone
CommandsStarting in version 4.2, MongoDB removes the deprecated copydb
command and clone
command.
The corresponding mongo
shell helpers db.copyDatabase()
and db.cloneDatabase()
can only be run when connected to MongoDB 4.0 or earlier.
As alternatives, users can use mongodump
and mongorestore
(with the mongorestore
options --nsFrom
and --nsTo
) or write a script using the drivers.
For example, to copy the test
database from a local instance running on the default port 27017 to the examples
database on the same instance, you can:
Use mongodump
to dump the test
database to an archive mongodump-test-db
:
mongodump --archive="mongodump-test-db" --db=test
Use mongorestore
with --nsFrom
and --nsTo
to restore (with database name change) from the archive:
mongorestore --archive="mongodump-test-db" --nsFrom='test.*' --nsTo='examples.*'
Include additional options as necessary, such as to specify the uri or host, username, password and authentication database.
Alternatively, instead of using an archive file, you can mongodump
the test
database to the standard output stream and pipe into mongorestore
:
mongodump --archive --db=test | mongorestore --archive --nsFrom='test.*' --nsTo='examples.*'
parallelCollectionScan
CommandStarting in version 4.2, MongoDB removes the parallelCollectionScan
command.
maxScan
MongoDB removes the deprecated option maxScan
for the find
command and the mongo
shell helper cursor.maxScan()
. Use either the maxTimeMS
option for the find
command or the helper cursor.maxTimeMS()
instead.
geoNear
CommandStarting in version 4.2, MongoDB removes the geoNear
command. Use the $geoNear
aggregation stage instead.
The options for $geoNear
are similar to the removed geoNear
command with the following exceptions:
The removed geoNear
command includes in its output a field named dis
that included the distance information.
For the $geoNear
stage, specify the distance field name in distanceField
.
The removed geoNear
command accepts a boolean
value for the includeLocs
option to include the loc
field.
For the $geoNear
stage, specify the location field name in includeLocs
.
The removed geoNear
command includes the avgDistance
and maxDistance
of the returned results.
You can use the aggregation pipeline to return the avgDistance
and maxDistance
as well. Specifically, after the $geoNear
stage, include a $group
stage to calculate the avgDistance
and maxDistance
:
db.places.aggregate([ { $geoNear: { near: <...>, distanceField: "dis", includeLocs: "loc", spherical: true, ... } }, { $group: { _id: null, objectsLoaded: { $sum: 1 }, maxDistance: { $max: "$dis" }, avgDistance: { $avg: "$dis" } } } ])
repairDatabase
CommandStarting in version 4.2, MongoDB removes the repairDatabase
command and its mongo
shell helper db.repairDatabase()
as well as the repairDatabase
privilege.
As alternatives:
mongod
, use the compact
command. For details about the operation, see compact
command.reIndex
command or its helper db.collection.reIndex()
. For details about the operation, see reIndex
command and db.collection.reIndex()
reference pages.mongod --repair
. See Recover a Standalone after an Unexpected Shutdown for details.getPrevError
CommandStarting in version 4.2, MongoDB removes the deprecated getPrevError
command and its mongo
shell helper db.getPrevError()
.
cloneCollection
MongoDB deprecates the cloneCollection
command and its mongo
shell helper db.cloneCollection()
As alternatives,
mongoexport
and mongoimport
.$out
or $merge
stages.MongoDB deprecates the following:
PlanCache.getPlansByQuery()
method/planCacheListPlans
command.
$planCacheStats
aggregation stage instead. See Find Cache Entry Details for a Query Shape.PlanCache.listQueryShapes()
method/planCacheListQueryShapes
command.
$planCacheStats
aggregation stage instead. See List Query Shapes.$out
Stage Restrictions$out
and ViewsThe view definition pipeline
cannot include the $out
stage. If you already have an existing view that includes the $out
stage, you can no longer create new views from this existing view.
For existing views that include the $out
stage, you should either drop
and recreate
the views without the $out
stage or use replace the view definition
with a new pipeline that does not contain the $out
stage.
$out
and $lookup
The $lookup
stage cannot include the $out
stage in its nested pipeline field for the joined collection.
$out
and linearizable
Read Concern LevelThe $out
stage cannot be used in conjunction with read concern "linearizable"
.
$out
and ExplainYou cannot run the db.collection.explain()
method (or the explain
command) in executionStats
mode or allPlansExecution
mode if the aggregation pipeline contains the $out
stage.
If the aggregation pipeline contains the $out
stage, to view executionStats
or allPlansExecution
information, run explain without the $out
stage in order to return explain results for the preceding stages.
Alternatively, you can run explain in queryPlanner
mode for an aggregation pipeline that contains the $out
stage.
$out
and majority
Read Concern LevelStarting in MongoDB 4.2, you can specify read concern level "majority"
for an aggregation that includes an $out
stage.
In MongoDB 4.0 and earlier, you cannot include the $out
stage to use "majority"
read concern for the aggregation.
limit
and num
Options from $geoNear
Starting in version 4.2, MongoDB removes the limit
and num
options for the $geoNear
stage as well as the default limit of 100 documents. To limit the results of $geoNear
, use the $geoNear
stage with the $limit
stage.
For example, the following aggregation where the $geoNear
stage contains the num
option is no longer valid in 4.2.
db.places.aggregate([ { $geoNear: { near: { type: "Point", coordinates: [ -73.99279 , 40.719296 ] }, distanceField: "distance", num: 5, // Not supported in 4.2 spherical: true } } ])
Instead, you can rewrite the aggregation to the following pipeline:
db.places.aggregate([ { $geoNear: { near: { type: "Point", coordinates: [ -73.99279 , 40.719296 ] }, distanceField: "distance", spherical: true } }, { $limit: 5 } ])
killCursors
as the first operation in a transaction.Starting in MongoDB 4.2, change streams are available regardless of the "majority"
read concern support; that is, read concern majority
support can be either enabled (default) or disabled to use change streams.
In MongoDB 4.0 and earlier, change streams are available only if "majority"
read concern support is enabled (default).
Starting in MongoDB 4.2, change streams use simple
binary comparisons unless an explicit collation is provided. In earlier versions, change streams opened on a single collection (db.collection.watch()
) would inherit that collection's default collation.
Starting in MongoDB 4.2, change streams will throw an exception if the change stream aggregation pipeline modifies an event's _id field.
Starting in version 4.2, MongoDB removes the --sslFIPSMode
option for the following programs:
The programs will use FIPS compliant connections to mongod
/mongos
if the mongod
/mongos
instances are configured to use FIPS mode.
Starting in version 4.2:
Binary | Changes |
---|---|
bsondump | Uses Extended JSON v2.0 (Canonical mode) format. |
mongodump | Use Extended JSON v2.0 (Canonical mode) format for the metadata. Requires In general, use corresponding versions of |
mongoexport | Creates output data in Extended JSON v2.0 (Relaxed mode) by default.
Creates output data in Extended JSON v2.0 (Canonical mode) if used with
--jsonFormat . |
mongoimport | Expects import data to be in Extended JSON v2.0 (either Relaxed or Canonical mode) by default.
Can recognize data that is in Extended JSON v1.0 format if the option
--legacy is specified.In general, the versions of |
For details on MongoDB extended JSON v2, see MongoDB Extended JSON (v2).
--query
OptionsStarting in version 4.2, the query option for mongodump --query
and mongoexport --query
must be in Extended JSON v2 format (relaxed or canonical/strict mode), including enclosing the field names and the operators in quotes, as in the following:
mongoexport -d=test -c=records -q='{ "a": { "$gte": 3 }, "date": { "$lt": { "$date": "2016-01-01T00:00:00.000Z" } } }' --out=exportdir/myRecords.json
In earlier versions, the query options uses the Extended JSON v1 format and the field names and the operators do not need to be in quotes:
mongoexport -d=test -c=records -q='{ a: { $gte: 3 }, date: { $lt: { "$date": "2016-01-01T00:00:00.000Z" } } }' --out=exportdir/myRecords.json
Starting in MongoDB 4.2, replSetStepDown
(and replSetReconfig
that results in a step down) no longer closes all client connections. However, writes that were in progress are killed.
In MongoDB 4.0 and earlier, replSetStepDown
closes all client connections during the step down.
ROLLBACK
StateStarting in version 4.2, MongoDB kills all in-progress user operations when a member enters the ROLLBACK
state.
Drivers compatible with MongoDB 4.2 and higher enable Retryable Writes by default. Earlier drivers require the retryWrites=true
option. The retryWrites=true
option can be omitted in applications that use drivers compatible with MongoDB 4.2 and higher.
To disable retryable writes, applications that use drivers compatible with MongoDB 4.2 and higher must include retryWrites=false
in the connection string.
The local
database does not support retryable writes. Applications which write to the local
database will encounter write errors upon upgrading to a 4.2-series driver unlessretryable writes are explicitly disabled.
reIndex
MongoDB implements a stronger restriction on running reIndex
command and db.collection.reIndex()
shell helper against a collection in a sharded cluster by disallowing reIndex
and db.collection.reIndex()
on a mongos
.
db.collection.dropIndex()
MethodYou cannot specify db.collection.dropIndex("*")
to drop all non-_id
indexes. Use db.collection.dropIndexes()
instead.
MongoDB changes the returned response if you create an index with one name, and then try to create the index again with another name.
Starting in version 4.2, the createIndexes
command and the mongo
shell helpers db.collection.createIndex()
and db.collection.createIndexes()
report an error if you create an index with one name, and then try to create the same index again but with another name.
{ "ok" : 0, "errmsg" : "Index with name: x_1 already exists with a different name", "code" : 85, "codeName" : "IndexOptionsConflict" }
In previous versions, MongoDB did not create the index again, but would return a response object with ok
value of 1
and a note that implied that the index was not recreated. For example:
{ "numIndexesBefore" : 2, "numIndexesAfter" : 2, "note" : "all indexes already exist", "ok" : 1 }
For hashed indexes, MongoDB 4.2 ensures that the hashed value for the floating point value 2 63 on PowerPC is consistent with other platforms. In previous versions, the hashed value for the floating point value 2 63 on PowerPC is inconsistent with other platforms.
Although hashed indexes on a field that may contain floating point values greater than 2 53 is an unsupported configuration, clients may still insert documents where the indexed field has the value 2 63.
To list all hashed indexes for your deployment, see PowerPC and 2 63.
If the current MongoDB 4.0 sharded cluster on PowerPC contains hashed values for 2 63 as part of the shard key, additional considerations must be taken before upgrading the sharded cluster to 4.2. See Upgrade a Sharded Cluster to 4.2.
Starting in MongoDB 4.2, when specifying min()
/max()
for a db.collection.find()
operation, you must explicitly specify the index for min()
/max()
with the cursor.hint()
method unless the find()
query is an equality condition on the _id
field { _id: <value> }
.
Similarly, when specifying min
/max
in the find
command, you must also explicitly specify the hint
for the min
/max
index.
In previous versions, you could run min()
/max()
(or the corresponding min
/max
fields in the command) with or without explicitly hinting the index regardless of the query condition. If run without the hint in 4.0 and earlier, MongoDB selects the index using the fields in the indexBounds
; however, if multiple indexes exist on same fields with different sort orders, the selection of the index may be ambiguous.
"getmore"
operations, the $currentOp
aggregation stage, along with currentOp
command and the db.currentOp()
helper, now returns the originatingCommand
field as a nested field in the new cursor
field. In previous versions, the originatingCommand
was a top-level field for the associated "getmore"
document. See also 4.2 currentOp Changes.serverStatus
and db.serverStatus()
method return opcounters
and opcountersRepl
metrics as 64-bit integers (i.e. NumberLong) instead of 32-bit integers (i.e. NumberInt).When logging to syslog
, the format of the message text includes the component. For example:
... ACCESS [repl writer worker 5] Unsupported modification to roles collection ...
Previously, the syslog
message text did not include the component. For example:
... [repl writer worker 1] Unsupported modification to roles collection ...
getLog
command truncates any event that contains more than 1024 characters. In earlier versions, getLog
truncates after 512 characters.Starting in version 4.2, MongoDB logs the debug verbosity level. For example, if verbosity level is 2, MongoDB logs D2
.
D
for Debug level.OP_COMMAND
and the corresponding OP_COMMANDREPLY
wire protocol.killCursors
ChangesStarting in MongoDB 4.2, you cannot specify killCursors
as the first operation in a transaction.
Starting in MongoDB 4.2, users can always kill their own cursors, regardless of whether the users have the privilege to killCursors
. As such, the killCursors
privilege has no effect in MongoDB 4.2+.
In MongoDB 3.6.3 through MongoDB 4.0.x, users required the killCursors
privilege in order to kill their own cursors when access control is enabled.
AsyncRequestsSenderUseBaton
ParameterIn MongoDB 4.2+ deployment, MongoDB removes the AsyncRequestsSenderUseBaton
parameter and always enables the performance enhancement controlled by the parameter.
count
SyntaxStarting in version 4.2, MongoDB implements a stricter validation of the option names for the count
command. The command now errors if you specify an unknown option name.
In previous versions, MongoDB ignores invalid option names.
Starting in MongoDB 4.2, the following commands no longer support afterClusterTime:
As such, these operations cannot be associated with causally consistent sessions.
fastmodinsert
MetricMongoDB 4.2 removes the deprecated fastmodinsert
metric from various outputs, including the explain executionStats, the profiler output, etc.
Starting in version 4.2, MongoDB deprecates:
Starting in MongoDB 4.2:
The balancerStart
command and the mongo
shell helper methods sh.startBalancer()
and sh.setBalancerState(true)
also enable auto-splitting for the sharded cluster.
sh.disableAutoSplit()
.The balancerStop
command and the mongo
shell helper methods sh.stopBalancer()
and sh.setBalancerState(false)
also disable auto-splitting for the sharded cluster.
sh.enableAutoSplit()
.The mongo
methods sh.enableBalancing(namespace)
and sh.disableBalancing(namespace)
have no affect on the auto-splitting.
Starting in version 4.2, MongoDB reports on ReplicationStateTransition
lock information.
In addition, MongoDB 4.2 separates ParallelBatchWriterMode
lock information from Global
lock information. Earlier MongoDB versions report ParallelBatchWriterMode
lock information as part of Global
locks.
For operations that report on lock information, see:
serverStatus
command and db.serverStatus()
method.$currentOp
aggregation pipeline stage, currentOp
command, and db.currentOp()
method.findAndModify
Query/Sort/Projection Argument ValidationStarting in MongoDB 4.2 (and 4.0.12+ and 3.6.14+), the findAndModify
command and its associated mongo
shell methods error if the specified query, sort, or projection argument is not a document.
In earlier versions, the operation treated non-document query or sort argument as an empty document {}
.
See:
dropDatabase
and movePrimary
Starting in MongoDB 4.2,
If you drop a database and create a new database with the same name, either:
mongos
instances and mongod
shard members; orflushRouterConfig
command on all mongos
instances and mongod
shard members before reading or writing to that database.If you use the movePrimary
command to move unshardedcollections, either:
mongos
instances and mongod
shard members; orflushRouterConfig
command on all mongos
instances and mongod
shard members before reading or writing to that database.This ensures that mongos
and shard instances refresh their metadata cache. Otherwise, the you may miss data on reads, and may not write data to the correct shard. To recover, you must manually intervene.
In earlier versions, you only need to restart or run flushRouterConfig
on the mongos
instances.
For more information, see dropDatabase
and movePrimary
.
libldap
and libldap_r
For MongoDB 4.2 (and 4.0.9) Enterprise binaries linked against libldap
(such as when running on RHEL), access to the libldap
is synchronized, incurring some performance/latency costs.
For MongoDB 4.2 (and 4.0.9) Enterprise binaries linked against libldap_r
, there is no change in behavior from earlier MongoDB versions.
Starting in version 4.2, MongoDB changes the ldapUseConnectionPool
default values to:
true
on Windows.true
on Linux where MongoDB Enterprise binaries are linked against libldap_r
.That is, on those systems, MongoDB, by default, uses connection pooling to connect to the LDAP server for authentication/authorization.
In earlier versions (versions 4.0.9+), MongoDB uses false
as the default value for ldapUseConnectionPool
. That is, MongoDB, by default, does not use connection pooling to connect to the LDAP server for authentication/authorization.
See ldapUseConnectionPool
for details.
system.indexes
and system.namespaces
CollectionsStarting in version 4.2, MongoDB removes the system.indexes
and system.namespaces
collections (deprecated since v3.0).
With the removal of these collections, built-in roles clusterManager
, clusterMonitor
, dbAdmin
, read
, restore
, and other roles that inherit from these roles no longer provide privileges to directly access system.indexes
and system.namespaces
collections.
MongoDB 4.2 arbiter data files are incompatible with MongoDB 4.0. Downgrading from MongoDB 4.2 to 4.0 requires deleting arbiter data files as an intermediary step. Running a MongoDB 4.0 arbiter against MongoDB 4.2 data files may result in unexpected behavior.
The downgrade instructions for replica sets and sharded clusters include specific steps for downgrading arbiters from 4.2 to 4.0:
Starting in MongoDB 4.2,
replaceOne()
or update()
(when used with a replacement document), will first attempt to target a single shard by using the query filter. If the operation cannot target a single shard by the query filter, it then attempts to target by the replacement document. In earlier versions, these operations only attempt to target using the replacement document.save()
method is deprecated: use the insertOne()
or replaceOne()
method instead. The save()
method cannot be used with sharded collections that are not sharded by _id
, and attempting to do so will result in an error.upsert: true
and is on a sharded collection, the filter
must include an equality match on the full shard key.Some features in 4.2 require not just the 4.2 binaries but the featureCompatibilityVersion (fCV) set to 4.2. These features include:
failIndexKeyTooLong
parameter has no effect for MongoDB versions with fCV set to 4.2+ and only applies for MongoDB 2.6 through MongoDB versions with fCV set to "4.0"
or earlier.$type: 0
as a synonym for $exists:false
. To query for null or missing fields, see Query for Null or Missing Fields.