Release Notes for MongoDB 6.1
On this page
Important
MongoDB 6.1 is a rapid release and is only supported for MongoDB Atlas. MongoDB 6.1 is not supported for use on-premises. For more information, see MongoDB Versioning.
Patch Releases
Warning
Past Release Limitations
Some past releases have critical issues. These releases are not recommended for production use. Use the latest available patch release version instead.
Issue | Affected Versions |
---|---|
6.1.0 - 6.1.1 (ARM64 or POWER system architectures) |
6.1.1 - Jan 3, 2022
Issues fixed:
SERVER-70436 Restrict cases where isCoveredNullQuery can apply
SERVER-70381 _internalSearchIdLookup stage violates a 5.0 precondition of the getOwnershipFilter function
SERVER-70793 Make database metadata refresh first check new metadata under the IS lock before taking X lock
SERVER-69877 Remove untimestamped writes to the catalog when restarting unfinished index builds during startup recovery
WT-10030 Internal pages with fast truncated children are not actively freed
6.1.0 - Oct 11, 2022
The rest of this page provides the 6.1.0 release notes:
Regular Expressions
The following sections describe changes to regular expressions in MongoDB 6.1.
PCRE Library Upgrade
Perl Compatible Regular Expressions (PCRE) is the library used by MongoDB to implement regular expression pattern matching. Starting in version 6.1, MongoDB upgrades the PCRE library to PCRE2. PCRE2 is the current PCRE library and is actively maintained and updated.
To learn how to perform regex matches in MongoDB, see the following pages:
$regex
(query operator)$regexFind
(aggregation operator)$regexFindAll
(aggregation operator)$regexMatch
(aggregation operator)
*UCP
Regex Option to Match Non-ASCII Characters
Starting in MongoDB 6.1, you can use the *UCP
option for regex
queries. The *UCP
option matches non-ASCII characters (specifically,
the option can match UTF-8 characters). However, the *UCP
option
results in a slower query than one without the option specified.
For an example that uses the *UCP
option, see
Extend Regex Options to Match Characters Outside of ASCII.
Replication
Retryable Writes Error Handling
Starting in MongoDB 6.1, if both the first and second attempt of a
retryable write fail without a single write being performed, MongoDB
returns an error with the NoWritesPerformed
label.
The NoWritesPerformed
label differentiates the results of batch
operations like insertMany()
. In an
insertMany
operation, one of the following outcomes can occur:
Outcome | MongoDB Output |
---|---|
No documents are inserted. | Error returned with NoWritesPerformed label. |
Partial work done. (At least one document is inserted, but not
all.) | Error returned without NoWritesPerformed label. |
All documents are inserted. | Success returned. |
Applications can use the NoWritesPerformed
label to definitively
determine that no documents were inserted. This error reporting lets the
application maintain an accurate state of the database when handling
retryable writes.
In previous versions of MongoDB, an error is returned when both the first and second attempts of a retryable write fail. However, there is no distinction made to indicate that no writes were performed.
General Changes
Balancing Policy Changes
Starting in MongoDB 6.1 (and 6.0.3), data in sharded clusters is distributed based on data size rather than number of chunks. Be aware of the following significant changes in sharded cluster data distribution behavior:
The balancer distributes ranges of data rather than chunks. The balancing policy looks for evenness of data distribution rather than chunk distribution.
Chunks are not subject to auto-splitting. Instead, chunks are split only when moved across shards.
A chunk is now referred to as a range.
moveRange
has replacedmoveChunk
.
Changes to Journaling
Starting in MongoDB 6.1, journaling is always enabled. As a result, MongoDB
removes the storage.journal.enabled
option and the corresponding
--journal
and --nojournal
command-line options.
Improved Efficiency for Multiple Document Deletions
Starting in MongoDB 6.1:
Resharding
Starting in MongoDB 6.1, there are new metrics available resharding. The output of the following commands has changed:
For details, see the release notes for currentOp and serverStatus.
currentOp
Metrics
Starting in MongoDB 6.1, the currentOp
command and the
db.currentOp()
method have expanded output for resharding.
Resharding operations can involve multiple MongoDB instances, and MongoDB instances can play different roles in the resharding operation. The particular operation and the role the host instance plays in the resharding process determine when each metric updates.
Metric | Role Tracked | Description |
---|---|---|
opStatus | Removed. | |
desc | All | Describes the action taken. The value is one of:
For |
op | All | This metric has a constant value: "command". |
ns | All | The namespace for the resharded index. The value is a string in
the form: <database>.<collection> . |
originatingCommand | All | A document that lists the command options for the operation. |
donorState | Donor | The current state of the role's state machine. |
coordinatorState | Coordinator | The current state of the role's state machine. |
recipientState | Recipient | The current state of the role's state machine. |
approxDocumentsToCopy | Recipient | The number of documents in the source collection. |
documentsCopied | Recipient | The number of documents already copied. |
approxBytesToCopy | Recipient | The total size, in bytes, of the documents in the source
collection. |
bytesCopied | Recipient | The number of bytes copied. When resharding completes, this value
is similar to the value of approxBytesToCopy . |
oplogEntriesFetched | Recipient | The number of oplog entries written to the oplog buffer
collection. |
oplogEntriesApplied | Recipient | The number of oplog entries applied from the oplog buffer
collection. |
insertsApplied | Recipient | The number of inserts applied to the temporary resharding
collection. Each oplog entry that involves an insert increments
the counter by 1. |
updatesApplied | Recipient | The number of updates applied to the temporary resharding
collection. Each oplog entry that involves an update increments
the counter by 1. |
deletesApplied | Recipient | The number of deletes applied to the temporary resharding
collection. Each oplog entry that involves a delete increments the
counter by 1. |
totalOperationTimeElapsedSecs | All | The number of seconds since the operation began. |
totalCopyTimeElapsedSecs | Recipient | The number of seconds spent cloning. |
totalCopyTimeElapsedSecs | Coordinator | The maximum number of seconds a Recipient could have spent
cloning. |
totalApplyTimeElapsedSecs | Recipient | The number of seconds spent applying changes. |
totalApplyTimeElapsedSecs | Coordinator | The approximate maximum number of seconds a Recipient could have
spent applying changes. |
totalCriticalSectionTimeElapsedSecs | Recipient | The number of seconds spent in the critical section. |
totalCriticalSectionTimeElapsedSecs | Coordinator | The number of seconds the critical section could have been held. |
remainingOperationTimeEstimatedSecs | Recipient | The estimated number of seconds until the operation completes. |
allShardsLowestRemainingOperationTimeEstimatedSecs | Coordinator | Calculated across all shards, the lowest estimate of the number of
seconds remaining. |
allShardsHighestRemainingOperationTimeEstimatedSecs | Coordinator | Calculated across all shards, the highest estimate of the number
of seconds remaining. |
countWritesToStashCollections | Recipient | The number of writes to the recipient stash collections. |
countWritesDuringCriticalSection | Donor | The number of writes attempted during the donor's critical
section. |
countReadsDuringCriticalSection | Donor | The number of reads attempted during the donor's critical section. |
serverStatus
Metrics
Starting in MongoDB 6.1, the serverStatus
command and the
db.serverStatus()
method have these output changes:
New Metrics
countWritesToStashCollections
The number of writes to the recipient stash collection.latencies
Timing metrics for resharding operations.collectionCloningTotalRemoteBatchRetrievalTimeMillis
Total time recipients spent retrieving batches of documents from donors, in milliseconds.collectionCloningTotalRemoteBatchesRetrieved
Total number of batches of documents recipients retrieved from donors.collectionCloningTotalLocalInsertTimeMillis
Total time recipients spent inserting batches of document from donors, in milliseconds.collectionCloningTotalLocalInserts
Total number of batches of documents from donors that recipients inserted.oplogFetchingTotalRemoteBatchRetrievalTimeMillis
Total time recipients spent retrieving batches of oplog entries from donors, in milliseconds.oplogFetchingTotalRemoteBatchesRetrieved
Total number of batches of oplog entries recipients retrieved from donors.oplogFetchingTotalLocalInsertTimeMillis
Total time recipients spent inserting batches of oplog entries from donors, in milliseconds.oplogFetchingTotalLocalInserts
Total number of batches of oplog entries from donors that recipients inserted.oplogApplyingTotalLocalBatchRetrievalTimeMillis
Total time recipients spent retrieving batches of oplog entries that were inserted during fetching, in milliseconds.oplogApplyingTotalLocalBatchesRetrieved
Total number of batches of oplog entries that were inserted during fetching that recipients retrieved.oplogApplyingTotalLocalBatchApplyTimeMillis
Total time recipients spent applying batches of oplog entries, in milliseconds.oplogApplyingTotalLocalBatchesApplied
Total number of batches of oplog entries that recipients applied.
Replaced Metrics
resharding.remainingOperationTimeEstimatedMillis
is replaced by:
Renamed Metrics
countReshardingSuccessful
is nowcountSucceeded
countReshardingFailures
is nowcountFailed
countReshardingOperations
is nowcountStarted
countReshardingCanceled
is nowcountCanceled
minShardRemainingOperationTimeEstimatedMillis
is nowcoordinatorAllShardsLowestRemainingOperationTimeEstimatedMillis
maxShardRemainingOperationTimeEstimatedMillis
is nowcoordinatorAllShardsHighestRemainingOperationTimeEstimatedMillis
resharding.opcounters.insert
is nowinsertsApplied
resharding.opcounters.update
is nowupdatesApplied
resharding.opcounters.delete
is nowdeletesApplied
Removed Metrics
oplogApplierApplyBatchLatencyMillis
collClonerFillBatchForInsertLatencyMillis
Storage Engine
In rare circumstances, a write can fail due to cache pressure. When
this happens MongoDB issues a TemporarilyUnavailable
error and
increments the temporarilyUnavailableErrors
counter in two places:
the slow query log and the Full Time Diagnostic Data Capture
(FTDC).
Individual operations within multi-document transactions never return
TemporarilyUnavailable
errors.
Adjust the write retry properties by modifying the
temporarilyUnavailableBackoffBaseMs
and
temporarilyUnavailableMaxRetries
parameters.
$addFields and $set Allow Empty Objects as Expressions
Starting in MongoDB 6.1, the aggregation stages $addFields
and
$set
allow you to set paths to empty objects without using the
$literal
expression.
Auditing
MongoDB 6.1 adds the following cluster audit events:
Starting in MongoDB 6.1, the startup audit event has this structure:
{ originalClusterServerParameter: <original parameter value>, updatedClusterServerParameter": <new parameter value> }
For additional details, see Audit Event Actions, Details, and Results.
Server Parameters
Starting in MongoDB 6.1, MongoDB adds the following new parameters:
temporarilyUnavailableBackoffBaseMs
adjusts the time between retries after a write failure.temporarilyUnavailableMaxRetries
limits the number of retries after a write failure.ldapRetryCount
sets the number of operation retries by the server LDAP manager after a network error.
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.