Release Notes for MongoDB 4.2¶

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¶

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

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

MMAPv1 Specific Configuration Options¶

MongoDB removes the following MMAPv1 specific configuration options:

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

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.

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.

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. Before MongoDB 4.2, 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 Connection Pool¶

Starting in MongoDB 4.2, MongoDB adds the parameter ShardingTaskExecutorPoolReplicaSetMatching that determines the minimum size (can vary during runtime) of the mongos instance’s connection pools to each member of the sharded cluster.

By default, for each replica set in the sharded cluster (i.e. shard replica set and config servers), mongos maintains connection pools to each replica set secondary that are at least equal to the size of its connection pool to the primary.

To modify, see ShardingTaskExecutorPoolReplicaSetMatching.

Sharded Collections and Replace Documents¶

Starting in MongoDB 4.2,

• Replace document operations, such as db.collection.replaceOne() or db.collection.update( query, replacement, … ), attempt to target a single shard, first 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, the operation attempts 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.

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.

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

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 Backup

  Starting 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 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

Enterprise Feature

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

Official MongoDB 4.2-compatible drivers and the MongoDB 4.2 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.

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.

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:

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 Variables¶

MongoDB 4.2 adds the following new aggregation pipeline variables:

Availability¶

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

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.

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.

Update and Aggregation¶

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

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,

• Replace document operations, such as db.collection.replaceOne() or db.collection.update( query, replacement, … ), attempt to target a single shard, first 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, the operation attempts 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.

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 command-line 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 command-line 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:

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

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¶

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:

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.

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:

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:

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.

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:

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.

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.

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.

Improvements to dropIndexes¶

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.

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¶

• queryHash

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

  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)

$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):

Startup Warnings¶

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 connectionId for the mongod/mongos instance’s connection to the client.