docs.mongodb.com Open in urlscan Pro
151.101.2.133  Public Scan

Form analysis
2 forms found in the DOM

GET https://docs.mongodb.com/search

<form role="search" method="GET" action="https://docs.mongodb.com/search" class="css-dc0gsv">
  <div class="css-87svlz">
    <div class="css-36i4c2"><input type="text" placeholder="Search all documentation..." class="css-etrcff" value=""></div>
    <div class="css-v2nqhr">
      <div class="css-aef77t"><button role="label" type="button" class="css-14k7wrz"><span data-testid="selected-value" class="css-6k4l2y">All Documentation</span>
          <div class="css-109dpaz"><svg data-testid="icon" width="16" height="9" viewBox="0 0 16 9" fill="none" xmlns="http://www.w3.org/2000/svg" class="css-1yzkxhp">
              <path d="M1.06689 0.799988L8.00023 7.73332L14.9336 0.799988" stroke-linecap="round" stroke-linejoin="round" class="css-1tlq8q9"></path>
            </svg></div>
        </button>
        <div class="css-hn9qqo">
          <ul data-testid="options" role="listbox" class="css-ac9zo2">
            <li role="option" tabindex="0" class="css-11dtrvq">General Information</li>
            <li role="option" tabindex="0" class="css-11dtrvq">All Documentation</li>
            <li role="option" tabindex="0" class="css-11dtrvq">Realm Documentation</li>
            <li role="option" tabindex="0" class="css-11dtrvq">Developer Articles &amp; Topics</li>
            <li role="option" tabindex="0" class="css-11dtrvq">Community Forums</li>
            <li role="option" tabindex="0" class="css-11dtrvq">Blog</li>
          </ul>
        </div>
      </div><input type="hidden" id="q" name="q" value=""><button tabindex="0" class=" css-cw9anm" data-track="true"><img alt="search icon"
          src="https://webimages.mongodb.com/_com_assets/cms/krc3hljsdwdfd2w5d-web-actions-search.svg?auto=format%252Ccompress" class="css-r9fohf"></button>
    </div>
  </div>
</form>

GET https://docs.mongodb.com/search

<form role="search" method="GET" action="https://docs.mongodb.com/search" class="css-11a71ad">
  <div class="css-7590ag"><input type="text" placeholder="Search all documentation..." class="css-xrkki1" value=""></div>
  <div class="css-abpu8v"><select class="select-overlay css-15v6p12" id="filter-select">
      <option value="General Information">General Information</option>
      <option selected="" value="All Documentation">All Documentation</option>
      <option value="Realm Documentation">Realm Documentation</option>
      <option value="Developer Articles &amp; Topics">Developer Articles &amp; Topics</option>
      <option value="Community Forums">Community Forums</option>
      <option value="Blog">Blog</option>
    </select><input type="hidden" id="q" name="q" value=""><button tabindex="0" class="css-1281qp9" data-track="true">Search</button></div>
</form>

Text Content

All Documentation

 * General Information
 * All Documentation
 * Realm Documentation
 * Developer Articles & Topics
 * Community Forums
 * Blog

 * Products
 * Solutions
 * Resources
 * Company
 * Pricing

Sign In
Try Free

General InformationAll DocumentationRealm DocumentationDeveloper Articles &
TopicsCommunity ForumsBlogSearch
Docs Menu
   
   MongoDB Documentation
   
   --------------------------------------------------------------------------------
   
   Back to Develop Applications
 * MongoDB Manual
   Version 5.0
 * Introduction
 * Installation
 * MongoDB Shell (mongosh)
 * MongoDB CRUD Operations
 * Aggregation
 * Data Models
 * Transactions
 * Indexes
 * Security
 * Change Streams
 * Replication
 * Sharding
 * Administration
 * Storage
 * Frequently Asked Questions
 * Reference
 * Release Notes
 * Release Notes for MongoDB 5.0
 * Release Notes for MongoDB 4.4
 * Release Notes for MongoDB 4.2
 * Compatibility Changes in MongoDB 4.2
 * Upgrade a Standalone to 4.2
 * Upgrade a Replica Set to 4.2
 * Upgrade a Sharded Cluster to 4.2
 * Downgrade 4.2 to 4.0
 * 4.2 Changelog
 * Release Notes for MongoDB 4.0
 * Release Notes for MongoDB 3.6
 * Release Notes for MongoDB 3.4
 * Release Notes for MongoDB 3.2
 * Release Notes for MongoDB 3.0
 * Release Notes for MongoDB 2.6
 * Release Notes for MongoDB 2.4
 * Release Notes for MongoDB 2.2
 * Release Notes for MongoDB 2.0
 * Release Notes for MongoDB 1.8
 * Release Notes for MongoDB 1.6
 * Release Notes for MongoDB 1.4
 * Release Notes for MongoDB 1.2.x
 * MongoDB Versioning
 * Technical Support

 * 



Docs Home → Develop Applications → MongoDB Manual


RELEASE NOTES FOR MONGODB 4.2¶

On this page

 * Minor Releases
 * Distributed Transactions
 * Removed MMAPv1 Storage Engine
 * Removed Commands and Methods
 * MongoDB Drivers
 * Sharded Clusters
 * Security Improvements
 * Aggregation Improvements
 * Change Stream
 * Update Enhancements
 * Wildcard Indexes
 * Platform Support
 * MongoDB Tools
 * Monitoring
 * Flow Control
 * Logging and Diagnostics
 * General Improvements
 * Query Plan Improvements
 * Optimized Index Builds
 * Changes Affecting Compatibility
 * Upgrade Procedures
 * Download
 * Known Issues
 * Report an Issue


MINOR RELEASES¶


4.2.17 - SEP 28, 2021¶

 * SERVER-59876: Large delays in returning from libcrypto.so while establishing
   egress connections
 * SERVER-59456: Start the LDAPReaper threadpool
 * SERVER-50549: Transform connection-related error codes in proxied commands
 * SERVER-49521: fix tests in core/txn to use write concern "majority" for
   createIndexes commands run before starting transactions
 * SERVER-44152: Pre-warm connection pools in mongos
 * All JIRA issues closed in 4.2.17
 * 4.2.17 Changelog


4.2.16 - SEP 13, 2021¶

Issues fixed in 4.2.16:

 * SERVER-59074: Do not acquire storage tickets just to set/wait on oplog
   visibility
 * SERVER-54729: MongoDB Enterprise Debian/Ubuntu packages should depend on
   libsasl2-modules and libsasl2-modules-gssapi-mit
 * SERVER-39621: Disabled chaining should enforce sync source change when the
   primary steps down even if the oplog fetcher isn't killed on sync source
 * SERVER-34938: Secondary slowdown or hang due to content pinned in cache by
   single oplog batch
 * WT-7776: Add a hard limit on the number of modify updates before we
   instantiate a complete update
 * All JIRA issues closed in 4.2.16
 * 4.2.16 Changelog


4.2.15 - JUL 13, 2021¶

Issues fixed in 4.2.15:

 * SERVER-57476: Operation may block on prepare conflict while holding oplog
   slot, stalling replication indefinitely
 * SERVER-56779: Do not use the collection distributed lock for chunk merges
 * SERVER-56240: Turn on checkpointing for the keystore Data Store
 * SERVER-56054: Change minThreads value for replication writer thread pool to 0
 * SERVER-47699: Change yield type used by range deleter from YIELD_MANUAL to
   YIELD_AUTO
 * All JIRA issues closed in 4.2.15
 * 4.2.15 Changelog


4.2.14 - MAY 6, 2021¶

Issues fixed in 4.2.14:

 * SERVER-54710: Large number of $or clauses can create profiling entry
   exceeding max BSON size, causing the query to fail when it should not
 * SERVER-54136: Make the authenticate command respect
   enforceUserClusterSeparation
 * SERVER-53566: Investigate and reproduce "opCtx != nullptr && _opCtx ==
   nullptr" invariant
 * SERVER-52564: Deadlock between step down and MongoDOperationContextSession
 * WT-7373: Improve slow random cursor operations on oplog
 * All JIRA issues closed in 4.2.14
 * 4.2.14 Changelog


4.2.13 - MAR 19, 2021¶

Issues fixed in 4.2.13:

 * SERVER-46686: Explain does not respect maxTimeMS
 * SERVER-46740: establishCursors() must always drain the
   AsyncRequestsSender::_baton
 * SERVER-46876: During the eviction pressure, we should quit the compact
   operation instead of crashing the process
 * SERVER-53394: Make ShardingTaskExecutorPoolReplicaSetMatching default to
   disabled for MongoD
 * WT-7028: Sweep thread shouldn't lock during checkpoint gathering handles
 * All JIRA issues closed in 4.2.13
 * 4.2.13 Changelog


4.2.12 - JAN 22, 2021¶

Issues fixed in 4.2.12:

 * SERVER-40361: Reduce memory footprint of plan cache entries
 * SERVER-47863: Initial Sync Progress Metrics
 * SERVER-48471: Hashed indexes may be incorrectly marked multikey and be
   ineligible as a shard key
 * SERVER-50769: server restarted after
   expr{"expr":"_currentApplyOps.getArrayLength() >
   0","file":"src/mongo/db/pipeline/document_source_change_stream_transform.cpp","line":535}}
 * SERVER-52654: new signing keys not generated by the monitoring-keys-for-HMAC
   thread
 * SERVER-52879: Periodic operation latency spikes every 5 minutes due to
   closing idle cached WT sessions
 * All JIRA issues closed in 4.2.12
 * 4.2.12 Changelog


4.2.11 - NOV 18, 2020¶

Issues fixed in 4.2.11:

 * SERVER-43664: Speedup WiredTiger storage engine startup for many tables by
   optimizing WiredTigerUtil::setTableLogging()
 * SERVER-45938: Allow matching O/OU/DC in client x509 cert if
   clusterMode:keyFile
 * SERVER-48523: Unconditionally check the first entry in the oplog when
   attempting to resume a change stream
 * SERVER-51120: Find queries with SORT_MERGE incorrectly sort the results when
   the collation is specified
 * WT-6507: Exit cache eviction worker after our operation has timed out
 * All JIRA issues closed in 4.2.11
 * 4.2.11 Changelog


4.2.10 - OCT 2, 2020¶

Issues fixed in 4.2.10:

 * SERVER-26726: Check number of arguments for createIndex() and throw error if
   more than two arguments
 * SERVER-31368: Log time spent waiting for other shards in merge cursors
   aggregation stage
 * SERVER-37422: Log balancer start and stop events in the actionlog
 * SERVER-40317: $facet execution has no limit on how much memory it can consume
 * SERVER-43233: Add ability to request only specific attribute(s) for the LDAP
   groups
 * SERVER-47469: applyOps does not take exclusive lock for views operation
 * SERVER-50463: Make PooledLDAPConnection::refresh take self-ownership
 * SERVER-51041: Throttle starting transactions for secondary reads
 * All JIRA issues closed in 4.2.10
 * 4.2.10 Changelog


4.2.9 - AUG 21, 2020¶

Issues fixed in 4.2.9:

 * SERVER-44051: getShardDistribution() does not report "Collection XYZ is not
   sharded" on dropped but previously sharded collections
 * SERVER-45610: Some reads work while system is RECOVERING
 * SERVER-47714: Secondary asserts on system.profile collection with
   WiredTigerRecordStore::insertRecord 95: Operation not supported
 * SERVER-48067: Reduce memory consumption for unique index builds with large
   numbers of non-unique keys
 * SERVER-49233: Introduce a flag to toggle the logic for bumping collection's
   major version during split
 * WT-6480: Fix a bug where files without block modification information were
   repeatedly copied at each incremental backup
 * All JIRA issues closed in 4.2.9
 * 4.2.9 Changelog


4.2.8 - JUN 15, 2020¶

Issues fixed in 4.2.8:

 * SERVER-46897: REMOVED node may never send heartbeat to fetch newest config
 * SERVER-47799: AsyncRequestsSender should update replica set monitor in
   between retries for InterruptedAtShutdown
 * SERVER-47994: Fix for numerical overflow in GeoHash
 * SERVER-48307: 3 Transactions that write to exactly one shard and read from
   one or more other shards may incorrectly indicate failure on retry after
   successful commit
 * WT-6366: Off-by-one overflow in block-modification bitmaps for incremental
   backup
 * All JIRA issues closed in 4.2.8
 * 4.2.8 Changelog


4.2.7 - MAY 26, 2020¶

Issues fixed in 4.2.7:

 * SERVER-47553: mongos crashes due to client disconnecting when signing keys
   being refreshed
 * SERVER-46487: The mongos routing for scatter/gather ops can have unbounded
   latency
 * SERVER-47190: Shutdown command with force:true should ignore all stepdown
   errors
 * SERVER-38731: Ability to specify sync source read preference in initial sync
 * All JIRA issues closed in 4.2.7
 * 4.2.7 Changelog


4.2.6 - APR 21, 2020¶

Issues fixed in 4.2.6:

 * SERVER-45119: CollectionShardingState::getCurrentShardVersionIfKnown returns
   collection version instead of shard version
 * SERVER-44892: getShardDistribution should use $collStats agg stage instead of
   collStats command
 * SERVER-43848: find/update/delete w/o shard key predicate under txn with
   snapshot read can miss documents
 * SERVER-42827: Allow sessions collection to return OK for creating indexes if
   at least one shard returns OK and others return
   CannotImplicitlyCreateCollection
 * SERVER-40805: Indicate the reason for replanning in the log file
 * SERVER-45389: Add metrics tracking how often shards have inconsistent indexes
 * SERVER-44689: Add serverStatus counter for each use of an aggregation stage
   in a user's request
 * All JIRA issues closed in 4.2.6
 * 4.2.6 Changelog


4.2.5 - MAR 26, 2020¶

Note

The release of version 4.2.4 was skipped due to an issue encountered during the
release. However, the 4.2.5 release includes the fixes made in 4.2.4.

Issues fixed in 4.2.5:

 * SERVER-45770: Add to information contained in logfile about "moveChunk.to"
 * All JIRA issues closed in 4.2.5
 * 4.2.5 Changelog

Issues fixed in 4.2.4:

 * SERVER-44915: Extend $indexStats output to include full index options and
   shard name
 * SERVER-46121: mongos crashes with invariant error after changing
   taskExecutorPoolSize
 * SERVER-45137: Increasing memory allocation in Top::record with high rate of
   collection creates and drops
 * SERVER-44904: Startup recovery should not delete corrupt documents while
   rebuilding unfinished indexes
 * SERVER-44260: Transaction can conflict with previous transaction on the
   session if the all committed point is held back
 * SERVER-35050: Don't abort collection clone due to negative document count
 * SERVER-39112: Primary drain mode can be unnecessarily slow
 * All JIRA issues closed in 4.2.4
 * 4.2.4 Changelog


4.2.3 - JAN 27, 2020¶

Issues fixed:

 * SERVER-42565: Aggregations and find commands sort missing fields differently
 * SERVER-44174: $push and $addToSet should restrict memory usage
 * SERVER-40435: A clearJumboFlag command to clear the jumbo flag
 * SERVER-45270: Increased vulnerability to slow DNS
 * TOOLS-1952: Use --forceTableScan by default when running against WiredTiger
   nodes
 * TOOLS-2453: Index keys not escaped correctly
 * SERVER-45396: fix the "me" field in isMaster responses when using
   splithorizon
 * SERVER-45309: Ensure bind credentials live longer than LDAP operations
 * SERVER-42697: Expose tcmalloc_release_rate via setParameter
 * WT-5120: Checkpoint hangs when reconciliation doesn't release the eviction
   generation
 * All JIRA issues closed in 4.2.3
 * 4.2.3 Changelog

Note

Fixed issues include those that resolve the following Common Vulnerabilities and
Exposure (CVE):

 * CVE-2020-7921 (See SERVER-45472)


4.2.2 - DEC 9, 2019¶

Issues fixed:

 * SERVER-31083: Allow passing primary shard to "enableSharding" command for a
   new database
 * SERVER-33272: The DatabaseHolder::close() function no longer requires a
   global write lock and neither does the dropDatabase command
 * SERVER-44050: Arrays along 'hashed' index key path are not correctly rejected
 * SERVER-43882: Building indexes for startup recovery uses unowned RecordData
   after yielding its cursor
 * SERVER-44617: $regexFind crash when one of the capture group doesn't match
   the input but pattern matches
 * SERVER-44721: Shell KMS AWS support cannot decrypt responses
 * SERVER-43860: Pipeline style update in $merge can produce unexpected result
 * WT-4961: Checkpoints with cache overflow must keep history for reads
 * All JIRA issues closed in 4.2.2
 * 4.2.2 Changelog


4.2.1 - OCT 18, 2019¶

Issues fixed:

 * SERVER-37768: Platform Support: Add Community & Enterprise Debian 10 x64
 * SERVER-37772: Platform Support: Add Community & Enterprise RHEL 8 x64
 * SERVER-41506: Track metrics associated with a node calling an election
 * SERVER-41499: Track number of elections called for each reason in
   serverStatus
 * SERVER-42518: Wildcard index plans miss results when the query path has
   multiple subsequent array indexes
 * SERVER-42856: Transactions with write can be sent to the wrong shard
 * All JIRA issues closed in 4.2.1
 * 4.2.1 Changelog


DISTRIBUTED TRANSACTIONS¶

Note
Distributed Transactions and Multi-Document Transactions

Starting in MongoDB 4.2, the two terms are synonymous. Distributed transactions
refer to multi-document transactions on sharded clusters and replica sets.
Multi-document transactions (whether on sharded clusters or replica sets) are
also known as distributed transactions starting in MongoDB 4.2.

In version 4.2, MongoDB introduces distributed transactions. Distributed
transactions:

 * Adds support for multi-document transactions on sharded clusters.
   
   * All members of the 4.2 sharded clusters must have
     featureCompatibilityVersion of 4.2.
   * Clients must use MongoDB drivers updated for MongoDB 4.2

 * Incorporates the existing support for transactions on replica sets.
   
   * All members of the 4.2 replica set must have featureCompatibilityVersion of
     4.2.
   * Clients must use MongoDB drivers updated for MongoDB 4.2
 * Removes the 16MB total size limit for a transaction. In version 4.2, MongoDB
   creates as many oplog entries (maximum size 16MB each) as necessary to
   encapsulate all write operations in a transaction. In MongoDB 4.0, MongoDB
   creates a single entry for all write operations in a transaction, thereby
   imposing a 16MB total size limit for a transaction.
 * Extends transaction support to deployments whose secondary members use the
   in-memory storage engine. That is, transactions are available for deployments
   that use the WiredTiger storage engine for the primary and either the
   WiredTiger or the in-memory storage engine for the secondary members. In
   MongoDB 4.0, transactions are available for deployments that use the
   WiredTiger storage engine only.

For more information, see Transactions.

Tip
See also:

4.2 Transaction Compatibility Changes


REMOVED MMAPV1 STORAGE ENGINE¶

MongoDB 4.2 removes 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:

 * Change Standalone to WiredTiger
 * Change Replica Set to WiredTiger
 * Change Sharded Cluster to WiredTiger


MMAPV1 SPECIFIC CONFIGURATION OPTIONS¶

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

Note

Starting in version 4.2, MongoDB processes will not start with these options.
Remove any MMAPv1 specific configuration options if using a WiredTiger
deployment.


MMAPV1 SPECIFIC PARAMETERS¶

MongoDB removes the following MMAPv1 parameters:

 * newCollectionsUsePowerOf2Sizes
 * replIndexPrefetch


MMAPV1 SPECIFIC COMMAND¶

MongoDB removes the MMAPv1 specific touch command.


MMAPV1 SPECIFIC OPTIONS FOR BINARIES, COMMANDS AND METHODS¶

MongoDB removes the MMAPv1 specific options:

 * noPadding and usePowerOf2Sizes for collMod
 * verbose for collStats
 * flags for create
 * paddingFactor, paddingBytes, preservePadding for the db.createCollection()
   method and the compact command.
 * repair for mongodump


REMOVED COMMANDS AND METHODS¶

Removed Command
Removed Method
Notes
group
db.collection.group()
Use db.collection.aggregate() with the $group stage instead.
eval

The 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


The corresponding mongo shell helpers db.copyDatabase() can only be run when
connected to MongoDB 4.0 or earlier.

As an alternative, users can use mongodump and mongorestore (see Copy/Clone a
Database) or write a script using the drivers.

clone


The corresponding mongo shell helpers db.cloneDatabase() can only be run when
connected to MongoDB 4.0 or earlier.

As an alternative, users can use mongodump and mongorestore (see Copy/Clone a
Database) or write a script using the drivers.

geoNear


Use db.collection.aggregate() with the $geoNear stage instead.

For more information, see Remove Support for the geoNear Command.

parallelCollectionScan


repairDatabase
db.repairDatabase()
For more information, see Remove Support for the repairDatabase Command.
getPrevError
db.getPrevError()



REMOVE MAXSCAN OPTION¶

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.


MONGODB DRIVERS¶

The following drivers are feature compatible [1] with MongoDB 4.2:

 * C 1.15.0
 * C# 2.9.0
 * Go 1.1

 * Java 3.11.0
 * Node 3.3.0
 * Perl 2.2.0

 * Python 3.9.0
 * Ruby 2.10.0
 * Scala 2.7.0

[1] For a complete list of official 4.2+ compatible drivers with support for
Client-Side Field Level Encryption, see Driver Compatibility Table.


RETRYABLE READS¶

Retryable reads allow MongoDB 4.2+ compatible drivers to automatically retry
certain read operations a single time if they encounter certain network or
server errors. See Retryable Reads for more information.


SHARDED CLUSTERS¶


MUTABLE SHARD KEY VALUES¶

Starting in MongoDB 4.2, you can update a document's shard key value unless the
shard key field is the immutable _id field. In MongoDB 4.2 and earlier, a
document's shard key field value is immutable.

For details on updating the shard key, see Change a Document's Shard Key Value.


BACKUPS¶

mongodump and mongorestore cannot be part of a backup strategy for 4.2+ sharded
clusters that have sharded transactions in progress, as backups created with
mongodump do not maintain the atomicity guarantees of transactions across
shards.

For 4.2+ sharded clusters with in-progress sharded transactions, use one of the
following coordinated backup and restore processes which do maintain the
atomicity guarantees of transactions across shards:

 * MongoDB Atlas,
 * MongoDB Cloud Manager, or
 * MongoDB Ops Manager.


BALANCER STATE AND AUTOSPLIT¶

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.
   
   To disable auto-splitting when the balancer is enabled, you can use
   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.
   
   To enable auto-splitting when the balancer is disabled, you can use
   sh.enableAutoSplit().

The mongo methods sh.enableBalancing(namespace) and
sh.disableBalancing(namespace) have no affect on the auto-splitting.


MONGOS / MONGOD CONNECTION POOL¶

Starting in MongoDB 4.2, MongoDB adds the parameter
ShardingTaskExecutorPoolReplicaSetMatching. This parameter determines the
minimum size of the mongod/mongos instance's connection pool to each member of
the sharded cluster. This value can vary during runtime.

mongod and mongos maintain connection pools to each replica set secondary for
every replica set in the sharded cluster. By default, these pools have a number
of connections that is at least the number of connections to the primary.

To modify, see ShardingTaskExecutorPoolReplicaSetMatching.


SHARDED COLLECTIONS AND REPLACE DOCUMENTS¶

Starting in MongoDB 4.2,

 * Operations which replace documents, such as 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.
 * The 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.
 * For a replace document operation that includes upsert: true and is on a
   sharded collection, the filter must include an equality match on the full
   shard key.


SECURITY IMPROVEMENTS¶


RESOLVED COMMON VULNERABILITIES AND EXPOSURES¶

MongoDB 4.2 includes fixes that resolve the following Common Vulnerabilities and
Exposures (CVEs):

 * CVE-2019-2389 (See SERVER-40563)
 * CVE-2019-2386 (See SERVER-38984)


NEW TLS OPTIONS¶

MongoDB 4.2 adds TLS options for the mongod, the mongos, and the mongo shell to
replace the corresponding SSL options (deprecated in 4.2). The new TLS options
provide identical functionality as the deprecated SSL options as MongoDB has
always supported TLS 1.0 and later.

 * For the command-line TLS options, refer to the mongod, mongos, and mongo
   shell pages.
 * For the corresponding mongod and mongos configuration file options, refer to
   the configuration file page.
 * For the connection string tls options, refer to the connection string page.

Tip

Most of the new TLS option names are similar to the SSL option name; e.g.
--tlsMode instead of --sslMode. The exceptions are:

 * net.tls.certificateKeyFile vs. net.ssl.PEMKeyFile
 * net.tls.certificateKeyFilePassword vs. net.ssl.PEMKeyPassword
 * --tlsCertificateKeyFile vs. --sslPEMKeyFile
 * --tlsCertificateKeyFilePassword vs. --sslPEMKeyPassword

Tip
See also:

New tlsClusterCAFile Option


DEPRECATED SSL OPTIONS¶

MongoDB 4.2 deprecates the SSL options for the mongod, the mongos, and the mongo
shell as well as the corresponding net.ssl Options configuration file options.

Use the new TLS options instead.


NEW TLS PARAMETERS¶

New Parameter
Description
tlsWithholdClientCertificate
Available for mongod and mongos, the parameter can be set to true to stop the
instance from sending its TLS certificate when initiating intra-cluster
communications with other mongod or mongos instances. For details, see
tlsWithholdClientCertificate.
tlsX509ClusterAuthDNOverride

Available for mongod and mongos, the parameter can be set to an alternative
certificate DN to use for x.509 membership authentication. For details, see
tlsX509ClusterAuthDNOverride.

You can use this parameter for a rolling update of certificates to new
certificates that contain a new DN value. See Rolling Update of x.509 Cluster
Certificates that Contain New DN.


NEW TLSCLUSTERCAFILE OPTION¶

MongoDB 4.2 adds the --tlsClusterCAFile option/net.tls.clusterCAFile for mongod
and mongos, which specifies a .pem file for validating the TLS certificate from
a client establishing a connection. This lets you use separate Certificate
Authorities to verify the client to server and server to client portions of the
TLS handshake.

Tip
See also:

New TLS Options


FORWARD SECRECY¶

Starting in version 4.2 on Linux:

 * If the platform's OpenSSL supports automatic curve selection for Elliptic
   Curve Diffie-Hellman, MongoDB enables support for Ephemeral Elliptic Curve
   Diffie-Hellman (ECDHE).
 * If the platform's OpenSSL does not support automatic curve selection for
   Elliptic Curve Diffie-Hellman, MongoDB attempts to enable ECDHE support using
   prime256v1 as the named curve.
 * If support for ECDHE is enabled, MongoDB attempts to enable support for
   Ephemeral Diffie-Hellman (DHE) if Ephemeral Diffie-Hellman (DHE) is not
   explicitly enabled.

In earlier versions of MongoDB (3.6.14+ and 4.0.3+), MongoDB enables support for
Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) if, during compile time, the
Linux platform's OpenSSL supports automatic curve selection of ECDH parameters.

On Windows and macOS, MongoDB's support for ECDHE and DH remain unchanged from
earlier versions; that is, support is implicit through the use of the platform's
respective native TLS/SSL OS libraries.

For more information, see Forward Secrecy.


PASSWORDPROMPT()¶

Starting in version 4.2 of the mongo shell, you can use the passwordPrompt()
method in conjunction with various user authentication/management
methods/commands to prompt for the password instead of specifying the password
directly in the method/command call. However, you can still specify the password
directly as you would with earlier versions of the mongo shell.

For example:

db.createUser( {   user:"user123",   pwd: passwordPrompt(),   // Instead of specifying the password in cleartext   roles:[ "readWrite" ]} )




KEYFILE FORMAT CHANGE TO YAML¶

Starting in MongoDB 4.2, keyfiles for internal membership authentication use
YAML format to allow for multiple keys in a keyfile. The YAML format accepts
content of:

 * a single key string (same as in earlier versions),
 * multiple key strings (each string must be enclosed in quotes), or
 * sequence of key strings.

The YAML format is compatible with the existing single-key keyfiles that use the
text file format.

The new format allows for rolling upgrade of the keys without downtime. See
Rotate Keys for Replica Sets and Rotate Keys for Sharded Clusters.


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.


ENCRYPTED STORAGE ENGINE¶

For encrypted storage engine configured with AES256-GCM cipher:

 * Restoring from Hot BackupStarting in 4.2, if you restore from files taken via
   "hot" backup (i.e. the mongod is running), MongoDB can detect "dirty" keys on
   startup and automatically rollover the database key to avoid IV
   (Initialization Vector) reuse.
 * Restoring from Cold Backup
   
   However, if you restore from files taken via "cold" backup (i.e. the mongod
   is not running), MongoDB cannot detect "dirty" keys on startup, and reuse of
   IV voids confidentiality and integrity guarantees.
   
   Starting in 4.2, to avoid the reuse of the keys after restoring from a cold
   filesystem snapshot, MongoDB adds a new command-line option
   --eseDatabaseKeyRollover. When started with the --eseDatabaseKeyRollover
   option, the mongod instance rolls over the database keys configured with
   AES256-GCM cipher and exits.

For more information, see encrypted storage engine and --eseDatabaseKeyRollover.


CLIENT-SIDE FIELD LEVEL ENCRYPTION¶

The official MongoDB 4.2+ compatible drivers provide a client-side field level
encryption framework. Applications can encrypt fields in documents prior to
transmitting data over the wire to the server. Only applications with access to
the correct encryption keys can decrypt and read the protected data. Deleting an
encryption key renders all data encrypted with that key as permanently
unreadable.

For a complete list of official 4.2+ compatible drivers with support for
client-side field level encryption, see Driver Compatibility Table.

For an end-to-end procedure for configuring field level encryption using select
MongoDB 4.2+ compatible drivers, see the Client Side Field Level Encryption
Guide.

Explicit (manual) encryption of fields

Official MongoDB 4.2+ compatible drivers and the MongoDB 4.2 or later mongo
shell support explicitly encrypting or decrypting fields with a specific data
encryption key and encryption algorithm.

Applications must modify any code associated with constructing read and write
operations to include encryption/decryption logic via the driver encryption
library. Applications are responsible for selecting the appropriate data
encryption key for encryption/decryption on a per-operation basis.

For more information, see Explicit (Manual) Client-Side Field Level Encryption.

Automatic encryption of fields
Note
Enterprise Feature

The automatic feature of field level encryption is only available in MongoDB
Enterprise 4.2 or later, and MongoDB Atlas 4.2 or later clusters.

Official MongoDB 4.2+ compatible drivers and the MongoDB 4.2 or later mongo
shell support automatically encrypting fields in read and write operations.

Applications must create a database connection object (e.g. MongoClient) with
the automatic encryption configuration settings. The configuration settings must
include automatic encryption encryption rules using a strict subset of the JSON
Schema Draft 4 standard syntax and encryption-specific schema keywords.
Applications do not have to modify code associated with constructing the
read/write operation. See Automatic Encryption Rules for complete documentation
on automatic encryption rules.

For more information, see Automatic Client-Side Field Level Encryption.

For complete documentation on client-side field level encryption, see
Client-Side Field Level Encryption.


GENERAL SECURITY ENHANCEMENTS¶

 * Add serverStatus to the backup built-in role.

 * To connect a client over TLS/SSL connection, MongoDB 4.2 supports matching by
   IP addresses as well as DNS for Subject Alternative Name (SAN) matching.
   
   For example, a mongod instance's x.509 certificate has the following SAN:
   
   X509v3 Subject Alternative Name:    DNS:hostname.example.com, DNS:localhost, IP Address:127.0.0.1
   
   Then, to connect a mongo shell to the instance, you can specify the host of
   127.0.0.1 or the DNS names:
   
   * mongo "mongodb:\\127.0.0.1:27017\test" --tls --tlsCAFile /etc/ssl/ca.pem ...
   
   * mongo "mongodb:\\hostname.example.com:27017\test" --tls --tlsCAFile /etc/ssl/ca.pem ...
   
   * mongo "mongodb:\\localhost:27017\test" --tls --tlsCAFile /etc/ssl/ca.pem ...
   
   In previous versions, MongoDB only supported DNS entries for SAN matching.
   
   * mongo "mongodb:\\hostname.example.com:27017\test" --tls --tlsCAFile /etc/ssl/ca.pem ...
   
   * mongo "mongodb:\\localhost:27017\test" --tls  --tlsCAFile /etc/ssl/ca.pem ...


LDAP QUERY TEMPLATE {PROVIDED_USER} TOKEN¶

Starting in version 4.2, MongoDB Enterprise adds a new token {PROVIDED_USER}
that can be used in security.ldap.authz.queryTemplate. When used in the
template, MongoDB substitutes the supplied username, i.e. before either
authentication or LDAP transformation.


AGGREGATION IMPROVEMENTS¶


ON-DEMAND MATERIALIZED VIEW ($MERGE STAGE)¶

MongoDB 4.2 adds the $merge aggregation stage.

With the new stage you can:

 * Can output to a collection in the same or different database.
 * Can incorporate results (merge documents, replace documents, keep existing
   documents, fail the operation, process documents with an custom update
   pipeline) into an existing collection.
 * Can output to an existing sharded collection.

The new stage allows users to create on-demand materialized views, where the
content of the output collection can be incrementally updated each time the
pipeline is run.


AGGREGATION TRIGONOMETRY EXPRESSIONS¶

MongoDB 4.2 adds new trigonometry expressions for use in aggregation pipelines.

Trigonometry expressions perform trigonometric operations on numbers. Values
that represent angles are always input or output in radians. Use
$degreesToRadians and $radiansToDegrees to convert between degree and radian
measurements.

Name
Description
$sin
Returns the sine of a value that is measured in radians.
$cos
Returns the cosine of a value that is measured in radians.
$tan
Returns the tangent of a value that is measured in radians.
$asin
Returns the inverse sin (arc sine) of a value in radians.
$acos
Returns the inverse cosine (arc cosine) of a value in radians.
$atan
Returns the inverse tangent (arc tangent) of a value in radians.
$atan2
Returns the inverse tangent (arc tangent) of y / x in radians, where y and x are
the first and second values passed to the expression respectively.
$asinh
Returns the inverse hyperbolic sine (hyperbolic arc sine) of a value in radians.
$acosh
Returns the inverse hyperbolic cosine (hyperbolic arc cosine) of a value in
radians.
$atanh
Returns the inverse hyperbolic tangent (hyperbolic arc tangent) of a value in
radians.
$sinh
Returns the hyperbolic sine of a value that is measured in radians.
$cosh
Returns the hyperbolic cosine of a value that is measured in radians.
$tanh
Returns the hyperbolic tangent of a value that is measured in radians.
$degreesToRadians
Converts a value from degrees to radians.
$radiansToDegrees
Converts a value from radians to degrees.


AGGREGATION ARITHMETIC EXPRESSIONS¶

MongoDB 4.2 adds the $round aggregation expression. Use $round to round
numerical values to a specific digit or decimal place.

MongoDB 4.2 adds expanded functionality and new syntax to $trunc. Use $trunc
with the new syntax to truncate numerical values to a specific digit or decimal
place.


AGGREGATION REGULAR EXPRESSIONS (REGEX) OPERATORS¶

MongoDB 4.2 adds the following regular expression (regex) pattern matching
operators for use in the aggregation pipeline:

Operator
Description
$regexFind
Applies a regular expression (regex) to a string and returns information on the
first matched substring.
$regexFindAll
Applies a regular expression (regex) to a string and returns information on all
matched substrings.
$regexMatch
Applies a regular expression (regex) to a string and returns true if a match is
found and false if a match is not found.

Prior to MongoDB 4.2, aggregation pipeline can only use the query operator
$regex in the $match stage.


NEW STAGES¶

MongoDB 4.2 adds the following new aggregation pipeline stages:

New Stage
Description
$merge
Writes the aggregation results to a collection. The $merge stage can incorporate
results (merge documents, replace documents, keep existing documents, fail the
operation, process documents with an custom update pipeline) into an existing
collection.
$planCacheStats

Provides plan cache information for a collection.

The $planCacheStats aggregation stage is preferred over the following methods
and commands, which have been deprecated in 4.2:

 * PlanCache.getPlansByQuery() method/planCacheListPlans command, and
 * PlanCache.listQueryShapes() method/planCacheListQueryShapes command.

Tip
See also:

Deprecated Plan Cache Commands/Methods

$replaceWith
Replaces the input document with the specified document. The operation replaces
all existing fields in the input document, including the _id field. The new
$replaceWith stage is an alias to the $replaceRoot stage.
$set
Adds new fields to documents. The stage outputs documents that contains all
existing fields from the input documents as well as the newly added fields. The
new $set stage is an alias to the $addFields stage.
$unset
Excludes fields from documents. The new $unset stage is an alias to the $project
stage that excludes fields.


NEW VARIABLES¶

MongoDB 4.2 adds the following new aggregation pipeline variables:

Variable
Description
NOW
Returns the current datetime value.
CLUSTER_TIME

Returns the current timestamp value.

Only available on replica sets and sharded clusters.


AVAILABILITY¶

Starting in MongoDB 4.2, you can use the aggregation pipeline for updates in:

Command
mongosh Methods
findAndModify
db.collection.findOneAndUpdate()
db.collection.findAndModify()
update
db.collection.updateOne()
db.collection.updateMany()
db.collection.update()
Bulk.find.update()
Bulk.find.updateOne()
Bulk.find.upsert()

For the updates, the pipeline can consist of the following stages:

 * $addFields and its alias $set
 * $project and its alias $unset
 * $replaceRoot and its alias $replaceWith.

Using the aggregation pipeline allows for a more expressive update statement,
such as expressing conditional updates based on current field values or updating
one field using the value of another field(s).

See the individual reference pages for details and examples.

Tip
See also:
 * Updates with Aggregation Pipeline
 * Aggregation


CHANGE STREAM¶


STARTAFTER OPTION FOR CHANGE STREAMS¶

MongoDB 4.2 adds startAfter as an option for Change Streams, which starts a new
change stream after the event indicated by a resume token. With this option, you
can start a change stream from an invalidate event, thereby guaranteeing no
missed notifications after the previous stream was invalidated.


CHANGE STREAMS RESUME TOKENS¶

MongoDB 4.2 uses the version 1 (i.e. v1) change streams resume tokens,
introduced in version 4.0.7.

Starting in MongoDB 4.2, change streams will throw an exception if the change
stream aggregation pipeline modifies an event's _id field.


AVAILABILITY¶

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).


CHANGE STREAM PIPELINE¶

Starting in MongoDB 4.2, you can use additional stages in the change stream
aggregation pipeline to modify the change stream output (i.e. the event
documents):

 * $replaceWith
 * $set
 * $unset

Starting in MongoDB 4.2, change streams will throw an exception if the change
stream aggregation pipeline modifies an event's _id field.

Tip
See also:

Change Streams Compatibility Changes


UPDATE ENHANCEMENTS¶


UPDATE AND AGGREGATION¶

Starting in MongoDB 4.2, you can use the aggregation pipeline for updates in:

Command
mongosh Methods
findAndModify
db.collection.findOneAndUpdate()
db.collection.findAndModify()
update
db.collection.updateOne()
db.collection.updateMany()
db.collection.update()
Bulk.find.update()
Bulk.find.updateOne()
Bulk.find.upsert()

For the updates, the pipeline can consist of the following stages:

 * $addFields and its alias $set
 * $project and its alias $unset
 * $replaceRoot and its alias $replaceWith.

Using the aggregation pipeline allows for a more expressive update statement,
such as expressing conditional updates based on current field values or updating
one field using the value of another field(s).

See the individual reference pages for details and examples.


UPDATE AND HINT¶

Starting in MongoDB 4.2, the update command and the associated mongo shell
method db.collection.update() can accept a hint argument to specify the index to
use. See:

 * update
 * db.collection.update()


SHARDED COLLECTIONS AND REPLACE DOCUMENTS¶

Starting in MongoDB 4.2,

 * Operations which replace documents, such as 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.
 * The 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.
 * For a replace document operation that includes upsert: true and is on a
   sharded collection, the filter must include an equality match on the full
   shard key.


WILDCARD INDEXES¶

MongoDB 4.2 introduces wildcard indexes for supporting queries against fields
whose names are unknown or arbitrary.

Consider an application that captures user-defined data under the userMetadata
field and supports querying against that data:

{ "userMetadata" : { "likes" : [ "dogs", "cats" ] } }{ "userMetadata" : { "dislikes" : "pickles" } }{ "userMetadata" : { "age" : 45 } }{ "userMetadata" : "inactive" }

Administrators want to create indexes to support queries on any subfield of
userMetadata.

A wildcard index on userMetadata can support single-field queries on
userMetadata, userMetadata.likes, userMetadata.dislikes, and userMetadata.age:

db.userData.createIndex( { "userMetadata.$**" : 1 } )



The index can support the following queries:

db.userData.find({ "userMetadata.likes" : "dogs" })db.userData.find({ "userMetadata.dislikes" : "pickles" })db.userData.find({ "userMetadata.age" : { $gt : 30 } })db.userData.find({ "userMetadata" : "inactive" })

A non-wildcard index on userMetadata can only support queries on values of
userMetadata.

Important

Wildcard indexes are not designed to replace workload-based index planning. For
more information on creating indexes to support queries, see Create Indexes to
Support Your Queries. For complete documentation on wildcard index limitations,
see Wildcard Index Restrictions.

The mongod featureCompatibilityVersion must be 4.2 to create wildcard indexes.
For instructions on setting the fCV, see Set Feature Compatibility Version on
MongoDB 5.0 Deployments.

You can create a wildcard index using the createIndexes database command or its
shell helpers db.collection.createIndex() and db.collection.createIndexes(). For
examples of creating a wildcard index, see Create a Wildcard Index.

See Wildcard Indexes for complete documentation.


PLATFORM SUPPORT¶

 * MongoDB 4.2 adds support for:
   
   * Ubuntu 18.04 on ARM64

 * MongoDB 4.2 removes support for:
   
   * Debian 8
   * Ubuntu 14.04
   * Ubuntu 16.04 ARM64 for MongoDB Community Edition
   * Ubuntu 16.04 POWER/PPC64LE (Also removed in version 3.6.13 and 3.4.21)
   * macOS 10.11

See Supported Platforms.


MONGODB TOOLS¶


FIPS MODE¶

Starting in version 4.2, MongoDB removes the --sslFIPSMode option for the
following programs:

 * mongodump
 * mongoexport
 * mongofiles
 * mongoimport
 * mongorestore
 * mongostat
 * mongotop

The programs will use FIPS compliant connections to mongod/mongos if the
mongod/mongos instances are configured to use FIPS mode.


--URI OPTION¶

Starting in version 4.2,

 * For the following Database Tools, if the write concern is specified in both
   the --uri connection string and the --writeConcern option, the --writeConcern
   option overrides the one in the connection string:
   
   * mongofiles
   * mongoimport
   * mongorestore

 * For the following Database Tools, if the read preference is specified in both
   the --uri connection string and the --readPreference option, the
   --readPreference option overrides the one in the connection string:
   
   * mongodump
   * mongoexport
   * mongofiles


EXTENDED JSON V2¶

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
mongorestore version 4.2 or later that supports Extended JSON v2.0 (Canonical
mode or Relaxed) format.

Tip

In general, use corresponding versions of mongodump and mongorestore. That is,
to restore data files created with a specific version of mongodump, use the
corresponding version of mongorestore.

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.
Tip

In general, the versions of mongoexport and mongoimport should match. That is,
to import data created from mongoexport, you should use the corresponding
version of mongoimport.

For details on MongoDB extended JSON v2, see MongoDB Extended JSON (v2).

Tip
See also:

--query Options


MONGOFILES¶

The mongofiles command get_id and delete_id can accept both ObjectId or
non-ObjectId values for the _id.


BULK OPERATIONS FOR MONGOIMPORT AND MONGORESTORE¶

MONGOIMPORT¶

Starting in version 4.2:

 * mongoimport uses maximum batch size of 100,000 to perform bulk insert/upsert
   operations.
 * mongoimport by default, continues when it encounters duplicate key and
   document validation errors. To ensure that the program stops on these errors,
   specify --stopOnError.

 * Specifying --maintainInsertionOrder for mongoimport:
   
   * Maintains document insertion order using ordered bulk write operations;
     i.e. both the batch order and document order within the batches are
     maintained. In earlier versions, only the batch order is maintained;
     document order within batches are not maintained.
   * Enables --stopOnError and sets numInsertionWorkers to 1.

MONGORESTORE¶

Starting in version 4.2:

 * mongorestore by default, continues when it encounters duplicate key and
   document validation errors. To ensure that the program stops on these errors,
   specify --stopOnError.

 * Specifying --maintainInsertionOrder for mongorestore:
   
   * Maintains document insertion order using ordered bulk write operations;
     i.e. both the batch order and document order within the batches are
     maintained. In earlier versions, only the batch order is maintained;
     document order within batches are not maintained.
   * Enables --stopOnError and sets --numInsertionWorkersPerCollection to 1.


LOCK OPTIMIZATION FOR SPECIFIC DDL OPERATIONS¶

Starting with MongoDB 4.2, the following operations take an exclusive collection
lock instead of an exclusive database lock:

Commands
Methods
create

db.createCollection()

db.createView()

createIndexes

db.collection.createIndex()

db.collection.createIndexes()

drop
db.collection.drop()
dropIndexes

db.collection.dropIndex()

db.collection.dropIndexes()

renameCollection
db.collection.renameCollection()

Prior to MongoDB 4.2, these operations took an exclusive lock on the database,
blocking all operations on the database and its collections until the operation
completed.

In earlier versions, get_id and delete_id can only accept ObjectId values for
the _id.


MONITORING¶

Starting in version 4.2, the Storage Node Watchdog is available in both the
MongoDB Community edition and the MongoDB Enterprise edition.

In earlier versions, the feature is available in the MongoDB Enterprise edition
only.


FLOW CONTROL¶

MongoDB 4.2 introduces a flow control mechanism to control the rate at which the
primary applies its writes in order to keep the majority committed lag under a
specified maximum value.

Flow control is enabled by default.

Note

For flow control to engage, the replica set/sharded cluster must have:
featureCompatibilityVersion (FCV) of 4.2 and read concern majority enabled. That
is, enabled flow control has no effect if FCV is not 4.2 or if read concern
majority is disabled.

For more information, see Replication Lag and Flow Control.


LOGGING AND DIAGNOSTICS¶


LOGGING¶

 * Added INITSYNC component to log messages.
 * Added ELECTION component to log messages.
 * For debug messages, include the verbosity level (i.e. D [1-5]). For example,
   if verbosity level is 2, MongoDB logs D2. In previous versions, MongoDB log
   messages only specified D for Debug level.

 * 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 ...
   
   
 * MongoDB 4.2 adds a usedDisk indicator to the profiler log messages and
   diagnostic log messages for the aggregate operation. The usedDisk indicates
   whether any stages of an aggregate operation wrote data to temporary files
   due to memory restrictions. For more information on aggregation memory
   restrictions, see Memory Restrictions.

 * Starting in version 4.2 (also available starting in 4.0.6), secondary members
   of a replica set now log oplog entries that take longer than the slow
   operation threshold to apply. These messages are logged for the secondaries
   under the REPL component with the text applied op: <oplog entry> took
   <num>ms.
   
   2018-11-16T12:31:35.886-0500 I REPL   [repl writer worker 13] applied op: command { ... }, took 112ms
   
   
   
   The slow oplog application logging on secondaries are:
   
   * Not affected by the slowOpSampleRate; i.e. all slow oplog entries are
     logged by the secondary.
   * Not affected by the logLevel/systemLog.verbosity level (or the
     systemLog.component.replication.verbosity level); i.e. for oplog entries,
     the secondary logs only the slow oplog entries. Increasing the verbosity
     level does not log all oplog entries.
   * Not captured by the profiler and not affected by the profiling level.
   
   For more information on setting the slow operation threshold, see
   
   * mongod --slowms
   * slowOpThresholdMs
   * The profile command or db.setProfilingLevel() shell helper method.
 * Starting in MongoDB 4.2, the getLog command truncates any event that contains
   more than 1024 characters. In earlier versions, getLog truncates after 512
   characters.
 * Starting in MongoDB 4.2 (and in 4.0.9), for slow operations, the profiler
   entries and diagnostic log messages include storage information.

 * Starting in MongoDB 4.2, the profiler entries and the diagnostic log messages
   (i.e. mongod/mongos log messages) for read/write operations include:
   
   * queryHash to help identify slow queries with the same query shape.
   * planCacheKey to provide more insight into the query plan cache for slow
     queries.
   
   See Query Plan Improvements.


CURRENTOP¶

MongoDB 4.2 adds a new option idleCursors to the $currentOp aggregation stage in
order to return information on idle cursors.

In addition, MongoDB 4.2 adds the following new fields to the documents returned
from the $currentOp aggregation stage, currentOp command, and db.currentOp()
helper:

$currentOp
currentOp/db.currentOp()
Description
$currentOp.type
currentOp.type
Specifies whether the reported operation is an op, idleSession, or idleCursor.
$currentOp.cursor
currentOp.cursor
Specifies cursor details. Available when returning getmore operations or
idleCursor information.
$currentOp.effectiveUsers
currentOp.effectiveUsers
Specifies users associated with the operation.
$currentOp.prepareReadConflicts
currentOp.prepareReadConflicts
Specifies the number of times the current operation had to wait for a prepared
transaction with a write to commit or abort.
$currentOp.runBy
currentOp.runBy
Specifies users that are impersonating the effective users for the operation.
$currentOp.writeConflicts
currentOp.writeConflicts
Specifies the number of times the current operation conflicted with another
write operation.

See also 4.2 current op compatibility changes


SERVERSTATUS METRICS¶

Starting in MongoDB 4.2, the serverStatus command and the mongo shell method
db.serverStatus() include the following output changes:

Updates to
Changes
shardingStatistics

Added new fields:

 * shardingStatistics.countDocsClonedOnRecipient
 * shardingStatistics.countDocsClonedOnDonor
 * shardingStatistics.countDocsDeletedOnDonor
 * shardingStatistics.countRecipientMoveChunkStarted
 * shardingStatistics.countDonorMoveChunkLockTimeout

metrics.repl.network:

Added new fields:

 * metrics.repl.network.notMasterLegacyUnacknowledgedWrites
 * metrics.repl.network.notMasterUnacknowledgedWrites

metrics.repl

Added new metrics.repl.stepDown metrics:

 * metrics.repl.stepDown.userOperationsKilled
 * metrics.repl.stepDown.userOperationsRunning

transactions
 * Now available for mongos (previously only for mongod)

 * Added new fields for mongod instances:
   
   * transactions.totalPrepared
   * transactions.totalPreparedThenCommitted
   * transactions.totalPreparedThenAborted
   * transactions.currentPrepared

logicalSessionRecordCache
Added new field logicalSessionRecordCache.sessionCatalogSize
locks

Separate ParallelBatchWriterMode from Global lock information.

Add ReplicationStateTransition lock information.


REPLICA SET STATUS METRICS¶

Starting in version MongoDB 4.2, replSetGetStatus and its mongo shell helper
rs.status() return:

 * The IP address, replSetGetStatus.members[n].ip for the replica set members.

 * ISODate-formatted date string fields that correspond to the various
   replSetGetStatus.optimes.
   
   New ISODate-Formatted Date String Field
   Corresponding Optime Field
   lastCommittedWallTime
   lastCommittedOpTime
   readConcernMajorityWallTime
   readConcernMajorityOpTime
   lastAppliedWallTime
   appliedOpTime
   lastDurableWallTime
   durableOpTime

MongoDB 4.2 deprecates the field lastStableCheckpointTimestamp.


LOCK DIAGNOSTICS REPORTING¶

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.


COLLSTATS IMPROVEMENTS¶

Starting in MongoDB 4.2, the $collStats aggregation, the collStats command, and
the mongo shell helper db.collection.stats() return information on indexes that
are currently being built.

For details, see:

 * collStats.nindexes
 * collStats.indexDetails
 * collStats.indexBuilds
 * collStats.totalIndexSize
 * collStats.indexSizes

Starting in MongoDB 4.2, the $collStats aggregation, the collStats command, and
the mongo shell helper db.collection.stats() return the scaleFactor used to
scale the various size data.


DBSTATS IMPROVEMENTS¶

Starting in MongoDB 4.2, the dbStats command, and the mongo shell helper
db.stats() return the scaleFactor used to scale the various size data.


GENERAL IMPROVEMENTS¶


EXTERNALLY SOURCED VALUES FOR CONFIGURATION FILES¶

MongoDB supports using expansion directives in configuration files to load
externally sourced values. Expansion directives can load values for specific
configuration file options or load the entire configuration file.

The following expansion directives are available:

Expansion Directive
Description
__rest
Allows users to specify a REST endpoint as the external source for configuration
file options or the full configuration file.
__exec
Allows users to specify a shell or terminal command as the external source for
configuration file options or the full configuration file.

For complete documentation, see Externally Sourced Configuration File Values.


OUTPUTCONFIG OPTION¶

MongoDB 4.2 adds the --outputConfig option for mongod and mongos. The option
outputs to stdout the mongod/mongos instance's configuration, in YAML format.

If the configuration uses any Externally Sourced Configuration File Values, the
option returns the resolved value for those options.

Warning

This may include any configured passwords or secrets previously obfuscated
through the external source.

For usage examples, see:

 * Output the Configuration File with Resolved Expansion Directive Values
 * Convert Command-Line Options to YAML


REMOVE INDEX KEY SIZE LIMIT¶

Starting in MongoDB 4.2, for featureCompatibilityVersion set to "4.2" or
greater, MongoDB removes the Index Key Limit. For fCV set to "4.0", the limit
still applies.

Tip
See also:

4.2 Indexes Compatibility Changes


REMOVE INDEX NAME LENGTH LIMIT¶

Starting in version 4.2, for featureCompatibilityVersion set to "4.2" or
greater, MongoDB removes the Index Name Length limit of 127 byte maximum. In
previous versions or MongoDB versions with featureCompatibilityVersion (fCV) set
to "4.0", index names must fall within the limit.

Tip
See also:
 * 4.2 Indexes Compatibility Changes
 * 4.2 Feature Compatibility


IMPROVEMENTS TO DROPINDEXES¶

DROP MULTIPLE INDEXES¶

Starting in MongoDB 4.2, you can specify multiple indexes to the dropIndexes
command and its mongo shell helper db.collection.dropIndexes(). To specify
multiple indexes to drop, pass an array of index names to
dropIndexes/db.collection.dropIndexes().

KILL RELATED QUERIES ONLY¶

Starting in MongoDB 4.2, the dropIndexes or its shell helpers dropIndex() and
dropIndexes() operation only kills queries that are using the index being
dropped. This may include queries considering the index as part of query
planning.

Prior to MongoDB 4.2, dropping an index on a collection would kill all open
queries on the collection.


ZSTD AVAILABILITY¶

Starting in version 4.2, MongoDB supports zstd for:

 * block compression. See storage.wiredTiger.collectionConfig.blockCompressor.
 * journal compression. See storage.wiredTiger.engineConfig.journalCompressor.

 * network compression. See net.compression.compressors.
   
   * For clients using the MongoDB drivers, they must use drivers updated for
     MongoDB 4.2.
   * The network compressors for mongod and mongos default to both
     snappy,zstd,zlib compressors, in that order. In version 4.0, mongod and
     mongos enable network compression by default with snappy as the compressor.


BULKWRITE() ERROR HANDLING INSIDE TRANSACTIONS¶

Starting in MongoDB 4.2, if a db.collection.bulkWrite() operation encounters an
error inside a transaction, the method throws a BulkWriteException (same as
outside a transaction).

In 4.0, if the bulkWrite operation encounters an error inside a transaction, the
error thrown is not wrapped as a BulkWriteException.

Inside a transaction, the first error in a bulk write causes the entire bulk
write to fail and aborts the transaction, even if the bulk write is unordered.


QUERY PLAN IMPROVEMENTS¶


PLAN CACHE STATES¶

Starting in MongoDB 4.2, the cache entry is associated with a state:

 * Missing
 * Inactive
 * Active

Associating states with entries helps reduce the likelihood that sub-optimal
cache entries remain in the cache. For more information, see Query Plans.


QUERYHASH AND PLANCACHEKEY¶

 * queryHashTo help identify slow queries with the same query shape, starting in
   MongoDB 4.2, each query shape is associated with a queryHash. The queryHash
   is a hexadecimal string that represents a hash of the query shape and is
   dependent only on the query shape.
   Note
   As with any hash function, two different query shapes may result in the same
   hash value. However, the occurrence of hash collisions between different
   query shapes is unlikely.
 * planCacheKey
   
   To provide more insight into the query plan cache, MongoDB 4.2 introduces the
   planCacheKey.
   
   planCacheKey is a hash of the key for the plan cache entry associated with
   the query.
   
   Note
   
   Unlike the queryHash, the planCacheKey is a function of both the query shape
   and the currently available indexes for the shape. That is, if indexes that
   can support the query shape are added/dropped, the planCacheKey value may
   change whereas the queryHash value would not change.
   
   Tip
   See also:
   
   planCacheKey

 * The queryHash and planCacheKey are available in:
   
   * profiler entry fields queryHash and planCacheKey the logged query
     operations.
   * diagnostic log messages (i.e. mongod/mongos log messages) for the logged
     query operations.
   * explain() output fields: queryHash and planCacheKey

The fields are also available in operations that return information about the
query plan cache:

 * $planCacheStats aggregation stage (New in MongoDB 4.2)
 * PlanCache.listQueryShapes() method/planCacheListQueryShapes command
   (Deprecated in MongoDB 4.2)
 * PlanCache.getPlansByQuery() method/planCacheListPlans command (Deprecated in
   MongoDB 4.2)

Tip
See also:

Deprecated Plan Cache Commands/Methods


$REGEX AND $NOT¶

Starting in MongoDB 4.2 (and 4.0.7), $not operator can perform logical NOT
operation on $regex operator expressions as well as on regular expression
objects (i.e. /pattern/).

In 4.0 and earlier versions, you could use $not operator with regular expression
objects (i.e. /pattern/) but not with $regex operator expressions.


KILL OWN CURSORS¶

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 starting in MongoDB 4.2.

In MongoDB 4.0, users required the killCursors privilege in order to kill their
own cursors.


NEW PARAMETERS¶

MongoDB 4.2 adds the parameter replBatchLimitBytes to configure the maximum
oplog application batch size. The parameter is also available starting in
MongoDB 4.0.10.


RETRYABLE WRITES ON CERTAIN SINGLE-DOCUMENT UPSERTS¶

MongoDB 4.2 will retry certain single-document upserts (update with upsert: true
and multi: false) that encounter a duplicate key exception. See Duplicate Key
Errors on Upsert for conditions.

Prior to MongoDB 4.2, MongoDB would not retry upsert operations that encountered
a duplicate key error.


DB.DROPDATABASE() AND WRITE CONCERN¶

Starting in MongODB 4.2, the mongo shell method db.dropDatabase() can take an
optional write concern document.


DROPCONNECTIONS¶

The dropConnections command drops the mongod/mongos instance's outgoing
connections to the specified hosts. The dropConnections must be run against the
admin database.


CLIENT DISCONNECTION¶

For the following operations, if the issuing client disconnects before the
operation completes, MongoDB marks the following operations for termination
(e.g. killOp on the operation):

Command
mongo Shell Method
Notes
aggregate
db.collection.aggregate()
Behavior only applies if the pipeline does not include $out and $merge
authenticate
db.auth()

count
db.collection.count()
db.collection.countDocuments()
db.collection.estimatedDocumentCount()

distinct
db.collection.distinct()

find
db.collection.find()
db.collection.findOne()

getnonce


isMaster


listCollections
db.getCollectionInfos()
db.getCollectionNames()

listDatabases


listIndexes
db.collection.getIndexes()



STARTUP WARNINGS¶

IN-MEMORY STORAGE ENGINES¶

Starting in version 4.2 (and 4.0.13 and 3.6.14 ), if a replica set member uses
the in-memory storage engine (voting or non-voting) but the replica set has
writeConcernMajorityJournalDefault set to true, the replica set member logs a
startup warning.

MONGO SHELL¶

Starting in MongoDB 4.2 (and 4.0.13), the mongo shell displays a warning message
when connected to non-genuine MongoDB instances as these instances may behave
differently from the official MongoDB instances; e.g. missing or incomplete
features, different feature behaviors, etc.


MAP-REDUCE¶

Starting in version 4.2, MongoDB deprecates:

 * The map-reduce option to create a new sharded collection as well as the use
   of the sharded option for map-reduce. To output to a sharded collection,
   create the sharded collection first. MongoDB 4.2 also deprecates the
   replacement of an existing sharded collection.
 * The explicit specification of nonAtomic: false option.


ROLLBACK TIME LIMIT¶

Starting in MongoDB 4.2, the rollback time limit is calculated between the first
operation after the common point and the last point in the oplog for the member
to roll back.

In MongoDB 4.0, the rollback time limit is calculated between the common point
and the last point in the oplog for the member to roll back.

For more information, see Rollback Elapsed Time Limitations.


ISINTERACTIVE()¶

MongoDB 4.2 adds a new mongo shell method isInteractive() that returns a boolean
indicating whether the mongo shell is running in interactive or script mode.


CHANGE TO EXPLAIN OUTPUT¶

Starting in MongoDB 4.2, the explain output can include a new optimizedPipeline
field. For details, refer to optimizedPipeline.


CHANGE TO ISMASTER OUTPUT¶

Starting in MongoDB 4.2, the output for isMaster, and the db.isMaster() helper
method, returns the isMaster.connectionId for the mongod/mongos instance's
connection to the client.


OPTIMIZED INDEX BUILDS¶

MongoDB index builds against a populated collection require an exclusive
read-write lock against the collection. Operations that require a read or write
lock on the collection must wait until the mongod releases the lock. MongoDB
uses an optimized build process that only holds the exclusive lock at the
beginning and end of the index build. The rest of the build process yields to
interleaving read and write operations.

For feature compatibility version (fcv) 4.2, MongoDB 4.2 index builds fully
replace the index build processes supported in previous MongoDB versions.
MongoDB ignores the background index build option if specified to createIndexes
or its shell helpers createIndex() and createIndexes().

Note
Requires featureCompatibilityVersion 4.2

For MongoDB clusters upgraded from 4.0 to 4.2, you must set the feature
compatibility version (fcv) to 4.2 to enable the optimized build process. For
more information on setting the fCV, see setFeatureCompatibilityVersion.

MongoDB 4.2 clusters running with fCV 4.0 only support 4.0 index builds.

For complete documentation on the index build process, see Index Builds on
Populated Collections.


CHANGES AFFECTING COMPATIBILITY¶

Some changes can affect compatibility and may require user actions. For a
detailed list of compatibility changes, see Compatibility Changes in MongoDB
4.2.


UPGRADE PROCEDURES¶

Important
Feature Compatibility Version

To upgrade, the 4.0 instances must have featureCompatibilityVersion set to 4.0.
To check the version:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )



For specific details on verifying and setting the featureCompatibilityVersion as
well as information on other prerequisites/considerations for upgrades, refer to
the individual upgrade instructions:

 * Upgrade a Standalone to 4.2
 * Upgrade a Replica Set to 4.2
 * Upgrade a Sharded Cluster to 4.2

If you need guidance on upgrading to 4.2, MongoDB offers major version upgrade
services to help ensure a smooth transition without interruption to your MongoDB
application.


DOWNLOAD¶

To download MongoDB 4.2, go to the MongoDB Download Center

Tip
See also:

All Third Party License Notices.


KNOWN ISSUES¶

In Version
Issues
Status
4.2.0
SERVER-43075: Missing storage.journal.commitIntervalMs
Fixed in 4.2.1


REPORT AN ISSUE¶

To report an issue, see https://github.com/mongodb/mongo/wiki/Submit-Bug-Reports
for instructions on how to file a JIRA ticket for the MongoDB server or one of
the related projects.

←  4.4 ChangelogCompatibility Changes in MongoDB 4.2 →

On this page

 * Minor Releases
 * Distributed Transactions
 * Removed MMAPv1 Storage Engine
 * Removed Commands and Methods
 * MongoDB Drivers
 * Sharded Clusters
 * Security Improvements
 * Aggregation Improvements
 * Change Stream
 * Update Enhancements
 * Wildcard Indexes
 * Platform Support
 * MongoDB Tools
 * Monitoring
 * Flow Control
 * Logging and Diagnostics
 * General Improvements
 * Query Plan Improvements
 * Optimized Index Builds
 * Changes Affecting Compatibility
 * Upgrade Procedures
 * Download
 * Known Issues
 * Report an Issue

Give Feedback
© 2021 MongoDB, Inc.

About

 * Careers
 * Legal Notices
 * Privacy Notices
 * Security Information
 * Trust Center

Support

 * Contact Us
 * Customer Portal
 * Atlas Status
 * Paid Support

Social

 * Github
 * Stack Overflow
 * LinkedIn
 * Youtube
 * Twitter
 * Twitch
 * Facebook

© 2021 MongoDB, Inc.




PRIVACY PREFERENCE CENTER

"Cookies" are small files that enable us to store information while you visit
one of our websites. When you visit any website, it may store or retrieve
information on your browser, mostly in the form of cookies. This information
might be about you, your preferences or your device and is mostly used to make
the site work as you expect it to. The information does not usually directly
identify you, but it can give you a more personalized web experience. Because we
respect your right to privacy, you can choose not to allow some types of
cookies, but essential cookies are always enabled. Click on the different
category headings to find out more and change our default settings. However,
blocking some types of cookies may impact your experience of the site and the
services we are able to offer.
MongoDB Privacy Policy
Allow All


MANAGE CONSENT PREFERENCES

STRICTLY NECESSARY COOKIES

Always Active

These cookies are necessary for the website to function and cannot be switched
off in our systems. They are usually only set in response to actions made by you
which amount to a request for services, such as setting your privacy
preferences, logging in or filling in forms. You can set your browser to block
or alert you about these cookies, but some parts of the site will not then work.
These cookies do not store any personally identifiable information.

PERFORMANCE COOKIES

Performance Cookies

These cookies allow us to count visits and traffic sources so we can measure and
improve the performance of our site. They help us to know which pages are the
most and least popular and see how visitors move around the site. All
information these cookies collect is aggregated and therefore anonymous. If you
do not allow these cookies we will not know when you have visited our site, and
will not be able to monitor its performance.

FUNCTIONAL COOKIES

Functional Cookies

These cookies enable the website to provide enhanced functionality and
personalisation. They may be set by us or by third party providers whose
services we have added to our pages. If you do not allow these cookies then some
or all of these services may not function properly.

TARGETING COOKIES

Targeting Cookies

These cookies may be set through our site by our advertising partners. They may
be used by those companies to build a profile of your interests and show you
relevant adverts on other sites. They do not store directly personal
information, but are based on uniquely identifying your browser and internet
device. If you do not allow these cookies, you will experience less targeted
advertising.

SOCIAL MEDIA COOKIES

Social Media Cookies

These cookies are set by a range of social media services that we have added to
the site to enable you to share our content with your friends and networks. They
are capable of tracking your browser across other sites and building up a
profile of your interests. This may impact the content and messages you see on
other websites you visit. If you do not allow these cookies you may not be able
to use or see these sharing tools.


BACK BUTTON PERFORMANCE COOKIES



Vendor Search Search Icon
Filter Icon

Clear
checkbox label label
Apply Cancel
Consent Leg.Interest
checkbox label label
checkbox label label
checkbox label label

Confirm My Choices


By clicking "Accept All Cookies", you agree to the storing of cookies on your
device to enhance site navigation, analyze site usage, and assist in our
marketing efforts. You can enable and disable optional cookies as desired. Read
our Privacy Policy. Read our Privacy Policy

Manage Cookies Accept All Cookies