Navigation

Release Notes for MongoDB 4.0

On this page

Issues fixed:

Issues fixed:

Issues fixed:

  • 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-45836 Provide more LDAP details (like server IP) at default log level
  • SERVER-35649 Nodes removed due to isSelf failure should re-attempt to find themselves
  • WT-7028 Sweep thread shouldn't lock during checkpoint gathering handles
  • All JIRA issues closed in 4.0.24
  • 4.0.24 Changelog

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

  • 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-46758 setFCV can be interrupted before an FCV change is majority committed and rollback the FCV without running the setFCV server logicbumping collection's major version during split
  • SERVER-47799 AsyncRequestsSender should update replica set monitor in between retries for InterruptedAtShutdown
  • SERVER-49233 Introduce a flag to toggle the logic for bumping collection's major version during split
  • All JIRA issues closed in 4.0.20
  • 4.0.20 Changelog

Issues fixed:

  • SERVER-42525 Single-node replica sets shouldn't wait for electable caught up secondaries during shutdown
  • SERVER-42862 Prevent shard refreshes in mergeChunks command from joining earlier refreshes
  • SERVER-46487 The mongos routing for scatter/gather ops can have unbounded latency
  • SERVER-46758 setFCV can be interrupted before an FCV change is majority committed and rollback the FCV without running the setFCV server logic
  • SERVER-47233 WriteOp can be left in pending state, leading to erroneous NoProgressMade write error from mongos
  • All JIRA issues closed in 4.0.19
  • 4.0.19 Changelog

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

  • SERVER-42565: Aggregations and find commands sort missing fields differently
  • SERVER-44341: Do not choose only first shard of all shards associated with a zone when pre-splitting during shard collection
  • SERVER-40435: A clearJumboFlag command to clear the jumbo flag
  • SERVER-45309: Ensure bind credentials live longer than LDAP operations
  • SERVER-44733: Change stream should throw ChangeStreamFatalError if a single shard cannot be targeted for updateLookup
  • SERVER-45396: fix the "me" field in isMaster responses when using splithorizon
  • WT-5042: Reduce configuration parsing overhead from checkpoints
  • All JIRA issues closed in 4.0.15
  • 4.0.15 Changelog
Note

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

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

  • SERVER-39756: Sharding a very large collection can result in a long stall of writes against this collection
  • SERVER-40134: Distinct command against a view can return incorrect results when the distinct path is multikey
  • SERVER-40535: Possibility to get a non-existent key if using ReadConcern level:local when reading signing keys in ReplicaSet
  • SERVER-41361: Do not read at lastApplied while already holding the PBWM lock on secondaries
  • SERVER-41869: Reverse mutex acquisition order in CatalogCache::_scheduleCollectionRefresh
  • SERVER-42055: Only acquire a collection IX lock to write the lastVote document
  • SERVER-42232: Adding a new shard renders all preceding resume tokens invalid
  • All JIRA issues closed in 4.0.11
  • 4.0.11 Changelog
Note

Fixed issues include those that resolve the following Common Vulnerabilities and Exposures (CVEs):

Issues fixed:

Issues fixed:

Note

Fixed issues include those that resolve the following Common Vulnerabilities and Exposures (CVEs):

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Starting in version 4.0, MongoDB provides the ability to perform multi-document transactions against replica sets. With multi-document transactions, until a transaction commits, no write operations in the transaction are visible outside the transaction. That is, the multi-document transactions are atomic.

Important

In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transactions should not be a replacement for effective schema design. For many scenarios, the denormalized data model (embedded documents and arrays) will continue to be optimal for your data and use cases. That is, for many scenarios, modeling your data appropriately will minimize the need for multi-document transactions.

For additional transactions usage considerations (such as runtime limit and oplog size limit), see also Production Considerations.

The featureCompatibilityVersion of all members of the replica set must be 4.0 or greater. To check the featureCompatibilityVersion for a member, connect to the member and run the following command:

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

For more information on the featureCompatibilityVersion flag, see setFeatureCompatibilityVersion.

Method
Description
Starts a multi-statement transaction.
Commits the transaction.
Aborts the transaction.

Clients require MongoDB drivers updated for MongoDB 4.0 to use transactions.

MongoDB 4.0 introduces a new read concern level "snapshot" for multi-document transaction.

For a multi-document transaction, MongoDB may sometimes substitute a stronger read concern for "local" and "majority" read concern.

For a list of all operations that accept read concerns, see Operations That Support Read Concern.

Multi-document transactions that contain read operations must use read preference primary. All operations in a given transaction must route to the same member.

By default, multi-document transactions wait 5 milliseconds to acquire locks required by the operations in the transaction. If the transaction cannot acquire its required locks with the 5 milliseconds, the transaction aborts.

You can use the maxTransactionLockRequestTimeoutMillis parameter to adjust how long transactions wait to acquire locks.

Transactions release all locks upon abort or commit.

The aggregation pipeline stage $currentOp (and the currentOp command and mongo shell helper db.currentOp() method) return information on inactive sessions which are holding locks as part of a transaction.

MongoDB 4.0 adds the following new aggregation operators for type conversion:

Operator
Description
Convert value to specified type.
Convert value to boolean.
Convert value to Date.
Convert value to Decimal128.
Convert value to Double.
Convert value to integer.
Convert value to long.
Convert value to ObjectId.
Convert value to string.

MongoDB 4.0 adds the following new aggregation string operators:

Operator
Description
Removes whitespace or the specified characters from the beginning of a string.
Removes whitespace or the specified characters from the end of a string.
Removes whitespace or the specified characters from the beginning and end of a string.

The $bucket stage no longer requires boundaries document arguments to be wrapped in $literal.

The $dateToString aggregation operator has the following option changes:

Note

Requires featureCompatibilityVersion (fcv) set to "4.0" or greater.

  • A new option onNull specifies the value to return if the date is null or missing.
  • The option format is now optional.

If the value specified for fields other than year, isoYear, and timezone is outside the valid range, $dateFromParts carries or subtracts the difference from other date parts to calculate the date. For more information, see Value Range.

The $dateFromString aggregation operator takes an optional format field.

The aggregation pipeline stage $currentOp supports the following new options:

  • idleSessions option to return information on inactive sessions which are holding locks as part of a transaction.
  • localOps option to report operations that are running locally on the current mongos instance, rather than reporting operations that are running on the shards.

The following drivers are feature compatible with MongoDB 4.0:

  • Java 3.8.0
  • Python 3.7.0
  • C 1.11.0
  • C# 2.7
  • Node 3.1.0
  • Ruby 2.6.0
  • Perl 2.0.0
  • PHP (PHPC) 1.5.0
  • Scala 2.4.0
Note

To use SCRAM-SHA-256, the featureCompatibilityVersion must be set to 4.0. For more information on featureCompatibilityVersion, see View FeatureCompatibilityVersion and setFeatureCompatibilityVersion.

MongoDB adds support for SCRAM authentication mechanism SCRAM-SHA-256, which uses the SHA-256 hash function. To modify the iteration count for SCRAM-SHA-256, MongoDB adds a new parameter scramSHA256IterationCount.

When creating or updating a SCRAM user, you can indicate the specific SCRAM mechanism or mechanisms to use for the user credentials. Specifically, MongoDB 4.0 adds the mechanisms option to the following commands and mongo shell helpers:

When using SCRAM-SHA-256, MongoDB (i.e. the server) requires undigested password. Starting in MongoDB 4.0, the default value of digestPassword is true for createUser, and the default value of passwordDigestor is "server". In earlier MongoDB versions, digestPassword is false and client respectively.

Starting in MongoDB 4.0, the isMaster command accepts an optional field saslSupportedMechs: <db.user> to return an additional field isMaster.saslSupportedMechs in its result.

isMaster.saslSupportedMechs is an array of SASL mechanisms used to create the specified user's credentials.

Starting in version 4.0, MongoDB removes support for the deprecated MongoDB Challenge-Response (MONGODB-CR) authentication mechanism.

Since version 3.0, MongoDB has not supported the creation of MONGODB-CR users unless the deployment had been upgraded from a 2.6 or earlier deployment that already had MONGODB-CR users and had not upgraded the authentication schema.

If your deployment has user credentials stored in MONGODB-CR schema, you must upgrade to Salted Challenge Response Authentication Mechanism (SCRAM) before you upgrade to version 4.0. For information on upgrading to SCRAM, see Upgrade to SCRAM.

The usersInfo command can return information across all databases by specifying:

{ usersInfo: { forAllDBs: true } }

The usersInfo and the mongo shell helpers db.getUser() and db.getUsers() method accept a new optional filter document. The filter document specifies $match stage conditions to return information only for users that match the conditions.

The usersInfo command and the mongo shell helpers db.getUser() and db.getUsers() method return the mechanisms field for the user.

Starting in version 4.0, MongoDB uses the native TLS/SSL OS libraries:

Platform
TLS/SSL Library
Windows
Secure Channel (Schannel)
Linux/BSD
OpenSSL
macOS
Secure Transport

Associated with this change, the parameter opensslCipherConfig is supported for Linux/BSD and no longer supported in Windows and macOS.

MongoDB 4.0 binaries for macOS support TLS 1.2.

MongoDB binaries (mongod, mongos, and mongo) disables support for TLS 1.0 encryption on systems where TLS 1.1+ is available.

If you need to support TLS 1.0:

On macOS, to connect mongo shell version 3.6.4 or earlier to a MongoDB 4.0+ deployment requires explicit enabling of TLS 1.0.

MongoDB Enterprise on Windows no longer supports AES256-GCM. This cipher is now available only on Linux.

Tip
See also:

To support free Cloud monitoring, MongoDB adds the following privilege actions available for the cluster resource:

MongoDB modifies the clusterMonitor role to include these privileges.

Starting in MongoDB 4.0, if you specify --sslAllowInvalidCertificates or net.ssl.allowInvalidCertificates: true (or in MongoDB 4.2, the alias --tlsAllowInvalidateCertificates or net.tls.allowInvalidCertificates: true) when using x.509 authentication, an invalid certificate is only sufficient to establish a TLS/SSL connection but is insufficient for authentication.

If you are using invalid certificates to perform x.509 authentication, update your certificates to valid certificates. For example, you may sign your existing certificates with a trusted CA, or if using a custom CA, specify that CA using net.ssl.CAFile.

The --sslCertificateSelector option (certificateSelector setting) allows mongod, mongo shell and mongos to use system SSL certificate stores for Windows and macOS.

The --sslClusterCertificateSelector option (clusterCertificateSelector setting) allows mongod and mongos to use system TLS/SSL certificate stores for Windows and macOS for internal TLS/SSL communication within a cluster.

The option --kmipClientCertificateSelector (security.kmip.clientCertificateSelector) allows mongod to use system TLS/SSL certificate stores for Windows and macOS when using TLS/SSL connection to the KMIP server.

Starting in version 4.0, MongoDB deprecates the MMAPv1 storage Engine and will remove MMAPv1 in a future release.

To change your MMAPv1 storage engine deployment to WiredTiger Storage Engine, see:

MongoDB 4.0 removes the deprecated replica set protocol version 0 pv0.

Before upgrading to MongoDB 4.0, you must upgrade to pv1.

To upgrade to pv1, connect a mongo shell to the replica set primary and perform the following sequence of operations:

cfg = rs.conf();
cfg.protocolVersion=1;
rs.reconfig(cfg);

You can use catchUpTimeoutMillis to prioritize between faster failovers and preservation of w:1 writes.

For more information on pv1, see Replica Set Protocol Version.

MongoDB 4.0 removes support for the deprecated master-slave replication. Before you can upgrade to MongoDB 4.0, if your deployment uses master-slave replication, you must upgrade to a replica set.

To convert from master-slave replication to a replica set, see Convert a Master-Slave Deployment to a Replica Set.

Starting in MongoDB 4.0, you cannot specify --nojournal option or storage.journal.enabled: false for replica set members that use the WiredTiger storage engine.

Starting in MongoDB 4.0, a new rollbackTimeLimitSecs parameter allows for the setting of the time limit in seconds between the common point and the last oplog write entry for the member indicated for rollback. The default rollback time limit is 1 day.

Starting in version 4.0, MongoDB waits for any in-progress background index builds to finish before starting a rollback.

MongoDB adds the parameter createRollbackDataFiles that determines whether during a rollback, MongoDB creates rollback files that contains documents affected during the rollback.

The replSetGetStatus returns the following new fields:

The following fields returned from replSetGetStatus are deprecated:

Starting in MongoDB 4.0, the oplog can grow past its configured size limit to avoid deleting the majority commit point.

MongoDB adds the ability to:

  • Open a change stream cursor for a single database (excluding admin, local, and config database) to watch for changes to all its non-system collections.
  • Open a change stream cursor for a deployment to watch for changes to all non-system collections across all databases except for admin, local, and config.
Note

Requires featureCompatibilityVersion (fcv) set to "4.0" or greater.

MongoDB adds the ability to specify a start time (startAtOperationTime option) for a change stream.

The change event documents include the new fields:

  • the clusterTime which corresponds to timestamp from the oplog entry for the event.
  • the txnNumber and the lsid if the operation is part of a multi-document transaction.

MongoDB 4.0 introduces new hex-encoded string change streams resume tokens:

The resume token _data type depends on the MongoDB versions and, in some cases, the feature compatibility version (fcv) at the time of the change stream's opening/resumption (i.e. a change in fcv value does not affect the resume tokens for already opened change streams):

MongoDB Version
Feature Compatibility Version
Resume Token _data Type
MongoDB 4.0.7 and later
"4.0" or "3.6"
Hex-encoded string (v1)
MongoDB 4.0.6 and earlier
"4.0"
Hex-encoded string (v0)
MongoDB 4.0.6 and earlier
"3.6"
BinData
MongoDB 3.6
"3.6"
BinData

With hex-encoded string resume tokens, you can compare and sort the resume tokens.

Regardless of the fcv value, a 4.0 deployment can use either BinData resume tokens or hex string resume tokens to resume a change stream. As such, a 4.0 deployment can use a resume token from a change stream opened on a collection from a 3.6 deployment.

New resume token formats introduced in a MongoDB version cannot be consumed by earlier MongoDB versions.

A 3.6 deployment can, however, use the BinData resume token returned from a change stream opened against a collection from a deployment with fcv 3.6. However, a 3.6 deployment cannot use the hex-encoded string resume tokens.

Method
Description

Opens a change stream cursor for a single database (excluding admin, local, and config database) to watch for changes to all its non-system collections.

For the corresponding MongoDB driver method, refer to your driver documentation.

Opens a change stream cursor for a deployment to watch for changes to all non-system collections across all databases except for admin, local, and config.

For the corresponding MongoDB driver method, refer to your driver documentation.

New in version 4.0.

MongoDB 4.0 (Community Edition) offers free Cloud monitoring for standalone or replica sets.

By default, you can enable/disable free monitoring during runtime using:

mongo Shell Methods
Command

You can also enable or disable free monitoring at startup using either:

To view the state of your free monitoring, MongoDB provides the following command and shell helper:

The serverStatus and the helper db.serverStatus() also includes free monitoring statistics in the freeMonitoring field.

To support free Cloud monitoring, MongoDB adds the following privilege actions available for the cluster resource:

The built-in role clusterMonitor includes the new privilege actions.

mongos uses "majority" write concern for the following operations that affect the sharded cluster metadata:

Starting in MongoDB 4.0, you can configure and start MongoDB as a service during the install.

  • MongoDB 4.0 (Community & Enterprise) adds support for:

  • MongoDB 4.0 (Community) adds support for:

    • s390x RHEL 6.x
  • MongoDB 4.0 does not support SLES 11.

    • Support for SLES 11 has also been removed in MongoDB 3.2.20+, 3.4.15+, and 3.6.4+.
  • MongoDB 4.0 does not support Ubuntu 12.04.

    • Support for Ubuntu 12.04 has also been removed in MongoDB 3.2.20+, 3.4.15+, and 3.6.4+.
    • Support for Ubuntu 12.04 has also been removed in MongoDB 3.2.20+, 3.4.15+, and 3.6.4+.
  • In future releases, MongoDB will end support for the following platforms:

    • Windows 7/2008R2
    • Windows 8/2012
    • Windows 8.1/2012R2
    • Ubuntu 14.04

Refer to Supported Platforms for the full platform support matrix.

The mongoreplay play command supports a new MONGOREPLAY_HOST environment variable that specifies the MongoDB connection string when running mongoreplay play. The new environment variable can be usedinstead of the command-line --host option.

For example, to play back a recording to a mongod instance running with authentication at mongodb1.example.net:27017, you can specify the connection string in:

  • The MONGOREPLAY_HOST environment variable:

    export MONGOREPLAY_HOST="mongodb://myUserName:s0meD1fficultPassw0rd@mongodb1.example.net:27017/?authSource=admin"
    mongoreplay play -p /some/path/to/my/recording.bson
  • The --host command-line option:

    mongoreplay play -p /some/path/to/my/recording.bson --host "mongodb://myUserName:s0meD1fficultPassw0rd@mongodb1.example.net:27017/?authSource=admin"

If --host command-line option is specified, the --host value overrides the environment variable.

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

Important
Feature Compatibility Version

To upgrade, the 3.6 instances must have featureCompatibilityVersion set to 3.6. 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:

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

To download MongoDB 4.0, go to the MongoDB Download Center

  • WT-4018:
    MongoDB 4.0 may lose data during unclean shutdowns on macOS 10.12.x, 10.13.x, and 10.14.0. This issue was fixed by Apple in macOS 10.14.1.
  • SERVER-35431:
    After a rollback, the 'dataSize' field reported in collStats and dbStats output can be inaccurate.
  • WT-4018:
    MongoDB 4.0 may lose data during unclean shutdowns on macOS 10.12.x, 10.13.x, and 10.14.0. This issue was fixed by Apple in macOS 10.14.1.
  • SERVER-35431:
    After a rollback, the 'dataSize' field reported in collStats and dbStats output can be inaccurate.
  • SERVER-35657:
    Using multi-document transactions with a single-member replica set may have significant performance impact. Single-member replica sets should only be for testing/development purposes and are not recommended for production use.
    Note
    Multi-document transactions performance on a single-member replica set are not indicative of performance on a replica set with more than one member.
  • WT-4018:
    MongoDB 4.0 may lose data during unclean shutdowns on macOS 10.12.x, 10.13.x, and 10.14.0. This issue was fixed by Apple in macOS 10.14.1.
  • SERVER-35431:
    After a rollback, the 'dataSize' field reported in collStats and dbStats output can be inaccurate.
  • SERVER-35657:
    Using multi-document transactions with a single-member replica set may have significant performance impact. Single-member replica sets should only be for testing/development purposes and are not recommended for production use.
    Note
    Multi-document transactions performance on a single-member replica set are not indicative of performance on a replica set with more than one member.
  • TOOLS-1952:
    Users running MongoDB 4.0 mongodump may experience slower performance compared to previous versions. Running mongodump with --forceTableScan may resolve performance issues.
  • TOOLS-2058:
    mongoreplay does not show insert/find commands for MongoDB 4.0.# Fixed in 4.0.1
  • WT-4018:
    MongoDB 4.0 may lose data during unclean shutdowns on macOS 10.12.x, 10.13.x, and 10.14.0. This issue was fixed by Apple in macOS 10.14.1.
  • SERVER-35431:
    After a rollback, the 'dataSize' field reported in collStats and dbStats output can be inaccurate.
  • SERVER-35657:
    Using multi-document transactions with a single-member replica set may have significant performance impact. Single-member replica sets should only be for testing/development purposes and are not recommended for production use.
    Note
    Multi-document transactions performance on a single-member replica set are not indicative of performance on a replica set with more than one member.
  • SERVER-35758:
    The shell prompt in the mongo shell will cause an error if you use the session associated with the global db object to run transactions.# Fixed in 4.0.1

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.

Give Feedback

On this page