Release Notes for MongoDB 5.0 (original) (raw)
Note
MongoDB 5.0 Released July 13, 2021
Warning
Past Release Limitations
The Critical Advisories below affect some prior MongoDB versions. If your deployment depends on features impacted by a Critical Advisory, upgrade to the latest available patch release.
- SERVER-76631 Store CPU model name in FTDC metadata
- SERVER-78311 mongos does not report writeConcernError in presence of writeErrors for insert command
- SERVER-86674 Primary catch-up may believe it is caught up when it is not
- SERVER-89529 Retryable writes during resharding may execute more than once if chunk migration follows the reshard operation
- SERVER-94635 Make session refresh parameters configurable
- All JIRA issues closed in 5.0.31
- 5.0.31 Changelog
Important
Improper neutralization of null bytes may lead to buffer over-reads in MongoDB Server
In MongoDB 5.0 prior to 5.0.30, an authorized user may trigger crashes or receive the contents of buffer over-reads of Server memory by issuing specially crafted requests that construct malformed BSON in the MongoDB Server.
This issue affects MongoDB Server versions:
5.0.0 - 5.0.29
6.0.0 - 6.0.18
7.0.0 - 7.0.14
8.0.0 - 8.0.1
SERVER-96419 Improper neutralization of null bytes may lead to buffer over-reads in MongoDB Server
Important
Fix for CSFLE and Queryable Encryption self-lookup may send values in subpipelines as plaintext instead of ciphertext
Due to CVE-2024-8013, in MongoDB 5.0 prior to 5.0.28, a bug in query analysis of certain complex self-referential $lookup subpipelines may result in literal values in expressions for encrypted fields being sent to the server malformed.
Should this occur, no documents are returned or written. This issue affects the mongocryptd
binary and mongo_crypt_v1
shared library in the following MongoDB Server versions:
- 7.3.0 - 7.3.3
- 7.0.0 - 7.0.11
- 6.0.0 - 6.0.16
- 5.0.0 - 5.0.28
CVSS Score: 2.2
CWE: CWE-319: Cleartext Transmission of Sensitive Information
SERVER-96254 CSFLE and Queryable Encryption self-lookup may fail to encrypt values in subpipelines
SERVER-59831 WTUniqueIndex::_insert expects secondaries to pass in dupsAllowed=true
SERVER-76777 Deadlock between index build external abort and self abort
SERVER-88750 Add "bypassEmptyTsReplacement" param to insert, update, findAndModify, and bulkWrite
SERVER-91223 $log gives incorrect calculation with Decimal128
WT-8771 Checkpoint cleanup to dirty obsolete page with overflow items
SERVER-63198 Prevent shutdown command from hanging
SERVER-90747 Handle $elemMatch with empty path in plan enumerator correctly
SERVER-91362 Performance: Do not copy JS "scope" object if a cached JsExecution exists
SERVER-91562 [5.0] IndexDescriptor::compareIndexOptions treats no unique/sparse as not identical to unique:false/sparse:false
WT-10807 Skip in-memory deleted pages as part of the tree walk
SERVER-78556 Return default of internalInsertMaxBatchSize to 64
SERVER-79637 Incorrect query results in $lookup with TS foreign collection using a correlated predicate
SERVER-80363 server default writeConcern is not honored when wtimeout is set
SERVER-86474 internalApplyOplogUpdatewith_internalApplyOplogUpdate with internalApplyOplogUpdatewithset: { foo: Timestamp(0, 0) } is not replicated correctly
SERVER-86648 Resumable index build sorter files are not fsynced on shutdown
SERVER-68128 Exceptions thrown while generating command response lead to network error
SERVER-72703 Downgrade $out's db lock to MODE_IX
SERVER-83602 or−>or -> or−>in MatchExpression rewrite should not generate ordirectlynestedinanotheror directly nested in another ordirectlynestedinanotheror
SERVER-86717 Resharding should validate user provided zone range doesn't include $-prefixed fields.
WT-11062 Safe free the ref addr to allow concurrent access
Important
Fix for MongoDB Server may allow successful untrusted connection
Due to CVE-2024-1351, in MongoDB 5.0 prior to 5.0.25, under certain configurations of --tlsCAFile andCAFile, MongoDB Server may skip peer certificate validation which may result in untrusted connections to succeed.
This may effectively reduce the security guarantees provided by TLS and open connections that should have been closed due to failing certificate validation. This issue affects the following MongoDB Server versions:
- 7.0.0 - 7.0.5
- 6.0.0 - 6.0.13
- 5.0.0 - 5.0.24
- 4.4.0 - 4.4.28
CVSS Score: 8.8
CWE: CWE-295: Improper Certificate Validation
SERVER-64444 listIndexes fails on invalid pre-5.0 index spec after upgrade
SERVER-82353 Multi-document transactions can miss documents when movePrimary runs concurrently
SERVER-83564 Make sure the process field is indexed in config.locks
SERVER-85419 Balancer pollutes logs in case no suitable recipient is found during draining
WT-10017 Remove the unstable historical versions at the end of rollback to stable
SERVER-50792 Return more useful errors when a shard key index can't be found for shardCollection/refineCollectionShardKey
SERVER-77506 Sharded multi-document transactions can mismatch data and ShardVersion
SERVER-81878 startupRecoveryForRestore may not play nicely with collection drop applied during startup recovery
SERVER-83091 $or query can trigger an infinite loop during plan enumeration
WT-7929 Investigate a solution to avoid FTDC stalls during checkpoint
SERVER-78108 POS interface should expose its shutdown state
SERVER-78115 Shard primaries must commit a majority write before using new routing information from the config server
SERVER-83150 Document::shred() does not copy document metadata
WT-11564 Fix RTS to read the newest transaction value only when it exists in the checkpoint
WT-11602 Hide expected eviction failures from the application and don't rollback in case of errors
SERVER-68548 MongoDB Shell version 4.4.15 logging asio message despite --quiet flag
SERVER-80021 Make $convert round-trip correctly between double and string
SERVER-80703 Avoid traversing routing table in MigrationDestinationManager
SERVER-81106 Recipient shard doesn't wait for the collection version to be locally persisted before starting the cloning phase
WT-11064 Skip globally visible tombstones as part of update obsolete check
SERVER-60466 Support drivers gossiping signed $clusterTimes to replica set --shardsvrs before addShard is run
SERVER-71627 Refreshed cached collection route info will severely block all client request when a cluster with 1 million chunks
SERVER-78813 Commit point propagation fails indefinitely with exhaust cursors with null lastCommitted optime
WT-10759 Do not retry to force evict history store pages during reconciliation
WT-11051 Fix newest start durable timestamp comparison in aggregate timestamp validation
SERVER-74954 Incorrect result when contained orrewritesor rewrites orrewriteselemMatch extra condition
SERVER-78813 Commit point propagation fails indefinitely with exhaust cursors with null lastCommitted optime
SERVER-79136 Incorrect query result of match+match + match+group on metaField over time-series
WT-10449 Do not save update chain when there are no updates to be written to the history store
WT-11031 Fix RTS to skip tables with no time window information in the checkpoint
SERVER-71985 Automatically retry time series insert on DuplicateKey error
SERVER-74551 WriteConflictException unnecessarily logged as warning during findAndModify after upgrade to mongo 5.0
SERVER-77018 Deadlock between dbStats and 2 index builds
SERVER-78126 For specific kinds of input, mongo::Value() always hashes to the same result on big-endian platforms
WT-10253 Run session dhandle sweep and session cursor sweep more often
Issues fixed:
- SERVER-48196 Upgrade the timelib to the latest to update the built-in timezone files to the latest
- SERVER-54150 Recovery from a stable checkpoint should fassert on oplog application failures
- SERVER-57056 Syslog severity set incorrectly for INFO messages
- SERVER-72686 Add support for $collStats agg stage on timeseries collection
- WT-10551 Incremental backup may omit modified blocks
- All JIRA issues closed in 5.0.18
- 5.0.18 Changelog
Issues fixed:
- SERVER-73229 Logical sessions cache refresh ignores write errors from updating session document, leading to cursors being killed early
- SERVER-74647 Resharding state machine creation should be retried after interruption
- SERVER-75261 "listCollections" command fails with BSONObjectTooLarge error
- SERVER-75431 Get rid or fix best effort check for primary db on rename path in sharded clusters
- SERVER-76098 Allow queries with $search and non-simple collations
- All JIRA issues closed in 5.0.17
- 5.0.17 Changelog
Issues fixed:
- SERVER-61909 Hang inserting or deleting document with large number of index entries
- SERVER-73822 Time-series $group rewrite ignores certain accumulators
- SERVER-74345 mongodb-org-server 4.4.19, 5.0.15, 6.0.5 not starting after upgrading from older version (Debian, RPM Packages)
- SERVER-74501 Fix MigrationBatchFetcher/Inserter completion reliance to not spawn an extra cleanup thread
- SERVER-75205 Deadlock between stepdown and restoring locks after yielding when all read tickets exhausted
- All JIRA issues closed in 5.0.16
- 5.0.16 Changelog
Issues fixed:
- SERVER-54900 Blocking networking calls can delay sync-source resolution indefinitely
- SERVER-72416 The find and findAndModify projection code does not honor the collection level collation
- SERVER-71759 dataSize command doesn't yield
- SERVER-72222 MapReduce with single reduce optimization fails when merging results in sharded cluster
- WT-9268 Delay deletion of the history store record to reconciliation
- All JIRA issues closed in 5.0.15
- 5.0.15 Changelog
Issues fixed:
- SERVER-68477 Improve NaN-handling for expireAfterSeconds TTL index parameter
- SERVER-66289 $out incorrectly throws BSONObj size error on v5.0.8
- SERVER-61185 Use prefix_search for unique index lookup
- SERVER-68115 Bug fix for "elemMatchRootLength > 0" invariant trigger
- SERVER-68139 Resharding command fails if the projection sort is bigger than 100MB
- All JIRA issues closed in 5.0.14
- 5.0.14 Changelog
Issues fixed:
- SERVER-69611 Set the -ffp-contract=off compiler option by default
- SERVER-69220 refineCollectionShardKey permits toggling current shard key fields between range-based and hashed, leading to data inconsistency
- SERVER-67650 Resharding recipient can return remainingOperationTimeEstimatedSecs=0 when the oplog applier hasn't caught up with the oplog fetcher
- SERVER-68094 Resharding with custom generated _id fails with projection error
- WT-9870 Fix updating pinned timestamp whenever oldest timestamp is updated during recovery
- All JIRA issues closed in 5.0.13
- 5.0.13 Changelog
Issues fixed:
- SERVER-68925 Reintroduce check table logging settings at startup (revert SERVER-43664)
- SERVER-63852 getThreadName() should not crash
- SERVER-60958 Avoid server hang in chunk migration when step-down event occurs
- SERVER-65382 AutoSplitVector should not use clientReadable to reorder shard key fields
- SERVER-63843 Don't allow recursive doLog in synchronous signal handlers
- All JIRA issues closed in 5.0.12
- 5.0.12 Changelog
Issues fixed:
- SERVER-68511 MovePrimary update of
config.databases
entry must use dotted fields notation - SERVER-61321 Improve handling of large/NaN values for text index version
- SERVER-60607 Improve handling of large/NaN values for geo index version
- SERVER-68628 Retrying a failed resharding operation after a primary failover can lead to server crash or lost writes
- SERVER-68522 Prevent 5.0 binary from starting in FCV 4.4 with misconfigured TTL index
- WT-9500 Fix RTS to use cell time window instead of key/value timestamps of HS update
- All JIRA issues closed in 5.0.11
- 5.0.11 Changelog
Issues fixed:
- SERVER-66418 Bad projection created during dependency analysis due to string order assumption
- SERVER-65821 Deadlock during setFCV when there are prepared transactions that have not persisted commit/abort decision
- SERVER-65131 Disable opportunistic read targeting (except for hedged reads)
- SERVER-63971 Change server parameter to default to read-your-writes behavior after 2PC transaction
- SERVER-66433 Backport deadline waiting for overlapping range deletion to finish to pre-v5.1 versions
- All JIRA issues closed in 5.0.10
- 5.0.10 Changelog
Issues fixed:
- SERVER-65636 Remove limits on number of LDAP connections per host
- SERVER-65137 Detect namespace changes when refreshing Collection after yielding
- SERVER-64822 Sharding an empty collection releases the critical section too early
- SERVER-62175 Mongos fails to attach RetryableWrite Error Label For Command Interrupted In _parseCommand
- WT-9096 Fix search near returning wrong key/value sometimes when key doesn't exist
- All JIRA issues closed in 5.0.9
- 5.0.9 Changelog
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
Issues fixed:
- SERVER-64517 RecoverableCriticalSection is not properly recovered on startup
- SERVER-64403 Find queries with SORT_MERGE collation-encode the missing sort attribute
- SERVER-63742 Default topology time in shard can lead to infinite refresh in shard registry
- SERVER-60412 Host memory limit check does not honor cgroups v2
- WT-7922 Handle missing WiredTiger version file
- All JIRA issues closed in 5.0.7
- 5.0.7 Changelog
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
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
Issues fixed:
- SERVER-60326 Windows Server fails to start when X509 certificate has empty subject name
- SERVER-59876 Large delays in returning from libcrypto.so while establishing egress connections
- SERVER-59456 Start the LDAPReaper threadpool
- SERVER-59226 Deadlock when stepping down with a profile session marked as uninterruptible
- SERVER-59074 Do not acquire storage tickets just to set/wait on oplog visibility
- All JIRA issues closed in 5.0.4
- 5.0.4 Changelog
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
Issues fixed:
- SERVER-58936: Unique index constraints may not be enforced
- SERVER-57756: Race between concurrent stepdowns and applying transaction oplog entry
- SERVER-54729: MongoDB Enterprise Debian/Ubuntu packages should depend on libsasl2-modules and libsasl2-modules-gssapi-mit
- SERVER-47372: config.cache collections can remain even after collection has been dropped
- WT-6729: Quiesce eviction prior running rollback to stable's active transaction check
- All JIRA issues closed in 5.0.2
- 5.0.2 Changelog
Issues fixed:
- SERVER-58489: Collection creation stuck in an infinite writeConflictRetry loop when having a duplicate name as a view
- SERVER-58171: Changing time-series granularity does not update view definition
- All JIRA issues closed in 5.0.1
- 5.0.1 Changelog
The rest of this page provides the 5.0.0 release notes:
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.
MongoDB 5.0 introduces the following aggregation 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.
Starting in MongoDB 5.0, the $eq, $lt,$lte, $gt, and $gte operators placed in an $expr operator can use indexes to improve performance.
Starting in MongoDB 5.0, you can specify multiple input expressions for the $ifNull expression before returning a replacement expression.
Starting in MongoDB 5.0, the aggregate command anddb.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.
Starting in MongoDB 5.0, an aggregation pipeline $lookupstage supports concise correlated subqueries that improve joins between collections.
Starting in MongoDB 5.0, for an uncorrelated subquery in a$lookup pipeline stage containing a $samplestage, 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.
Starting in MongoDB 5.0, the query optimizer pushes down the results of a $project stage into the $sort stage. As a result,$sort
operations can require less RAM when used with the project
stage and avoid Sort exceeded memory limit
errors.
MongoDB 5.0 adds the ability to configure auditing filters at runtime.
Starting in MongoDB 5.0:
- System event auditing has:
- An additional uuid field and otheraudit message enhancements.
- New audit message types: clientMetadata, directAuthMutation, logout, and startup.
- Additional information and logging scenarios for these existing audit message types: authCheck,authenticate,createCollection,createIndex, anddropCollection.
- DDL operations auditing on secondaries has changes. See Audit Events and Filter.
Starting in MongoDB 5.0, the implicit delete operations for replica set capped collections are processed by the primary and replicated to the secondary members.
Starting in MongoDB 5.0.7, you can delete documents from capped collections using delete methods.
Starting in MongoDB 5.0, Change Eventscontain the field updateDescription.truncatedArrays
to record array truncations.
Starting in MongoDB 5.0, multiplepartial indexescan be created using the same key pattern as long as the partialFilterExpressionfields do not express equivalent filters.
In earlier versions of MongoDB, creating multiplepartial indexes is not allowed when using the same key pattern with differentpartialFilterExpressions.
Starting in MongoDB 5.0, unique sparseand unique non-sparse indexes with the samekey pattern can exist on a single collection.
See unique sparse index creation
The db.collection.dropIndexes() command cannot dropready indexesif 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.
When run on a MongoDB deployment,db.collection.validate() attempts to fixmultikey metadata inconsistenciesof standalone deployments.
MongoDB 5.0 removes the deprecated geoHaystack
index andgeoSearch
command. Use a 2d index with$geoNear or one of the supported geospatial query operators instead.
Upgrading your MongoDB instance to 5.0 and settingfeatureCompatibilityVersion to 5.0
will delete any pre-existing geoHaystack
indexes.
The db.collection.createIndex() and db.collection.createIndexes()operations have new error messages when options are specified incorrectly.
If a node in a replica set is cleanly shutdown or rolls back during an index build, the index build progress is nowsaved to disk. When the server restarts, index creation resumes from the saved position.
Starting in MongoDB 5.0, the reIndex command and thedb.collection.reIndex() shell method may only be run onstandalone instances.
Starting in MongoDB 5.0, these database commands andmongo
shell helper methods are removed:
Starting in MongoDB 5.0, non-transaction reads are not allowed on the config.transactions collection with the following read concerns and options:
- "snapshot"
- "majority" and theafterClusterTime option is set
- When using a MongoDB Driverand "majority"within a causally consistent session
Starting in MongoDB 5.0, thehello command and the db.hello() method were introduced as replacements for the isMaster
command and the db.isMaster()
method. The new topology metricconnections.exhaustHello tracks this inconnections.
Starting in MongoDB 5.0, mongod and mongosenter a quiesce period to allow any ongoing database operations to complete before shutting down.
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.
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, seeMitigate Performance Issues with a Self-Managed 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.
Starting in MongoDB 5.0, you can use the newreplWriterMinThreadCount server parameter to allow idle threads above this minimum to be closed. When replWriterMinThreadCount is configured with a value less than replWriterThreadCount, idle threads above replWriterMinThreadCount are timed out.
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 inModify a Self-Managed PSA Replica Set Safely.
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.
Starting in MongoDB 5.0.2, you can set the newenableOverrideClusterChainingSetting server parameter totrue
to allow secondary members to replicate data from other secondary members even if settings.chainingAllowed isfalse
.
Starting in MongoDB 5.0, you may now rotate the following TLS certificates on demand without first needing to stop your runningmongod or mongos instance:
- TLS Certificates
- CRL (Certificate Revocation List) files(on Linux and Windows platforms)
- CA (Certificate Authority) files
To rotate these certificates, replace the certificate files on your filesystem with updated versions, then use therotateCertificates command or thedb.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.
MongoDB 5.0 introduces the opensslCipherSuiteConfigparameter to enable configuration of the supported cipher suites OpenSSL should permit when using TLS 1.3 encryption.
Starting in MongoDB 5.0, mongod and mongos now issue a startup warning when their certificates do not include aSubject 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 notauthenticate to MongoDB servers that use X.509 certificates whose hostnames arespecified by CommonName attributes.
MongoDB 5.0 introduces the applyOpsprivilege action which is inherited by dbAdminAnyDatabase.
The applyOps action permits users to run theapplyOps database command.
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 thereshardCollection command to change the shard key for a collection to change the distribution of your data across your cluster.
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.
Starting in MongoDB 5.0, the $currentOp aggregation stage is used when running the helper method db.currentOp()with mongosh.
Starting in MongoDB 5.0, 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 amongod, the instance follows the behavior specified for the "disabled"
option.
Starting in MongoDB 5.0, you can use the renameCollectioncommand 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.
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.
Starting in MongoDB 5.0, documents in the config.changelogcollection forsplit andmerge operations contain an owningShard
field. The owningShard
field shows theshardId
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.
Starting in MongoDB 5.0, you can set themaxCatchUpPercentageBeforeBlockingWrites 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:
- moveChunk commands that are run manually.
- Load balancer functionality, which automatically runs multiplemoveChunk commands to evenly distribute chunks across shards. See Sharded Cluster Balancer.
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 theinstallation instructions for further details.
Starting in MongoDB 5.0, the Google Cloud Platform KMS and Azure Key Vault are supported in both mongosh and the legacy mongo
shell asKey Management Service (KMS)providers for Client-Side Field Level Encryption.
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 ofHow CSFLE Decrypts Documents of data fields when used with MongoDB Enterprise.
To learn more, see Configure a KMS provider using mongosh.
Starting in MongoDB 5.0, read concern "snapshot" is supported for some read operations outside of multi-document transactions on primaries and secondaries. SeePerform Long-Running Snapshot Queries.
Starting in MongoDB 5.0, you can use theminSnapshotHistoryWindowInSeconds parameter to control how long WiredTiger keeps the snapshot history.
The server parametercoordinateCommitReturnImmediatelyAfterPersistingDecisioncontrols when transaction commit decisions are returned to the client.
The parameter was introduced in MongDB 5.0 with a default value oftrue
. In MongoDB 6.1 the default value changes to false
.
When coordinateCommitReturnImmediatelyAfterPersistingDecision
isfalse
, the shard transaction coordinator waits for all members to acknowledge a multi-document transaction commit before returning the commit decision to the client.
Starting in February 2022, the "Versioned API" terminology was changed to "Stable API". All concepts and features remain the same with this naming change.
MongoDB 5.0 adds execution plan statistics for queries that use a $lookuppipeline stage.
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.
Starting in MongoDB 5.0, once the Cluster Wide Write Concern (CWWC) is set via the setDefaultRWConcern command the write concern cannot be unset.
Starting in MongoDB 5.0, the implicit defaultwrite concern isw: majority. However, special considerations are made for deployments containingarbiters:
- 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" } defaultwrite concern provides a stronger durability guarantee in the event of an election, or if replica set members become unavailable.
Starting in MongoDB 5.0, the new parametermongosShutdownTimeoutMillisForSignaledShutdown specifies the time in milliseconds to wait for any ongoing database operations to complete before initiating a shutdown of mongos.
MongoDB 5.0 introduces thezstdCompressionLevelconfiguration file option which allows for configurable compression levels whenblockCompressor is set to zstd
.
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 andaggregate 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.
MongoDB 5.0 adds detailed explanations when a document failsschema validation.
Starting in MongoDB 5.0, the validate command anddb.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.
Starting in MongoDB 5.0, validate anddb.collection.validate() validates documents in a collection. The commands report if anyschema validation rules are violated.
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.
Starting in MongoDB 5.0, the validate command anddb.collection.validate() helper method return a newcorruptRecords field that contains an array ofRecordId
values for corrupt documents.
Starting in MongoDB 5.0, the setParametercommand has a new maxValidateMemoryUsageMB parameter, which sets the maximum memory usage for the validate command.
Starting in MongoDB 5.0, you can use thefindChunksOnConfigTimeoutMS parameter to change the timeout for find operations on chunks.
Starting in MongoDB 5.0, you can set a filter
option for thedatabase 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:
Starting in MongoDB 5.0, changes made to the database profiler level
, slowms
, sampleRate
, orfilter
using the profile command ordb.setProfilingLevel() wrapper method are recorded in thelog file.
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.
Starting in MongoDB 5.0, slow operation log messages include aremote
field specifying client IP address.
Starting in MongoDB 5.0, you can use the remoteOpWaitMillis log field to obtain the wait time for results from shards.
Starting in MongoDB 5.0, log messages for slow queries on viewsinclude a resolvedViews
field that contains the view details.
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.
- find command
- findAndModify command and correspondingdb.collection.findAndModify() shell helper
- update command and correspondingdb.collection.update() shell helper
- delete command
- db.collection.remove() shell helper
The update command also has a c
field to define a list of variables.
Starting in MongoDB 5.0, the userToDNMappingconfiguration file option and the --ldapUserToDNMapping command line option formongod / mongos and mongoldapnow 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.
Starting in MongoDB 5.0, the dbStats command outputs these additional statistics:
- Free space allocated to collections (freeStorageSize)
- Free space allocated to indexes (indexFreeStorageSize)
- Total free space allocated to collections and indexes (totalFreeStorageSize)
serverStatus includes the following new fields in its output:
Aggregation Metrics
- metrics.commands.update.pipeline
- metrics.commands.update.arrayFilters
- metrics.commands.findAndModify.pipeline
- metrics.commands.findAndModify.arrayFilters
- metrics.dotsAndDollarsFields
- metrics.operatorCounters
API Version Metrics
Replication Metrics
Read Concern Counters
- readConcernCounters, which reports on theread concern level specified by query operations (readConcernCounters replacesopReadConcernCounters)
- readConcernCounters now has the following new fields:
readConcernCounters.nonTransactionOps.noneInfo
readConcernCounters.transactionOps.noneInfo
Write Concern Counters
- opWriteConcernCounters now has the following new fields:
opWriteConcernCounters.insert.noneInfo
opWriteConcernCounters.update.noneInfo
opWriteConcernCounters.delete.noneInfo
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
- shardingStatistics.resharding, which reports statistics about resharding operations
Service Executor Metrics
- network.serviceExecutors, which reports on the service executors that run operations for client requests
Cursor Metrics
- metrics.cursor.moreThanOneBatch, which reports the total number of cursors that have returned more than one batch (additional batches are retrieved using the getMorecommand)
- metrics.cursor.totalOpened, which reports the total number of cursors that have been opened
Security Counter
- security.authentication.saslSupportedMechsReceived, which reports the number of times a hello request includes a valid hello.saslSupportedMechs field.
Repl
- repl now includes aprimaryOnlyServices document that contains additional information about services that only run on replica set primaries.
Starting in MongoDB 5.0, theplan 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 theplan caches
for all collections exceeds this threshold, additionalplan 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.
Starting in MongoDB 5.0, cursors created within aclient session close when the corresponding server sessionends with the killSessions command, if the session times out, or if the client has exhausted the cursor. See Iterate a Cursor in mongosh.
MongoDB 5.0 adds the validateDBMetadata command. ThevalidateDBMetadata command checks that the stored metadata of a database or a collection is valid within a particular API version.
MongoDB 5.0 changes the default write concern to{ w: "majority" }. The new default write concern might impact performance since MongoDB acknowledges writes only after acalculated majority of replica set members have executed and persisted the write to disk.
If your application relies on performance-sensitive writes, you can override the default write concern at the cost of data durability guarantees. To override this setting, you can:
- Set the write concern at the individual operation level for performance-critical writes. For more information, see yourdriver documentation.
- Use the setDefaultRWConcern command to explicitly set the default write concern.
Warning
If write operations use { w: 1 } write concern, the rollback directory may exclude writes submitted after anoplog hole if the primary restarts before the write operation completes.
Starting in MongoDB 5.0, "local" is the default read concern level for read operations against the primary and secondaries. In MongoDB 4.4, queries targeting sharded cluster secondaries use read concern "available" and can returnorphaned documents.
This may introduce a significant latency increase for count queries that use a filter and for covered queries.
You can opt out of this behavior by setting the cluster-wide read concern with setDefaultRWConcern.
MongoDB 5.0 increases the default value ofminSnapshotHistoryWindowInSeconds to 300
, which might negatively impact performance. If you aren't using read concern"snapshot", you can reduce the value of theminSnapshotHistoryWindowInSeconds
parameter to 5
on allmongod instances. For more information, seeSnapshot History Retention.
Note
If you are running a sharded cluster, do not changeminSnapshotHistoryWindowInSeconds
on config servers.
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, orIntel 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.
MongoDB 5.0 removes support for the following platforms:
See Platform Support for the full list of platforms and architectures supported in MongoDB 5.0.
Some changes can affect compatibility and may require user actions. For a detailed list of compatibility changes, seeCompatibility Changes in MongoDB 5.0.
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:
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.
MongoDB only supports single-version downgrades. You cannot downgrade to a release that is multiple versions behind your current release.
For example, you can downgrade a 5.0-series to a 4.4-seriesdeployment. However, further downgrading that 4.4-series deployment to a 4.2-series deployment is not supported.
To download MongoDB 5.0, go to the MongoDB Download Center.
See also:
In Version | Issues | Status |
---|---|---|
5.0.0 | SERVER-58171: A Time Series collection's granularityparameter 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. | Fixed in 5.0.3 |
To report an issue, see the MongoDB GitHub repository for instructions on how to file a JIRA ticket for the MongoDB server or one of the related projects.