Navigation

Release Notes for MongoDB 4.0

Note

Database clusters hosted on MongoDB Atlas can be automatically upgraded to the latest versions of MongoDB with no downtime using automated rolling upgrades. Create a free cluster.

Minor Releases

4.0.2 - Aug 29, 2018

Issues fixed:

4.0.1 - Aug 6, 2018

Issues fixed:

Multi-Document Transactions

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

Feature Compatibility

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.

mongo Shell Methods

Method Description
Session.startTransaction() Starts a multi-statement transaction.
Session.commitTransaction() Commits the transaction.
Session.abortTransaction() Aborts the transaction.

MongoDB Drivers

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

Read Concern snapshot

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

Read Preference

Multi-document transactions that contain read operations must use read preference primary.

All operations in a given transaction must route to the same member.

Commands

Locks

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.

$currentOp

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.

Parameters

Aggregation

New Type Conversion Operators

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

Operator Description
$convert Convert value to specified type.
$toBool Convert value to boolean.
$toDate Convert value to Date.
$toDecimal Convert value to Decimal128.
$toDouble Convert value to Double.
$toInt Convert value to integer.
$toLong Convert value to long.
$toObjectId Convert value to ObjectId.
$toString Convert value to string.

New String Operators

MongoDB 4.0 adds the following new aggregation string operators:

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

Additional Improvements

$bucket

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

$dateToString

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.

$dateFromParts

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.

$dateFromString

The $dateFromString aggregation operator takes an optional format field.

$currentOp

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.

MongoDB Drivers

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

PHPC 1.5.0

Scala 2.4.0

Security

Add Support for SCRAM-SHA-256

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.

New Option for Create and Update User Operations

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:

Command Method
createUser db.createUser()
updateUser db.updateUser()

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.

New Option for isMaster Command

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.

Remove Support for MONGODB-CR

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.

usersInfo Enhancement

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.

TLS/SSL

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

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.

TLS 1.2 Support

MongoDB 4.0 binaries for macOS support TLS 1.2.

Disable TLS 1.0

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.

AES-GCM

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

New Privilege Actions

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.

x.509 Authentication Certificate Restrictions

Starting in MongoDB 4.0, if you specify --sslAllowInvalidCertificates or ssl.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.

Enable System Store for TLS/SSL on Windows and macOS

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 and mongos to use system TLS/SSL certificate stores for Windows and macOS when using TLS/SSL connection to the KMIP server.

Deprecate MMAPv1

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:

Replica Set

Remove pv0 for Replica Sets

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.

Remove Master-Slave Replication

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 your master-slave replication, see Convert a Master-Slave Deployment to a Replica Set.

Journaling and Replica Sets

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.

rollbackTimeLimitSecs Parameter Available

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.

Wait for Background Index Builds

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

Rollback Files

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

replSetGetStatus Output Changes

The replSetGetStatus returns the following new fields:

The following fields returned from replSetGetStatus are deprecated:

Oplog Size

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

Change Streams

Database and Deployment Change Streams

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.

Start Time Option

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

Change Event Document Changes

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.

Resume Token Data Type Change

If the featureCompatibilityVersion (fcv) is set to "4.0" or greater, newly opened change streams return a hex-encoded string for the resume token data, i.e. the _id._data value. This change allows for the ability to compare and sort the resume tokens. If the fcv is 3.6, newly opened change streams return a BinData for the resume token data.

Important

The fcv value at the time of the cursor’s opening determine the resume token data type. That is, the modification of the fcv does not affect the resume tokens for change streams already opened before the fcv change.

Regardless of the fcv value, a 4.0 replica set or a sharded cluster can resume a change stream using either the BinData or string resume token.

As such, a 4.0 deployment can use a resume token from a change stream opened on a collection from a 3.6 deployment.

A 3.6 deployment can 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 a string resume token returned from a change stream opened against a collection from a deployment with fcv 4.0.

mongo Shell Methods

Method Description
db.watch()

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.

Mongo.watch()

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.

Free Monitoring

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

Enable/Disable

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

mongo Shell Methods Command
setFreeMonitoring

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

View Status

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

mongo Shell Methods Command
db.getFreeMonitoringStatus() getFreeMonitoringStatus

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

Access Control

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.

Sharded Clusters

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

Command Method Note
addShard sh.addShard()  
create db.createCollection()  
drop db.collection.drop()  
dropDatabase db.dropDatabase() Changed in MongoDB 3.6
enableSharding sh.enableSharding()  
movePrimary    
renameCollection db.collection.renameCollection()  
shardCollection sh.shardCollection()  
removeShard    
setFeatureCompatibilityVersion    

.msi Installer on Windows

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

Platform Support

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

General Improvements

Commands

  • The command listCollections takes Intent Shared lock on the database. In previous versions, the command takes Shared lock on the database.
  • The command listCollections and its mongo shell helper db.getCollectionInfos() accepts the following option:
    • nameOnly to return only the collection names and types (which does not require collection locks).
    • authorizedCollections to allow users without the required privilege to run listCollections can run the command, with nameOnly: true, authorizedCollections: true, to return the the collection(s) to which the user has privileges.
  • The command serverStatus and its mongo shell helper db.serverStatus() includes shardingStatistics in its output. The shardingStatistics includes data on metadata refresh on sharded clusters.
  • The mongo shell helper db.collection.drop() accepts the write concern option.
  • For cursors created inside a session, you cannot call getMore outside the session. Similarly, for cursors created outside of a session, you cannot call getMore inside a session.
  • The command dbHash includes the following fields in its output:
    • capped field that lists the capped collections
    • uuids field that contains the collections and their corresponding UUIDs.
  • The command killOp now supports termination of queries that are running on a mongos. When run on the mongos, killOp can kill queries that are running in more than one shard.

Geospatial Query Improvements

  • The geospatial query operators $near and $nearSphere now supports querying on sharded collections.
  • As of MongoDB 4.0, the $geoNear aggregation operator and geoNear command support using the minDistance option with 2d indexes. Similarly, $near and $nearSphere support the $minDistance option for 2d indexes. Previously, minDistance and $minDistance were only available for 2dsphere indexes.
  • MongoDB 4.0 adds a key option for the $geoNear aggregation operator and geoNear command that enables users to specify which geospatial index to use when querying a collection with multiple geospatial indexes. Previously, to use the $geoNear aggregation operator or geoNear command, the collection could only have one geospatial index.

Network Layer Improvements

Configuration Options

Miscellaneous

  • The JavaScript engine’s JIT compiler is now disabled by default.
  • Upgrades MozJS to ESR 45.9.0.
  • Adds RECOVERY component to log messages.
  • MongoDB 4.0 adds support for using the appName connection string option for setting a custom app name when connecting from the mongo shell. Previously, only MongoDB drivers supported using the appName to set a custom value and the mongo shell used the default MongoDB Shell value as the app name.
  • Adds a mongo shell method convertShardKeyToHashed to return the hashed value for a document.
  • Resolves localhost IP address as configured instead of assuming 127.0.0.1.
  • When using the DNS Seedlist Connection Format to connect to the mongo shell with authentication, the mongo shell will now prompt the user to provide their password when starting up.

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

Upgrade Procedures

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.

Download

To download MongoDB 4.0, go to the MongoDB Download Center

Known Issues in 4.0.2

  • WT-4018:

    MongoDB 4.0 may lose data during unclean shutdowns on macOS 10.13+.

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

Known Issues in 4.0.1

  • WT-4018:

    MongoDB 4.0 may lose data during unclean shutdowns on macOS 10.13+.

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

Known Issues in 4.0.0

  • 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.13+.

  • 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

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.