Navigation

Release Notes for MongoDB 5.0

On this page

Note

MongoDB 5.0 Released Jul 13, 2021

Patch Releases

5.0.9 - May 31, 2022

Issues fixed:

5.0.8 - April 25, 2022

Issues fixed:

  • SERVER-63531 commitQuorum incorrectly includes buildIndexes:false nodes and error message incorrectly says that only voting nodes are eligible
  • SERVER-63387 1 StreamingCursor should return backup blocks in the order they were retrieved from the WiredTiger backup cursor
  • SERVER-62229 Fix invariant when applying index build entries while recoverFromOplogAsStandalone=true
  • SERVER-61879 Refreshes to recover migrations must never join ongoing refreshes
  • WT-8924 Don’t check against on disk time window if there is an insert list when checking for conflicts in row-store
  • All JIRA issues closed in 5.0.8
  • 5.0.8 Changelog

5.0.7 - April 11, 2022

Issues fixed:

5.0.6 - January 31, 2022

Issues fixed:

  • WT-8395 Inconsistent data after upgrade from 4.4.3 and 4.4.4 to 4.4.8+ and 5.0.2+
  • SERVER-62245 MigrationRecovery must not assume that only one migration needs to be recovered
  • SERVER-61427 Unique index builds can cause a loss of availability during commit due to checking many false duplicates
  • SERVER-61194 Prevent time-series bucket OID reuse with coarse granularity
  • SERVER-60310 OCSP response validation should not consider statuses of irrelevant certificates
  • All JIRA issues closed in 5.0.6
  • 5.0.6 Changelog

5.0.5 - December 6, 2021

Issues fixed:

  • SERVER-61483 Resharding coordinator fails to recover abort decision on step-up, attempts to commit operation as success, leading to data inconsistency
  • SERVER-59858 Add observability for tasks scheduled on the reactor thread
  • SERVER-51329 Unexpected non-retryable error when shutting down a mongos server
  • WT-8163 Consider more eviction scenarios to give up checkpoint-cleanup
  • WT-7912 Fix prefix search near optimisation to handle scenarios where the key range is split across pages.
  • All JIRA issues closed in 5.0.5
  • 5.0.5 Changelog

5.0.4 - Nov 15, 2021

Issues fixed:

5.0.3 - Sep 21, 2021

Issues fixed:

  • SERVER-57667: Improve processing speed for resharding’s collection cloning pipeline
  • SERVER-57630: Enable SSL_OP_NO_RENEGOTIATION on Ubuntu 18.04 when running against OpenSSL 1.1.1
  • WT-8005: Fix a prepare commit bug that could leave the history store entry unresolved
  • WT-7995: Fix the global visibility that it cannot go beyond checkpoint visibility
  • WT-7984: Fix a bug that could cause a checkpoint to omit a page of data
  • All JIRA issues closed in 5.0.3
  • 5.0.3 Changelog

5.0.2 - Aug 4, 2021

Warning

MongoDB version 5.0.2 is not recommended for production use due to critical issues WT-7984 and WT-7995, fixed in later versions. Use the latest available patch release version.

Issues fixed:

5.0.1 - Jul 22, 2021

Warning

MongoDB version 5.0.1 is not recommended for production use due to critical issues SERVER-58936, WT-7984, and WT-7995, fixed in later versions. Use the latest available patch release version.

Issues fixed:

5.0.0 - Jul 13, 2021

Warning

MongoDB version 5.0.0 is not recommended for production use due to critical issues SERVER-58936, WT-7984, and WT-7995, fixed in later versions. Use the latest available patch release version.

The rest of this page provides the 5.0.0 release notes:

Time Series Collections

MongoDB 5.0 introduces time series collections which efficiently store sequences of measurements over a period of time. Compared to normal collections, storing time series data in time series collections improves query efficiency and reduces disk usage for your data and indexes.

Aggregation

New Aggregation Operators

MongoDB 5.0 introduces the following aggregation operators:

Operator Description
$count

$count (aggregation accumulator) provides a count of all documents when used in the existing pipeline $group (aggregation) stage and the new MongoDB 5.0 $setWindowFields stage.

Note

Disambiguation

The $count (aggregation accumulator) is distinct from the $count (aggregation) pipeline stage.
$dateAdd Increments a Date object by a specified number of time units.
$dateDiff Returns the difference between two dates.
$dateSubtract Decrements a Date object by a specified number of time units.
$dateTrunc Truncates a date.
$getField Returns the value of a specified field from a document. You can use $getField to retrieve the value of fields with names that contain periods (.) or start with dollar signs ($).
$rand The $rand method generates a random float value between 0 and 1 each time it is called. The new $sampleRate operator is based on $rand. (Also added to MongoDB 4.4.2)
$sampleRate Adds the $sampleRate method to probabilistically select documents from a pipeline at a given rate.
$setField Adds, updates, or removes a specified field in a document. You can use $setField to add, update, or remove fields with names that contain periods (.) or start with dollar signs ($).
$unsetField Removes a specified field in a document. An alias for $setField to remove fields with names that contain periods (.) or that start with dollar signs ($).

Window Operators

MongoDB 5.0 introduces the $setWindowFields pipeline stage, allowing you to perform operations on a specified span of documents in a collection, known as a window. The operation returns the results based on the chosen window operator.

For example, you can use the $setWindowFields stage to output the:

  • Difference in sales between two documents in a collection.
  • Sales rankings.
  • Cumulative sales totals.
  • Analysis of complex time series information without exporting the data to an external database.

General Aggregation Improvements

$expr Operator: Comparison Operators Use Indexes

Starting in MongoDB 5.0, the $eq, $lt, $lte, $gt, and $gte operators placed in an $expr operator can use indexes to improve performance.

$ifNull Expression Accepts Multiple Input Expressions

Starting in MongoDB 5.0, you can specify multiple input expressions for the $ifNull expression before returning a replacement expression.

let Option for Aggregation

Starting in MongoDB 5.0, the aggregate command and db.collection.aggregate() helper method have a let option to specify a list of variables that can be used elsewhere in the aggregation pipeline. This allows you to improve command readability by separating the variables from the query text.

$lookup Stage: Concise Correlated Subqueries

Starting in MongoDB 5.0, an aggregation pipeline $lookup stage supports concise correlated subqueries that improve joins between collections.

$lookup Stage: Uncorrelated Subqueries

Starting in MongoDB 5.0, for an uncorrelated subquery in a $lookup pipeline stage containing a $sample stage, the $sampleRate operator, or the $rand operator, the subquery is always run again if repeated. Previously, depending on the subquery output size, either the subquery output was cached or the subquery was run again.

See Perform an Uncorrelated Subquery with $lookup.

Auditing

Runtime Audit Filter Configuration

MongoDB 5.0 adds the ability to configure auditing filters at runtime.

Operator Description
auditConfigPollingFrequencySecs Defines the polling interval for checking audit configuration
getAuditConfig Retrieves audit configurations from mongod and mongos.
setAuditConfig Sets new audit configurations for mongod and mongos instances at runtime.

General Auditing Updates

Starting in MongoDB 5.0:

Change Streams

Change Events Output

Starting in MongoDB 5.0, Change Events contain the field updateDescription.truncatedArrays to record array truncations.

Indexes

Partial Indexes Behavior Change

Starting in MongoDB 5.0, multiple partial indexes can be created using the same key pattern as long as the partialFilterExpression fields do not express equivalent filters.

In earlier versions of MongoDB, creating multiple partial indexes is not allowed when using the same key pattern with different partialFilterExpressions.

Unique Sparse Index Behavior Change

Starting in MongoDB 5.0, unique sparse and unique non-sparse indexes with the same key pattern can exist on a single collection.

See unique sparse index creation

Cannot Drop Ready Indexes During In-Progress Index Builds

The db.collection.dropIndexes() command cannot drop ready indexes if there are any in-progress index builds.

  • In versions 4.4.0-4.4.4 of MongoDB, this logic was not true due to a bug.

Foreground Validation May Fix Multikey Metadata Inconsistencies

When run on a MongoDB deployment, db.collection.validate() attempts to fix multikey metadata inconsistencies of standalone deployments.

Removal of geoHaystack Index and the geoSearch Command

MongoDB 5.0 removes the deprecated geoHaystack index and geoSearch command. Use a 2d index with $geoNear or one of the supported geospatial query operators instead.

Upgrading your MongoDB instance to 5.0 and setting featureCompatibilityVersion to 5.0 will delete any pre-existing geoHaystack indexes.

New Error Messages

The db.collection.createIndex() and db.collection.createIndexes() operations have new error messages when options are specified incorrectly.

Interrupted Index Builds

If a node in a replica set is cleanly shutdown or rolls back during an index build, the index build progress is now saved to disk. When the server restarts, index creation resumes from the saved position.

reIndex Behavior Change

Starting in MongoDB 5.0, the reIndex command and the db.collection.reIndex() shell method may only be run on standalone instances.

Removed Commands

Starting in MongoDB 5.0, these database commands and mongo shell helper methods are removed:

Removed Command Alternative
db.collection.ensureIndex() db.collection.createIndex()
db.resetError() Not available
resetError Not available
shardConnPoolStats connPoolStats
unsetSharding Not available
geoSearch $geoNear or one of the supported geospatial query operators

Replica Sets

Non-transactional Reads on config.transactions

Starting in MongoDB 5.0, non-transaction reads are not allowed on the config.transactions collection with the following read concerns and options:

hello Command

Starting in MongoDB 5.0 (and 4.4.2, 4.2.10, 4.0.21, and 3.6.21), the hello command and the db.hello() method were introduced as replacements for the isMaster command and the db.isMaster() method. The new topology metric connections.exhaustHello tracks this in connections.

Quiesce Period

Starting in MongoDB 5.0, mongod and mongos enter a quiesce period to allow any ongoing database operations to complete before shutting down.

Limit Removed for members[n]._id Values

Starting in MongoDB 5.0, the members[n]._id field may be any integer value greater than or equal to 0. Previously, this value was limited to an integer between 0 and 255 inclusive.

enableMajorityReadConcern Is Not Configurable

Starting in MongoDB 5.0, enableMajorityReadConcern and --enableMajorityReadConcern cannot be changed and are always set to true due to storage engine improvements.

In earlier versions of MongoDB, enableMajorityReadConcern and --enableMajorityReadConcern are configurable and can be set to false to prevent storage cache pressure from immobilizing a deployment with a three-member primary-secondary-arbiter (PSA) architecture.

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:

  • The write concern "majority" can cause performance issues if a secondary is unavailable or lagging. For advice on how to mitigate these issues, see Mitigate Performance Issues with PSA Replica Set.
  • If you are using a global default "majority" and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data.

Enhanced Thread Pool Timeout Control

Starting in MongoDB 5.0, you can use the new replWriterMinThreadCount server parameter to configure the timeout of idle threads in the thread pool for parallel execution of replication operations. When replWriterMinThreadCount is configured with a value less than replWriterThreadCount, idle threads above replWriterMinThreadCount are timed out.

Reconfiguring PSA Replica Sets

When reconfiguring primary-secondary-arbiter (PSA) replica sets or changing to a PSA architecture, it is now in some cases required to perform the reconfiguration in a two-step change. MongoDB 5.0 introduces the rs.reconfigForPSASet() method which performs both steps. If you cannot use the helper method, follow the procedure in Modify PSA Replica Set Safely.

Limit Sync Source Re-evaluations

maxNumSyncSourceChangesPerHour determines how many sync source changes can happen per hour before the node temporarily stops re-evaluating a sync source. This parameter will not prevent a node from starting to sync from another node if it doesn’t have a sync source.

enableOverrideClusterChainingSetting Server Parameter

Starting in MongoDB 5.0.2 (and 4.2.16 and 4.4.8), you can set the new enableOverrideClusterChainingSetting server parameter to true to allow secondary members to replicate data from other secondary members even if settings.chainingAllowed is false.

Security

Support for Online Certificate Rotation

Starting in MongoDB 5.0, you may now rotate the following TLS certificates on demand without first needing to stop your running mongod or mongos instance:

To rotate these certificates, replace the certificate files on your filesystem with updated versions, then use the rotateCertificates command or the db.rotateCertificates() shell method to trigger certificate rotation.

Rotating certificates in this manner does not require downtime, and does not drop any active remote connections.

See Online Certificate Rotation for full details.

Support for Configuring TLS 1.3 Cipher Suites

MongoDB 5.0 introduces the opensslCipherSuiteConfig parameter to enable configuration of the supported cipher suites OpenSSL should permit when using TLS 1.3 encryption.

TLS Connection X509 Certificate Startup Warning

Starting in MongoDB 5.0, mongod and mongos now issue a startup warning when their certificates do not include a Subject Alternative Name attribute.

The following platforms do not support common name validation:

  • iOS 13 and higher
  • MacOS 10.15 and higher
  • Go 1.15 and higher

Clients using these platforms will not authenticate to MongoDB servers that use x.509 certificates whose hostnames are specified by CommonName attributes.

ApplyOps Privilege Action

MongoDB 5.0 introduces the applyOps privilege action which is inherited by dbAdminAnyDatabase.

The applyOps action permits users to run the applyOps database command.

Sharded Clusters

Resharding

The ideal shard key allows MongoDB to distribute documents evenly throughout the cluster while facilitating common query patterns. A suboptimal shard key can lead to performance or scaling issues due to uneven data distribution. Starting in MongoDB 5.0, you can use the reshardCollection command to change the shard key for a collection to change the distribution of your data across your cluster.

currentOp Reports Ongoing Resharding Operations

Starting in MongoDB 5.0, the $currentOp aggregation stage (and the currentOp command and db.currentOp() shell method) include additional information about the status of ongoing resharding operations for the resharding coordinator and the donor and recipient shards.

db.currentOp Method Now Uses Aggregation Stage in mongosh

Starting in MongoDB 5.0, the $currentOp aggregation stage is used when running the helper method db.currentOp() with mongosh.

mongos / mongod Connection Pool

Starting in MongoDB 5.0 (also available starting in 4.4.5 and 4.2.13), MongoDB adds the parameter option "automatic" as the new default for the ShardingTaskExecutorPoolReplicaSetMatching. When set for a mongos, the instance follows the behavior specified for the "matchPrimaryNode" option. When set for a mongod, the instance follows the behavior specified for the "disabled" option.

renameCollection Compatible with Sharded Collections

Starting in MongoDB 5.0, you can use the renameCollection command to change the name of a sharded collection.

When renaming a sharded or unsharded collection in a sharded cluster, the source and target collections are exclusively locked on every shard. Subsequent operations on the source and target collections must wait until the rename operation completes.

movePrimary Error Message For Writes During Operation

Starting in MongoDB 5.0, when using the movePrimary command to remove a shard from a sharded cluster, writes to the original shard will generate an error message.

Split and Merge Chunk Changelogs Show Owning Shard

Starting in MongoDB 5.0, documents in the config.changelog collection for split and merge operations contain an owningShard field. The owningShard field shows the shardId of the shard that owns the chunks that were split or merged.

The owningShard field helps identify shards where split or merge operations frequently occur.

maxCatchUpPercentageBeforeBlockingWrites Server Parameter

Starting in MongoDB 5.0 (and 4.4.7, 4.2.15, 4.0.26), you can set the maxCatchUpPercentageBeforeBlockingWrites to specify the maximum allowed percentage of data not yet migrated during a moveChunk operation when compared to the total size (in MBs) of the chunk being transferred.

This parameter can affect the behavior of:

Shell Changes

New MongoDB Shell: mongosh

The mongo shell has been deprecated in MongoDB v5.0. The replacement shell is mongosh. The legacy mongo shell will be removed in a future release.

Shell packaging also changes in MongoDB v5.0. Refer to the installation instructions for further details.

Shell Support for GCP and Azure KMS Providers

Starting in MongoDB 5.0 (and MongoDB 4.4.5), the Google Cloud Platform KMS and Azure Key Vault are supported in both mongosh and the legacy mongo shell as Key Management Service (KMS) providers for manual-csfle-feature.

Using a KMS, you can centrally and securely store Customer Master Keys (CMKs), which are used to encrypt and decrypt data encryption keys as part of the client-side field level encryption workflow.

In addition, a configured KMS allows for the use of How CSFLE Decrypts Documents of data fields when used with MongoDB Enterprise.

To learn more, see Configure a KMS provider using mongosh.

Snapshots

Extended Support for Read Concern "snapshot"

Starting in MongoDB 5.0, read concern "snapshot" is supported for some read operations outside of multi-document transactions on primaries and secondaries.

minSnapshotHistoryWindowInSeconds Server Parameter

Starting in MongoDB 5.0, you can use the minSnapshotHistoryWindowInSeconds parameter to control how long WiredTiger keeps the snapshot history.

Transactions

coordinateCommitReturnImmediatelyAfterPersistingDecision Parameter

Starting in MongoDB 5.0, the new server parameter coordinateCommitReturnImmediatelyAfterPersistingDecision controls when transaction commit decisions are returned to the client. In previous versions of MongoDB, the shard transaction coordinator waited for all members to acknowledge a multi-document transaction commit before returning the commit decision to the client.

Naming Changes

Starting in February 2022, the “Versioned API” terminology was changed to “Stable API”. All concepts and features remain the same with this naming change.

General Improvements

Capped Collection Deletes Process On Secondaries

Starting in MongoDB 5.0, the implicit delete operations of replica set capped collections are processed by the secondary members.

Execution Plan Statistics for Query with $lookup Pipeline Stage

MongoDB 5.0 adds execution plan statistics for queries that use a $lookup pipeline stage.

Improved Handling of ($) and (.) in Field Names

MongoDB 5.0 adds improved support for field names that are ($) prefixed or that contain (.) characters. The validation rules for storing data have been updated to make it easier to work with data sources that use these characters.

Cluster Wide Default Write Concern

Starting in MongoDB 5.0, once the Cluster Wide Write Concern (CWWC) is set via the setDefaultRWConcern command the write concern cannot be unset.

Implicit Default Write Concern

Starting in MongoDB 5.0, the implicit default write concern is w: majority. However, special considerations are made for deployments containing arbiters:

  • The voting majority of a replica set is 1 plus half the number of voting members, rounded down. If the number of data-bearing voting members is not greater than the voting majority, the default write concern is { w: 1 }.
  • In all other scenarios, the default write concern is { w: "majority" }.

Specifically, MongoDB uses the following formula to determine the default write concern:

if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ]
    defaultWriteConcern = { w: 1 }
else
    defaultWriteConcern = { w: "majority" }

For example, consider the following deployments and their respective default write concerns:

Non-Arbiters Arbiters Voting Nodes Majority of Voting Nodes Implicit Default Write Concern
2 1 3 2 { w: 1 }
4 1 5 3 { w: "majority" }
  • In the first example:
    • There are 2 non-arbiters and 1 arbiter for a total of 3 voting nodes.
    • The majority of voting nodes (1 plus half of 3, rounded down) is 2.
    • The number of non-arbiters (2) is equal to the majority of voting nodes (2), resulting in an implicit write concern of { w: 1 }.
  • In the second example:
    • There are 4 non-arbiters and 1 arbiter for a total of 5 voting nodes.
    • The majority of voting nodes (1 plus half of 5, rounded down) is 3.
    • The number of non-arbiters (4) is greater than the majority of voting nodes (3), resulting in an implicit write concern of { w: "majority" }.

The { w: "majority" } default write concern provides a stronger durability guarantee in the event of an election, or if replica set members become unavailable.

The { w: "majority" } write concern may impact performance since writes will only be acknowledged once a calculated majority of replica set members have executed and persisted the write to disk. If your application relies on performance-sensitive writes, you can use the setDefaultRWConcern command to explicitly set the default write concern for improved performance at the cost of data durability guarantees. You can also set the write concern at the individual operation level for performance-critical writes. See your :driver:`driver documentation </>` for details.

mongosShutdownTimeoutMillisForSignaledShutdown Parameter

Starting in MongoDB 5.0, the new parameter mongosShutdownTimeoutMillisForSignaledShutdown specifies the time in milliseconds to wait for any ongoing database operations to complete before initiating a shutdown of mongos.

Configurable zstd Compression Level

MongoDB 5.0 introduces the zstdCompressionLevel configuration file option which allows for configurable compression levels when blockCompressor is set to zstd.

Lock-Free Read Operations

Starting in MongoDB 5.0, the following read operations are not blocked when another operation holds an exclusive (X) write lock on the collection:

When writing to a collection, mapReduce and aggregate hold an intent exclusive (IX) lock. Therefore, if an exclusive X lock is already held on a collection, mapReduce and aggregate write operations are blocked.

Schema Validation Failures Explained

MongoDB 5.0 adds detailed explanations when a document fails schema validation.

Repair Option in validate Command

Starting in MongoDB 5.0, the validate command and db.collection.validate() helper method have a new repair option for repairing a collection that has inconsistencies.

The validate command and db.collection.validate() helper method also return a new repaired boolean value that is true if the collection was repaired.

validate Command Reports Document Schema Violations

Starting in MongoDB 5.0, validate and db.collection.validate() validates documents in a collection. The commands report if any schema validation rules are violated.

Repair Option in mongod

Starting in MongoDB 5.0, the --repair option for mongod validates the collections to find any inconsistencies and fixes them if possible, which avoids rebuilding the indexes. See the --repair option for usage and limitations.

corruptRecords Field in Validation Output

Starting in MongoDB 5.0, the validate command and db.collection.validate() helper method return a new corruptRecords field that contains an array of RecordId values for corrupt documents.

maxValidateMemoryUsageMB Server Parameter

Starting in MongoDB 5.0, the setParameter command has a new maxValidateMemoryUsageMB parameter, which sets the maximum memory usage for the validate command.

findChunksOnConfigTimeoutMS Server Parameter

Starting in MongoDB 5.0, you can use the findChunksOnConfigTimeoutMS parameter to change the timeout for find operations on chunks.

Database Profiler filter Option

Starting in MongoDB 5.0, you can set a filter option for the database profiler to determine which operations are profiled and logged. You can use the filter expression in place of the slowms and sampleRate profiler options.

See:

Log Changes to Database Profiler Settings

Starting in MongoDB 5.0 (also available starting in 4.4.2, 4.2.12, and 4.0.22), changes made to the database profiler level, slowms, sampleRate, or filter using the profile command or db.setProfilingLevel() wrapper method are recorded in the log file.

Independent Log Rotation for Server and Audit Logs

Starting in MongoDB 5.0, when auditing is enabled, you may now rotate the server and audit logs independently using the logRotate command. Previously, logRotate would rotate the two logs together.

remote Field in Slow Operation Logs

Starting in MongoDB 5.0, slow operation log messages include a remote field specifying client IP address.

remoteOpWaitMillis Log Field

Starting in MongoDB 5.0, you can use the remoteOpWaitMillis log field to obtain the wait time for results from shards.

resolvedViews Log Field for Slow Queries on Views

Starting in MongoDB 5.0, log messages for slow queries on views include a resolvedViews field that contains the view details.

Define Variables Using the let Option

Starting in MongoDB 5.0, the following commands have a let option to define a list of variables. This allows you to improve command readability by separating the variables from the query text.

The update command also has a c field to define a list of variables.

Support for Username to LDAP DN Mapping by Default

Starting in MongoDB 5.0, the userToDNMapping configuration file option and the --ldapUserToDNMapping command line option for mongod / mongos and mongoldap now map the authenticated username as the LDAP DN by default if an empty mapping document (i.e. an empty string or empty array) is specified to the option. Previously, providing an empty mapping document would cause mapping to fail.

Additional dbStats Free Space Statistics

Starting in MongoDB 5.0, the dbStats command outputs these additional statistics:

serverStatus Output Change

serverStatus includes the following new fields in its output:

Aggregation Metrics
API Version Metrics
Replication Metrics
Read Concern Counters
Number of Threaded Connections
  • connections.threaded, which reports the number of incoming connections from clients that are assigned to threads that service client requests
Resharding Statistics
Service Executor Metrics
Cursor Metrics
Security Counter
Repl
  • repl now includes a primaryOnlyServices document that contains additional information about services that only run on replica set primaries.

Plan Cache Debug Info Size Limit

Starting in MongoDB 5.0 (and 4.4.3, 4.2.12, 4.0.23, and 3.6.23), the plan cache will save full plan cache entries only if the cumulative size of the plan caches for all collections is lower than 0.5 GB. When the cumulative size of the plan caches for all collections exceeds this threshold, additional plan cache entries are stored without certain debug information.

The estimated size in bytes of a plan cache entry is available in the output of $planCacheStats.

Closure of Inactive Cursors Opened Within a Session

Starting in MongoDB 5.0 (and 4.4.8), cursors created within a client session close when the corresponding server session ends with the killSessions command, if the session times out, or if the client has exhausted the cursor. See Iterate a Cursor in mongosh.

New validateDBMetadata Command

MongoDB 5.0 adds the validateDBMetadata command. The validateDBMetadata command checks that the stored metadata of a database or a collection is valid within a particular API version.

Platform Support

Minimum Microarchitecture

MongoDB 5.0 introduces the following minimum microarchitecture requirements:

CPU Minimum Supported Microarchitecture
Intel x86_64

MongoDB 5.0 requires one of:

  • Intel Sandy Bridge or later Core processor, or
  • Intel Tiger Lake or later Celeron or Pentium processor.
AMD x86_64 MongoDB 5.0 requires AMD Bulldozer or later.
ARM arm64 MongoDB 5.0 requires ARMv8.2-A or later.

MongoDB v5.0 is not supported on x86_64 or arm64 platforms that do not meet these minimum microarchitecture requirements.

See x86_64 Platform Support for more information.

Removed Platforms

MongoDB 5.0 removes support for the following platforms:

  • macOS 10.13
  • RHEL 7 / CentOS 7 / Oracle 7 on the PPC64LE architecture
  • SLES 12 on the s390x architecture
  • Ubuntu 18.04 on the PPC64LE and s390x architectures

See prod-notes-supported-platforms for the full list of platforms and architectures supported in MongoDB 5.0.

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

Upgrade Procedures

Important

Feature Compatibility Version

To upgrade to MongoDB 5.0 from a 4.4 deployment, the 4.4 deployment must have featureCompatibilityVersion set to 4.4. To check the version:

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

To upgrade to MongoDB 5.0, refer to the upgrade instructions specific to your MongoDB deployment:

If you need guidance on upgrading to 5.0, MongoDB professional services offer major version upgrade support to help ensure a smooth transition without interruption to your MongoDB application.

Download

To download MongoDB 5.0, go to the MongoDB Download Center.

See also

Known Issues

In Version Issues Status
5.0.0 SERVER-58171: A Time Series collection’s granularity parameter cannot be modified after the collection is created. Fixed in 5.0.1
5.0.0 SERVER-58392: An ongoing resharding operation may prevent a backup or restore operation from succeeding. Unresolved

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.

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.