Docs Menu
Docs Home
/
MongoDB Manual
/
Release Notes

Release Notes for MongoDB 4.0

On this page

  • Patch Releases
  • Multi-Document Transactions
  • Aggregation
  • MongoDB Drivers
  • Security
  • Deprecate MMAPv1
  • Replica Set
  • Change Streams
  • Free Monitoring
  • Sharded Clusters
  • .msi Installer on Windows
  • Platform Support
  • MongoDB Tools
  • General Improvements
  • Changes Affecting Compatibility
  • Upgrade Procedures
  • Download
  • Known Issues in 4.0.3
  • Known Issues in 4.0.2
  • Known Issues in 4.0.1
  • Known Issues in 4.0.0
  • Report an Issue

Patch Releases

4.0.28 - January 31, 2022

Issues fixed:

  • SERVER-62065 Upgrade path from 3.6 to 4.0 can leave chunk entries without history on the shards

  • SERVER-55648 Mongos doesn't return top-level batch-write error in case of shutdown

  • SERVER-54064 Sessions on arbiters accumulate and cannot be cleared out

  • SERVER-53335 Queries, updates, and deletes with non-"simple" collations may miss documents when using hashed sharding

  • SERVER-45953 Exempt oplog readers from acquiring read tickets

  • All JIRA issues closed in 4.0.28

  • 4.0.28 Changelog

4.0.27 - Sep 13, 2021

Issues fixed:

4.0.26 - Jul 23, 2021

Issues fixed:

4.0.25 - Jun 10, 2021

Issues fixed:

4.0.24 - Apr 20, 2021

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

4.0.23 - Feb 22, 2021

Issues fixed:

4.0.22 - Jan 4, 2021

Issues fixed:

4.0.21 - Nov 10, 2020

Issues fixed:

4.0.20 - Aug 21, 2020

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

4.0.19 - Jun 15, 2020

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

4.0.18 - Apr 15, 2020

Issues fixed:

4.0.17 - Mar 25, 2020

Issues fixed:

4.0.16 - Feb 5, 2020

Issues fixed:

4.0.15 - Jan 27, 2020

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

4.0.14 - Dec 18, 2019

Issues fixed:

4.0.13 - Oct 19, 2019

Issues fixed:

4.0.12 - Aug 12, 2019

Issues fixed:

4.0.11 - Jul 26, 2019

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

4.0.10 - May 31, 2019

Issues fixed:

4.0.9 - Apr 16, 2019

Issues fixed:

Note

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

4.0.8 - Mar 29, 2019

Issues fixed:

4.0.7 - Mar 25, 2019

Issues fixed:

4.0.6 - Feb 7, 2019

Issues fixed:

4.0.5 - Dec 20, 2018

Issues fixed:

4.0.4 - Nov 8, 2018

Issues fixed:

4.0.3 - Oct 9, 2018

Issues fixed:

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

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
Starts a multi-statement transaction.
Commits the transaction.
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 Operations That Support Read Concern.

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

New String Operators

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.

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

  • PHP (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 Get 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

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

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.

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.

Tip

See also:

Enable System Store for TLS/SSL on Windows and macOS

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 any of the following x.509 authentication options, an invalid certificate is sufficient only to establish a TLS connection but it is insufficient for authentication:

  • --sslAllowInvalidCertificates or net.ssl.allowInvalidCertificates: true for MongoDB 4.0 and later

  • --tlsAllowInvalidCertificates or net.tls.allowInvalidCertificates: true for MongoDB 4.2 and later

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 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 from master-slave replication to a replica set, 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

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

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.

mongo Shell Methods

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.

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

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

The serverStatus and the helper db.serverStatus() 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" write concern for the following operations that affect the sharded cluster metadata:

Command
Method
Note
Changed in MongoDB 3.6

.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 Platform Support for the full platform support matrix.

MongoDB Tools

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.

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

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.

Download

To download MongoDB 4.0, go to the MongoDB Download Center

Tip

See also:

All Third Party License Notices.

Known Issues in 4.0.3

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

Known Issues in 4.0.2

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

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

Known Issues in 4.0.0

  • 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

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.

Back

4.2 Changelog