Docs Menu
Docs Home
/
MongoDB Manual

Release Notes for MongoDB 6.1

On this page

  • Patch Releases
  • Regular Expressions
  • Replication
  • General Changes
  • Server Parameters
  • Report an Issue

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.

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)

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

  • All JIRA issues closed in 6.1.1

  • 6.1.1 Changelog

The rest of this page provides the 6.1.0 release notes:

The following sections describe changes to regular expressions in MongoDB 6.1.

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:

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.

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.

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

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.

Starting in MongoDB 6.1:

  • To improve efficiency, MongoDB may batch multiple document deletions together.

  • The explain command results contain a new BATCHED_DELETE stage for batched document deletions.

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.

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:

  • ReshardingDonorService<operationUUID>

  • ReshardingRecipientService<operationUUID>

  • ReshardingCoordinatorService<operationUUID>

For $currentOp, the command UUID is added to each role's state document.

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.

Starting in MongoDB 6.1, the serverStatus command and the db.serverStatus() method have these output changes:

resharding.remainingOperationTimeEstimatedMillis is replaced by:

  • oplogApplierApplyBatchLatencyMillis

  • collClonerFillBatchForInsertLatencyMillis

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.

Starting in MongoDB 6.1, the aggregation stages $addFields and $set allow you to set paths to empty objects without using the $literal expression.

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.

Starting in MongoDB 6.1, MongoDB adds the following new parameters:

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.

Next

What is MongoDB?