Release Notes for MongoDB 8.0MongoDB 8.0发行说明

8.0.15 - Oct 2, 2025

This release contains security or reliability improvements. These release notes will be updated when more information is available.此版本包含安全性或可靠性改进。这些发行说明将在获得更多信息后更新。

• All JIRA issues closed in 8.0.15所有JIRA问题已于8.0.15关闭
• 8.0.15 Changelog

8.0.14 - Sep 25, 2025

Issues fixed:已解决的问题：

• SERVER-100448: Command registration should not depend on the FCV at startup：命令注册不应依赖于启动时的FCV
• SERVER-103742: opWriteConcernCounters can illegally embed a NUL bytes into ServerStatus：opWriteConcernCounters可以将NUL字节非法嵌入ServerStatus
• SERVER-103841: Memory leak in TransactionCoordinator associated to long-lived cancellation source：与长期取消源关联的TransactionCoordinator内存泄漏
• SERVER-105478: Separate eligible and ineligible oplog entries for the applier with secondaryDelaySecs：将符合条件和不符合条件的oplog条目与二级DelaySecs分开

• WT-14140: Unnecessary schema lock taken for active "file:" dhandles that are not swept：对未扫描的活动“file:”数据处理程序采取了不必要的架构锁

• WT-14653: Add logs/stats to reconciliation for tracking HS updates：将日志/统计数据添加到对账中，以跟踪HS更新
• All JIRA issues closed in 8.0.14所有JIRA问题已于8.0.14结束
• 8.0.14 Changelog

8.0.13 - Aug 21, 2025

Issues fixed:已解决的问题：

• SERVER-77172: abortExpiredTransactions thread can get stuck if it fails to checkout a session：abortExpiredTransactions线程如果无法签出会话，则可能会卡住
• SERVER-82180: Capped inserts on the primary can have a different natural ordering from secondaries：primary上的封顶插入物可以具有与secondery不同的自然顺序
• SERVER-91686: Improve mongod signal handler to print out current thread's command object：改进mongod信号处理程序，以打印出当前线程的命令对象
• SERVER-94315: Shard filtering bug with collation：带有排序规则的分片筛选错误
• SERVER-102670: Incorrect ordered time-series insert error handling：顺序不正确的时间序列插入错误处理
• SERVER-107361: Rollover determination in the bucket catalog can fail to check mixed schema for large measurements：桶目录中的滚动确定可能无法检查大型度量的混合模式
• All JIRA issues closed in 8.0.13所有JIRA问题已于8.0.13结束
• 8.0.13 Changelog

8.0.12 - July 23, 2025

Issues fixed:已解决的问题：

• SERVER-95523: upsert does not handle DuplicateKey retry correctly：upsert无法正确处理DuplicateKey重试
• SERVER-95524: Avoid retrying on duplicate key error for upserts in multidocument transactions：避免在多文档事务中因出现异常而重试重复键错误
• SERVER-97368: Enable TTL deletes on time-series collections containing data prior to 1970：对包含1970年之前数据的时间序列集合启用TTL删除
• SERVER-99342: Throughput probing decrease metrics are not being updated：吞吐量探测减少指标未更新
• WT-14391: Check eviction server is running before opening HS：打开HS之前，请检查驱逐服务器是否正在运行
• All JIRA issues closed in 8.0.12所有JIRA问题已于8.0.12结束
• 8.0.12 Changelog

8.0.11 - Jun 30, 2025

Issues fixed:已解决的问题：

• SERVER-105375: Use EOF plan for alwaysFalse expressions within elemMatch：对elemMatch中的alwaysFalse表达式使用EOF计划
• SERVER-106614: List of replica set hosts in config.shards entries not updated for shards added prior to 8.0：配置文件条目中的副本集主机列表未针对8.0之前添加的分片进行更新
• All JIRA issues closed in 8.0.11所有JIRA问题已于8.0.11结束
• 8.0.11 Changelog

8.0.10 - Jun 04, 2025

Issues fixed:已解决的问题：

• SERVER-90495: Support start or resume from deleted recordId on natural order scan：支持在自然顺序扫描中从已删除的recordId开始或恢复
• SERVER-92806: Plan cache entry ignores index collation with $elemMatch：计划缓存条目忽略使用$elemMatch的索引排序规则
• SERVER-96197: ExpressionContext's _resolvedNamespaces can't distinguish between collections with the same name in different dbs：ExpressionContext的_resolvedNamespaces无法区分不同数据库中同名集合
• SERVER-100785: Fatal crash of mongodb config server after issuing malformed reshardCollection command：发出格式错误的reshardCollection命令后，mongodb配置服务器严重崩溃
• WT-13216: Assess the use of cache eviction check in compact：评估compact中缓存清除检查的使用情况
• All JIRA issues closed in 8.0.10
• 8.0.10 Changelog

8.0.9 - May 1, 2025

Issues fixed:已解决的问题：

• SERVER-92236: Chunk migrations should use short lived cancellation sources：块迁移应使用短期取消源
• SERVER-106753: Incorrect handling of incomplete data may prevent mongos from accepting new connections：对不完整数据的错误处理可能会阻止mongos接受新的连接
• All JIRA issues closed in 8.0.9所有JIRA问题已于8.0.9完成
• 8.0.9 Changelog

8.0.8 - Apr 14, 2025

Issues fixed:已解决的问题：

• SERVER-103328 Incorrect BSONColumn handling of skip after non-zero RLE for double type双精度类型非零RLE后跳过的BSONColumn处理不正确
• All Jira issues closed in 8.0.8所有Jira问题都在8.0.8中关闭
• 8.0.8 Changelog

8.0.7 - Apr 14, 2025

Issues fixed:已解决的问题：

• SERVER-106752 MongoDB Server may be susceptible to privilege escalation due to $mergeCursors stage由于$mergeCursors阶段，MongoDB服务器可能容易受到权限升级的影响

8.0.6 - Mar 19, 2025

Issues fixed:已解决的问题：

• SERVER-87442 Platform Support: Add support for Macos 14 sonoma (ARM64 and AMD64)平台支持：添加对Macos 14 sonoma(ARM64和AMD64）的支持
• SERVER-89757 checkSbeStatus should check for all nodescheckSbeStatus应检查所有节点
• SERVER-97911 Query with "_id in empty array" traverses the full collection when given the _id index as a hint当给定_id索引作为提示时，使用“空数组中的_id”的查询会遍历整个集合
• SERVER-100901 Relax user digest invariant to tassert in ShardingTaskExecutor在ShardingTaskExecutor中将用户摘要不变量放宽为tassert

• SERVER-101838 Revert SERVER-93101 + SERVER-91121

• All Jira issues closed in 8.0.6所有Jira问题都在8.0.6中关闭
• 8.0.6 Changelog

8.0.5 - Feb 20, 2025

Issues fixed:已解决的问题：

• SERVER-51366 Configure folders created by installer配置安装程序创建的文件夹
• SERVER-93497 Move user cache invalidation from OpObserver to onCommit handlers将用户缓存无效从OpObserver移动到onCommit处理程序
• SERVER-95672 Indexes on array fields that contain subarrays do not include some results包含子数组的数组字段上的索引不包括某些结果
• SERVER-97044 Fix an issue where change streams might incorrectly output a "drop" event during resharding or unsharding of a collection that is or was using zone sharding修复了一个问题，即在对正在或曾经使用区域分片的集合进行重新分区或取消分区时，更改流可能会错误地输出“drop”事件
• SERVER-97860 Express path can return incorrect results when scanning a unique, multi-field index扫描唯一的多字段索引时，快速路径可能会返回不正确的结果
• SERVER-99290 Invalid timeseries buckets collections prevent completion of FCV 8.0 upgrade时间序列桶集合无效，无法完成FCV 8.0升级
• SERVER-99345 Prevent sharding/moving a time-series buckets collection without the 'timeseries' options on FCV 8.0+在FCV 8.0+上没有“时间序列”选项的情况下，防止分片/移动时间序列桶集合+
• SERVER-106748 Pre-auth denial of service when accepting OIDC authentication接受OIDC身份验证时的预身份验证拒绝服务
• SERVER-106749 Pre-authentication Denial of Service Stack Overflow Vulnerability in JSON Parsing via Excessive Recursion in MongoDBMongoDB中过度递归JSON解析中的预认证拒绝服务堆栈溢出漏洞
• WT-12846 Fix how compact walk handles EBUSY from checkpoint flush_lock修复compact walk如何从检查点flush_lock处理EBUSY
• All Jira issues closed in 8.0.5所有Jira问题都在8.0.5中关闭
• 8.0.5 Changelog

8.0.4 - Dec 9, 2024

• SERVER-73641 Time series filtering can miss extended-range events when sharded分片时，时间序列筛选可能会错过扩展范围事件
• SERVER-82037 Memory used by sorter spills can grow without bound分拣机溢出使用的内存可以无限增长
• SERVER-94559 Time series measurement deletes update the minTime of a bucket时间序列测量删除更新桶的minTime
• SERVER-95067 Time series inserts can generate multiple batches referencing the same bucket时间序列插入可以生成引用同一桶的多个批次
• SERVER-95724 ReshardingOplogSessionApplication clones retryable applyOps session info with admin.$cmd as affectedNamespace使用admin.$cmd重新存储OplogSessionApplication克隆可重试的applyOps会话信息，作为受affectedNamespace（影响命名空间）
• All Jira issues closed in 8.0.4所有Jira问题已在8.0.4中关闭
• 8.0.4 Changelog

8.0.3 - Oct 24, 2024

Issues fixed:已解决的问题：

• SERVER-96419 Improper neutralization of null bytes may lead to buffer over-reads in MongoDB Server空字节的不正确中和可能会导致MongoDB服务器中的缓冲区过度读取
• All Jira issues closed in 8.0.3所有Jira问题已在8.0.3中关闭
• 8.0.3 Changelog

8.0.1 - Oct 9, 2024

Issues fixed:已解决的问题：

• SERVER-76883 Reduce chattiness of "Role does not exist" logs for externally sourced users减少外部用户对“角色不存在”日志的闲聊
• SERVER-82221 listCollections and listIndexes should include commit-pending namespaceslistCollections和listIndexes应包含待提交命名空间
• SERVER-94635 Make session refresh parameters configurable使会话刷新参数可配置
• SERVER-95244 Upsert statements which result in an insert may fail with tassert 9146500 when client connects directly to shard当客户端直接连接到分片时，导致插入的Upsert语句可能会因tassert 9146500而失败
• WT-13409 One ret in __txn_checkpoint is not handled__txn_checkpoint中的一个ret未处理
• All Jira issues closed in 8.0.1所有Jira问题已在8.0.1中关闭
• 8.0.1 Changelog

8.0.0 - Oct 2, 2024

The rest of this page describes changes and new features introduced in MongoDB 8.0.本页其余部分描述了MongoDB 8.0中引入的更改和新功能。

New Bulk Write Command新建批量写入命令

Starting in MongoDB 8.0, you can use the new bulkWrite command to perform many insert, update, and delete operations on multiple collections in one request. 从MongoDB 8.0开始，您可以使用新的bulkWrite命令在一个请求中对多个集合执行许多插入、更新和删除操作。The existing db.collection.bulkWrite() method only allows you to modify one collection in one request.现有的db.collection.bulkWrite()方法只允许您在一个请求中修改一个集合。

bulkWrite operations on MongoDB 8.0 can run up to 56% faster than bulk write operations on MongoDB 7.0.MongoDB 8.0上的bulkWrite操作比MongoDB 7.0上的批量写操作快56%。

Time Series Block Processing时间序列块处理

Starting in version 8.0, MongoDB may execute certain time series queries using block processing. This performance improvement processes queries in "blocks" of data, rather than individual values. Block processing improves query execution speed and throughput when working with time series collections.从8.0版本开始，MongoDB可以使用块处理执行某些时间序列查询。这种性能改进以数据的“块”而不是单个值来处理查询。在处理时间序列集合时，块处理可以提高查询执行速度和吞吐量。

Compared to time series queries run on MongoDB 7.0 or earlier, block processing for time series data in MongoDB 8.0 may handle higher volumes of data and improve throughput in some cases by more than 200% for $group operations and analytical queries.与在MongoDB 7.0或更早版本上运行的时间序列查询相比，MongoDB 8.0中时间序列数据的块处理可以处理更大的数据量，在某些情况下，对于$group操作和分析查询，吞吐量可以提高200%以上。

To see if your time series query uses block processing, check the explain.queryPlanner.winningPlan.slotBasedPlan.stages field in the explain plan output.要查看您的时间序列查询是否使用块处理，请检查解释计划输出中的explain.queryPlanner.winningPlan.slotBasedPlan.stages字段。

To learn more, see Block Processing.要了解更多信息，请参阅块处理。

Database Profiler数据库分析器

When you specify a filter for the database profiler, you can log operations based on the new workingMillis metric. You can log operations based on both workingMillis and durationMillis and set each metric to a different threshold.为数据库分析器指定筛选器时，可以根据新的workingMillis（工作毫秒）度量记录操作。您可以根据工作毫秒和持续时间毫秒记录操作，并将每个指标设置为不同的阈值。

BinData Conversion二进制数据转换

Starting in MongoDB 8.0, you can use the $convert operator to perform the following conversions:从MongoDB 8.0开始，您可以使用$convert运算符执行以下转换：

• String values to binData values将字符串值转换为binData值
• binData values to string valuesbinData值到字符串值

MongoDB 8.0 also includes a new helper expression, $toUUID, which provides simplified syntax for converting strings to UUID values.MongoDB 8.0还包括一个新的辅助表达式$toUUID，它提供了将字符串转换为UUID值的简化语法。

$queryStats

Starting in MongoDB 7.1, the $queryStats stage returns statistics for recorded queries.从MongoDB 7.1开始，$queryStats阶段返回已记录查询的统计信息。

$rank and $denseRank Behavior$rank和$denseRank行为

Starting in MongoDB 8.0, null and missing field values in $denseRank and $rank sortBy operations are treated the same when calculating rankings. 从MongoDB 8.0开始，在计算排名时，$denseRank和$rank sortBy操作中的null和缺失字段值被视为相同。This change makes the behavior of denseRank and rank consistent with $sort.此更改使denseRank和rank的行为与$sort一致。

Queryable Encryption Range Queries可查询的加密范围查询

Starting in MongoDB 8.0, Queryable Encryption supports range queries on encrypted fields using the $lt, $lte, $gt, and $gte operators. 从MongoDB 8.0开始，可查询加密支持使用$lt、$lte、$gt和$gte运算符对加密字段进行范围查询。For details, see Supported Operations for Queryable Encryption. To enable range queries on encrypted fields, see Create an Encryption Schema.有关详细信息，请参阅可查询加密的支持操作。要在加密字段上启用范围查询，请参阅创建加密架构。

OCSF Schema for Log Messages日志消息的OCSF架构

Starting in MongoDB 8.0, you can specify the OCSF schema for audit log messages. The OCSF schema provides logs in a standardized format compatible with log processors.从MongoDB 8.0开始，您可以为审计日志消息指定OCSF模式。OCSF模式以与日志处理器兼容的标准化格式提供日志。

To set the schema used for log messages, use the auditLog.schema configuration file option.要设置用于日志消息的架构，请使用auditLog.schema配置文件选项。

For example log messages in OCSF format, see OCSF Schema Audit Messages.例如，OCSF格式的日志消息，请参阅OCSF架构审核消息。

Ingress Queue入口队列

MongoDB 8.0 introduces a new queue for ingress admission control. Operations that wait for entry into the database from the network enter the ingress queue. By default, the queue is unrestricted, meaning that MongoDB allows all operations to execute through this stage without any queueing. Setting the queue maximum to a specific value allows you to queue operations at this stage if the number of concurrent operations reaches the specified limit.MongoDB 8.0引入了一个新的入口准入控制队列。等待从网络进入数据库的操作进入入口队列。默认情况下，队列是不受限制的，这意味着MongoDB允许所有操作在此阶段执行，而无需任何排队。将队列最大值设置为特定值，允许您在并发操作数量达到指定限制时在此阶段对操作进行排队。

Moving a Collection移动集合

Starting in MongoDB 8.0, you can move an unsharded collection to a different shard using the moveCollection command.从MongoDB 8.0开始，您可以使用moveCollection命令将未分片的集合移动到其他分片。

For details, see Moveable Collections. To get started, see Move a Collection.有关详细信息，请参阅可移动集合。要开始，请参阅移动集合。

Unsharding a Collection打开集合

Starting in MongoDB 8.0, you can unshard existing sharded collections with the unshardCollection command or the sh.unshardCollection() method. 从MongoDB 8.0开始，您可以使用unshardCollection命令或sh.unshardCollection()方法取消对现有分片集合的分区。This operation moves all documents in the collection onto a specified shard or the shard with the least amount of data.此操作将集合中的所有文档移动到指定的分片或数据量最少的分片上。

For details, see Unsharded Collections. To get started, see Unshard a Collection.有关详细信息，请参阅未分片集合。要开始，请参阅取消分片集合。

Config Shards配置分片

Starting in MongoDB 8.0, you can configure a config server to store your application data in addition to the usual sharded cluster metadata. 从MongoDB 8.0开始，您可以配置配置服务器来存储应用程序数据以及通常的分片集群元数据。A mongod node that provides both config server and shard server functionality is called a config shard. 同时提供配置服务器和分片服务器功能的mongod节点称为配置分片。A mongod node that runs as a standalone --configsvr without shard server functionality is called a dedicated config server.没有分片服务器功能的mongod节点作为独立的--configsvr运行，称为专用配置服务器。

To configure a dedicated config server to run as a config shard, run the transitionFromDedicatedConfigServer command.要将专用配置服务器配置为作为配置分片运行，请运行transitionFromDedicatedConfigServer命令。

To configure a config shard to run as a dedicated config server, run the transitionToDedicatedConfigServer command.要将配置分片配置为作为专用配置服务器运行，请运行transitionToDedicatedConfigServer命令。

For details, see Config Shard. To get started, see Start a Sharded Cluster with a Config Shard. 有关详细信息，请参阅配置分片。要开始，请参阅使用配置分片启动分片集群。To convert a replica set to a sharded cluster with a config shard, see Convert a Replica Set to a Sharded Cluster with an Embedded Config Server.要将副本集转换为具有配置分片的分片集群，请参阅使用嵌入式配置服务器将副本集转化为分片集群。

New Database Commands新建数据库命令

• abortMoveCollection
• abortUnshardCollection
• moveCollection
• transitionFromDedicatedConfigServer
• transitionToDedicatedConfigServer
• unshardCollection

New mongosh Methods新mongosh方法

• sh.abortMoveCollection()
• sh.abortUnshardCollection()
• sh.moveCollection()
• sh.shardAndDistributeCollection()
• sh.unshardCollection()

serverStatus Metrics服务器状态指标

Starting in MongoDB 8.0, serverStatus includes the following new shardingStatistics fields in its output:从MongoDB 8.0开始，serverStatus在其输出中包括以下新的shardingStatistics字段：

• shardingStatistics.countTransitionToDedicatedConfigServerStarted
• shardingStatistics.countTransitionToDedicatedConfigServerCompleted
• shardingStatistics.countTransitionFromDedicatedConfigServerCompleted
• shardingStatistics.configServerInShardCache

MongoDB 7.1 includes the following new sharding statistics for chunk migrations:MongoDB 7.1包括以下用于块迁移的新分片统计信息：

• shardingStatistics.countDonorMoveChunkCommitted
• shardingStatistics.countDonorMoveChunkAborted
• shardingStatistics.totalDonorMoveChunkTimeMillis
• shardingStatistics.countBytesClonedOnRecipient
• shardingStatistics.countDocsClonedOnCatchUpOnRecipient
• shardingStatistics.countBytesClonedOnCatchUpOnRecipient

Default Chunks Per Shard每个分片的默认块数

Starting in MongoDB 7.2, when you shard an empty collection with a hashed shard key, the operation creates one chunk per shard by default. Previously, the operation created two chunks by default.从MongoDB 7.2开始，当您使用哈希分片键对空集合进行分片时，默认情况下，该操作会为每个分片创建一个块。以前，该操作默认创建了两个块。

directShardOperations Role角色

Starting in MongoDB 8.0, you can use the directShardOperations role to perform maintenance operations that require you to execute commands directly against a shard.从MongoDB 8.0开始，您可以使用directShardOperations角色执行维护操作，这些操作要求您直接对分片执行命令。

dbhash Can Run Directly on a Sharddbhash可以直接在分片上运行

Starting in MongoDB 8.0.5, you can run dbHash directly on a shard. For a full list of shard direct commands, see Shard Direct Commands.从MongoDB 8.0.5开始，您可以直接在分片上运行dbHash。有关分片直接命令的完整列表，请参阅分片直接指令。

Exhaust Cursors Enabled for Sharded Clusters为分片集群启用排气游标

Starting in MongoDB 7.1, mongos supports exhaust cursors when a client's getMore request sets the exhaustAllowed flag. 从MongoDB 7.1开始，当客户端的getMore请求设置了exhaustAllowed标志时，mongos支持exhaust游标。This can improve query performance on sharded clusters when the client receives multiple replies from the database server for a single request.当客户端从数据库服务器收到单个请求的多个回复时，这可以提高分片集群上的查询性能。

mongos Port Range蒙古港范围

Starting in MongoDB 7.1, mongos accepts --port values from [0, 65535]. For more information, see --port.从MongoDB 7.1开始，mongos接受[0，65535]中的--port值。有关更多信息，请参阅--port。

Query with Partial Shard Key使用部分分片键进行查询

Starting in MongoDB 7.1, findAndModify and deleteOne() can use a partial shard key to query on a sharded collection.从MongoDB 7.1开始，findAndModify和deleteOne()可以使用部分分片键来查询分片集合。

Resharding Improvements重新硬装改进

MongoDB 8.0 introduces significant performance improvements in resharding operations, substantially reducing the amount of time the operation takes to run.MongoDB 8.0在重新标记操作中引入了显著的性能改进，大大减少了操作运行所需的时间。

Additionally, if your application and cluster meet the necessary requirements and limitations, you can reshard the collection on the same key using the reshardCollection command to redistribute your collection, which is much faster than alternative range migration procedure.此外，如果您的应用程序和集群满足必要的要求和限制，您可以使用reshardCollection命令在同一键上重新标记集合以重新分发您的集合，这比其他范围迁移过程快得多。

The following options are added to the command:以下选项将添加到命令中：

For examples, see Redistribute Data to New Shards.有关示例，请参阅将数据重新分配到新分片。

Self-Managed Backups of Sharded Clusters分片集群的自我管理备份

Starting in MongoDB 7.1, the fsync and fsyncUnlock commands can perform fsync operations on sharded clusters.从MongoDB 7.1开始，fsync和fsyncUnlock命令可以在分片集群上执行fsync操作。

When run on mongos with the lock field set to true, the fsync command flushes writes from the storage layer to disk and locks each shard, preventing additional writes. 当在mongos上运行并将lock字段设置为true时，fsync命令会将写入从存储层刷新到磁盘并锁定每个分片，从而防止额外的写入。The fsyncUnlock command can then be used to unlock the cluster.然后，可以使用fsyncUnlock命令解锁集群。

This feature enables self-managed backups of sharded clusters using mongodump.此功能允许使用mongodump对分片集群进行自我管理备份。

UpdateOne upsert Behavior on Sharded CollectionsUpdateOne对分片化集合的扰乱行为

Starting in MongoDB 7.1, when using updateOne() with upsert: true on a sharded collection, you do not need to include the full shard key in the filter.从MongoDB 7.1开始，当在分片集合上使用updateOne()和upsert:true时，您不需要在筛选器中包含完整的分片键。

$lookup Stage in Transactions with Sharded Collections分片集合事务中的$lookup阶段

Starting in MongoDB 8.0, you can use the $lookup stage within a transaction while targeting a sharded collection.从MongoDB 8.0开始，您可以在事务中使用$lookup阶段，同时针对分片集合。

Majority Write Concern多数人写担忧

Starting in MongoDB 8.0, write operations that use the "majority" write concern return an acknowledgment when the majority of replica set members have written the oplog entry for the change. 从MongoDB 8.0开始，当大多数副本集成员已经为更改写入oplog条目时，使用"majority"写入关注的写入操作会返回确认。This improves the performance of "majority" writes. In previous releases, these operations would wait and return an acknowledgment after the majority of replica set members applied the change.这提高了"majority"写入的性能。在以前的版本中，这些操作将在大多数副本集成员应用更改后等待并返回确认。

If your application reads from a secondary immediately after receiving an acknowledgment from a { w: "majority" } write operation (without a causally consistent session), the query may return results that don't include changes from the write.如果您的应用程序在收到{ w: "majority" }写入操作的确认后立即从辅助服务器读取（没有因果一致的会话），则查询可能会返回不包括写入更改的结果。

New replSetGetStatus Metrics新replSetGetStatus指标

Starting in MongoDB 8.0, the following metrics are available when using the replSetGetStatus command:从MongoDB 8.0开始，使用replSetGetStatus命令时可以使用以下指标：

• replSetGetStatus.electionCandidateMetrics.lastSeenWrittenOpTimeAtElection
• replSetGetStatus.electionParticipantMetrics.lastWrittenOpTimeAtElection
• replSetGetStatus.electionParticipantMetrics.maxWrittenOpTimeInSet
• replSetGetStatus.members[n].optimeWritten
• replSetGetStatus.members[n].optimeWrittenDate
• replSetGetStatus.members[n].lastWrittenWallTime
• replSetGetStatus.optimeWritten
• replSetGetStatus.optimeWrittenDate
• replSetGetStatus.optimes.lastWrittenWallTime
• replSetGetStatus.optimes.writtenOpTime

Oplog BuffersOplog缓冲区

Starting in MongoDB 8.0, secondaries write and apply oplog entries for each batch in parallel. A writer thread reads new entries from the primary and writes them to the local oplog. An applier thread asynchronously applies these changes to the local database. This changes increases replication throughput for secondaries.从MongoDB 8.0开始，二级服务器并行为每个批写入和应用oplog条目。writer线程从主线程读取新条目并将其写入本地oplog。应用程序线程异步地将这些更改应用于本地数据库。此更改增加了辅助服务器的复制吞吐量。

This introduces a breaking change for metrics.repl.buffer, as it now provides metrics on two buffers instead of one.这为metrics.repl.buffer带来了突破性的变化，因为它现在在两个缓冲区而不是一个缓冲区上提供度量。

MongoDB 8.0 deprecates the following server status metrics:MongoDB 8.0不支持以下服务器状态指标：

• metrics.repl.buffer.count
• metrics.repl.buffer.maxSizeBytes
• metrics.repl.buffer.sizeBytes

MongoDB 8.0 adds the following server status metrics:MongoDB 8.0增加了以下服务器状态指标：

• metrics.repl.buffer.apply
• metrics.repl.buffer.apply.count
• metrics.repl.buffer.apply.maxCount
• metrics.repl.buffer.apply.maxSizeBytes
• metrics.repl.buffer.apply.sizeBytes
• metrics.repl.buffer.write
• metrics.repl.buffer.write.count
• metrics.repl.buffer.write.maxSizeBytes
• metrics.repl.buffer.write.sizeBytes
• metrics.repl.write
• metrics.repl.write.batchSize
• metrics.repl.write.batches
• metrics.repl.write.batches.num
• metrics.repl.write.batches.totalMillis

serverStatus Metrics指标

Starting in MongoDB 8.0, the following new serverStatus metrics report information about tcmalloc usage:从MongoDB 8.0开始，以下新的serverStatus指标报告了有关tcmalloc使用情况的信息：

• tcmalloc.usingPerCPUCaches
• tcmalloc.generic.peak_memory_usage
• tcmalloc.tcmalloc.cpu_free
• tcmalloc.tcmalloc.total_bytes_held
• tcmalloc.tcmalloc.cpuCache
• tcmalloc.tcmalloc.cpuCache.N.overflows
• tcmalloc.tcmalloc.cpuCache.N.underflows
• tcmalloc.tcmalloc_derived.total_free_bytes

Shutdown Performance关机性能

Starting in MongoDB 8.0, Bulk.insert() and data ingestion workloads may perform better. However, shutting down MongoDB immediately after running these workloads might take longer because of the extra data being flushed to disk.从MongoDB 8.0开始，Bulk.insert()和数据摄取工作负载可能会表现更好。然而，在运行这些工作负载后立即关闭MongoDB可能需要更长的时间，因为额外的数据会被刷新到磁盘。

Store Application Data on Config Shards将应用程序数据存储在配置分片上

Starting in MongoDB 8.0, you can configure a config server to store application data in addition to the usual sharded cluster metadata. The config server is then known as a config shard. 从MongoDB 8.0开始，您可以配置配置服务器来存储应用程序数据，以及通常的分片集群元数据。配置服务器被称为“配置分片”。For details, see Config Shards.有关详细信息，请参阅配置分片。

Compaction Improvements压实改进

Starting in MongoDB 7.3, the compact command includes a new freeSpaceTargetMB option to specify the minimum amount of storage space, in megabytes, that must be recoverable for compaction to proceed.从MongoDB 7.3开始，compact命令包括一个新的freeSpaceTargetMB选项，用于指定压缩必须恢复的最小存储空间量（以兆字节为单位）。

Concurrent DDL Operations并发DDL操作

Starting in MongoDB 7.1, when you run multiple DDL operations that target different collections from the same database, MongoDB runs those operations concurrently.从MongoDB 7.1开始，当您运行针对同一数据库中不同集合的多个DDL操作时，MongoDB会同时运行这些操作。

This change adds two new types to the serverStatus locks field and currentOp.locks output:此更改为serverStatus locks字段和currentOp.locks输出添加了两种新类型：

• DDLDatabase
• DDLCollection

Database Validation on mongos Aggregation Queriesmongos聚合查询的数据库验证

Starting in MongoDB 7.2, aggregation pipeline queries that attempt to use non-existent databases on mongos deployments return validation errors.从MongoDB 7.2开始，试图在mongos部署上使用不存在的数据库的聚合管道查询会返回验证错误。

In previous versions, these aggregation queries return empty cursors.在以前的版本中，这些聚合查询返回空游标。

DDL OperationsDDL操作

In MongoDB 8.0, if you add or remove a shard while your cluster executes a DDL operation (operation that modifies a collection such as reshardCollection), any operation that adds or removes a shard only executes after the concurrent DDL operation finishes.在MongoDB 8.0中，如果在集群执行DDL操作（修改集合（如reshardCollection）的操作）时添加或删除分片，则任何添加或删除分片的操作都只能在并发DDL操作完成后执行。

Error Codes for Exceeding Pipeline Size Limit超出管道尺寸限制的错误代码

Starting in MongoDB 7.1, an aggregation command will throw an error when a pipeline exceeds the pipeline stage limit. For more details, see Number of Stages Restrictions.从MongoDB 7.1开始，当管道超过管道阶段限制时，聚合命令将抛出错误。有关更多详细信息，请参阅阶段数限制。

getField Field Supports All Strings字段支持所有字符串

Starting in MongoDB 7.2, you can specify any valid expression that resolves to a string for the field input of the $getField operator. 从MongoDB 7.2开始，您可以为$getField运算符的field输入指定任何解析为字符串的有效表达式。In earlier versions, field accepts only string constants.在早期版本中，字段只接受字符串常量。

Improved Index Builds改进索引构建

Starting in MongoDB 7.1, index builds are improved with faster error reporting and increased failure resilience. 从MongoDB 7.1开始，索引构建得到了改进，错误报告更快，故障恢复能力更强。You can also set the minimum available disk space required for index builds using the new indexBuildMinAvailableDiskSpaceMB parameter, which stops index builds if disk space is too low.您还可以使用新的indexBuildMinAvailableDiskSpaceMB参数设置索引构建所需的最小可用磁盘空间，如果磁盘空间太低，该参数将停止索引构建。

The following new index build metrics were added:添加了以下新的索引构建指标：

• indexBuilds.killedDueToInsufficientDiskSpace
• indexBuilds.failedDueToDataCorruption

For full details, see Index Builds.有关完整详细信息，请参阅索引构建。

New Parameters参数

New Query Shape and Query Settings新建查询形状和查询设置

MongoDB 8.0 introduces a new query shape. The pre-existing query shape is renamed as the plan cache query shape.MongoDB 8.0引入了一种新的查询形状。预先存在的查询形状将重命名为计划缓存查询形状。

Starting in MongoDB 8.0, you can add query settings for the new query shape. 从MongoDB 8.0开始，您可以为新的查询形状添加查询设置。The query optimizer uses the query settings as an additional input during query planning, which affects the plan selected to run a query that has a matching query shape.查询优化器在查询规划期间使用查询设置作为额外输入，这会影响为运行具有匹配查询形状的查询而选择的计划。

Query settings have improved functionality compared to index filters. Index filters are also deprecated starting in MongoDB 8.0, and you should avoid using them.与索引筛选器相比，查询设置的功能得到了改进。从MongoDB 8.0开始，索引筛选器也被弃用，你应该避免使用它们。

• To add query settings, use the setQuerySettings command.要添加查询设置，请使用setQuerySettings命令。
• To delete query settings, use the removeQuerySettings command.要删除查询设置，请使用removeQuerySettings命令。
• To retrieve query settings, use a $querySettings stage in an aggregation pipeline.要检索查询设置，请在聚合管道中使用$querySettings阶段。
• To block a query shape, see operation rejection filters.要阻止查询形状，请参阅操作拒绝筛选器。
• To set the log verbosity level for rejected queries, use the systemLog.component.query.rejected.verbosity parameter.要为被拒绝的查询设置日志详细程度，请使用systemLog.component.query.rejected.verbosity参数。

Starting in MongoDB 8.0, queryShapeHash is included in the following output:从MongoDB 8.0开始，queryShapeHash包含在以下输出中：

• explain command in the explain.queryShapeHash fieldexplain.queryShapeHash字段中的explain命令
• database profiler in the system.profile.queryShapeHash fieldsystem.profile.queryShapeHash字段中的数据库分析器
• $currentOp aggregation pipeline stage in the $currentOp.queryShapeHash field$currentOp.queryShapeHash字段中的$currentOp聚合管道阶段
• slow query log慢速查询日志
• $queryStats stage in the queryShapeHash fieldqueryShapeHash字段中的$queryStats阶段

Starting in MongoDB 8.0, the existing queryHash field is duplicated in a new field named planCacheShapeHash. If you're using an earlier MongoDB version, you'll only see the queryHash field. 从MongoDB 8.0开始，现有的queryHash字段被复制到一个名为planCacheShapeHash的新字段中。如果你使用的是早期的MongoDB版本，你只会看到queryHash字段。Future MongoDB versions will remove the deprecated queryHash field, and you'll need to use the planCacheShapeHash field instead.未来的MongoDB版本将删除弃用的queryHash字段，您将需要使用planCacheShapeHash字段。

numInitialChunks Option Removed选项已删除

Starting in MongoDB 7.2, the numInitialChunks option is removed from the shardCollection command. 从MongoDB 7.2开始，从shardCollection命令中删除numInitialChunks选项。The server automatically creates chunks on every shard in a cluster when using hashed sharding for an empty collection.当对空集合使用哈希分片时，服务器会自动在集群中的每个分片上创建块。

Parameter Filtering参数筛选

Starting in MongoDB 8.0, the getParameter command accepts a setAt field. 从MongoDB 8.0开始，getParameter命令接受setAt字段。You can use this field to filter the allParameters: true return document to show only those parameters that you can set at startup or runtime.您可以使用此字段筛选allParameters:true返回文档，仅显示您可以在启动或运行时设置的参数。

Read Concern on Capped Collections关于封顶集合的读取关注

Starting in MongoDB 8.0, you can use read concern "snapshot" on capped collections.从MongoDB 8.0开始，您可以在封顶集合上使用读取关注"snapshot"。

serverStatus Output Change输出更改

Starting in MongoDB 7.1, the serverStatus command output includes the following new metrics:从MongoDB 7.1开始，serverStatus命令输出包括以下新指标：

• changeStreamPreImages.expireAfterSeconds
• metrics.changeStreams.showExpandedEvents
• queryStats

Starting in MongoDB 7.2, the serverStatus command output includes the following new metrics:从MongoDB 7.2开始，serverStatus命令输出包括以下新指标：

• metrics.operation.killedDueToMaxTimeMSExpired
• readPreferenceCounters

Starting in MongoDB 7.3, the serverStatus command output includes the following new metrics:从MongoDB 7.3开始，serverStatus命令输出包括以下新指标：

• metrics.repl.stateTransition.totalOperationsRunning
• metrics.repl.stateTransition.totalOperationsKilled
• metrics.repl.waiters.replication
• metrics.repl.waiters.opTime
• planCache.classic.skipped
• planCache.sbe.skipped

Starting in MongoDB 8.0, the serverStatus command output includes the following new metrics:从MongoDB 8.0开始，serverStatus命令输出包括以下新指标：

• opWorkingTime
• opWorkingTime.commands
• opWorkingTime.reads
• opWorkingTime.writes
• opWorkingTime.transactions
• planCache.classic.replanned
• planCache.sbe.replanned

Sort Option选项

Starting in MongoDB 8.0, updateOne(), replaceOne(), and update have an optional sort field to order documents before applying an update.从MongoDB 8.0开始，updateOne()、replaceOne()和update都有一个可选的sort字段，用于在应用更新之前对文档进行排序。

Previous releases use the findAndModify() and findOneAndUpdate() methods to update the first document in a user-specified sort order. 以前的版本使用findAndModify()和findOneAndUpdate()方法以用户指定的排序顺序更新第一个文档。Support for retryable writes requires these methods to copy the entire document to a special side collection for each node, which is a more expensive operation than the updateOne() method with the new sort option.支持可重试写入要求这些方法将整个文档复制到每个节点的特殊侧集合中，这是一个比具有新排序选项的updateOne()方法更昂贵的操作。

Specify Query Index Hints for distinct Commands为不同的命令指定查询索引提示

Starting in MongoDB 7.1, the hint field is available in the distinct command, allowing you to specify the query's index.从MongoDB 7.1开始，hint字段在distinct命令中可用，允许您指定查询的索引。

TTL IndexesTTL索引

Starting in MongoDB 7.1, you can create TTL indexes on capped collections.从MongoDB 7.1开始，您可以在封顶集合上创建TTL索引。

Query Planning and Execution查询计划和执行

Batch Multi-Document Insert Operations批量多文档插入操作

Starting in MongoDB 8.0, bulk insert operations outside of transactions may no longer produce individual oplog entries. Instead, MongoDB typically batches bulk inserts as a single entry. 从MongoDB 8.0开始，事务之外的批量插入操作可能不再产生单个oplog条目。相反，MongoDB通常将批量插入作为单个条目进行批处理。The change stream insert event for each document has the same clusterTime.每个文档的更改流insert事件具有相同的clusterTime。

This change increases performance of multi-document insert operations and eliminates possible replication lag caused by multiple oplog writes.此更改提高了多文档插入操作的性能，并消除了多次oplog写入可能导致的复制延迟。

OIDC Identity Providers Can Share an IssuerOIDC身份提供者可以共享发卡机构

Starting in MongoDB 8.0, when multiple identity providers (IDP) are defined, the oidcIdentityProviders parameter accepts duplicate issuer values as long as the audience value is unique for each issuer. 从MongoDB 8.0开始，当定义了多个身份提供者（IDP）时，oidcIdentityProviders参数接受重复的issuer（颁发者）值，只要每个颁发者的audience值都是唯一的。This is also available in versions 7.3 and 7.0.这在7.3和7.0版本中也可用。

Namespaces in Subpipelines子管道中的命名空间

Starting in MongoDB 8.0, namespaces in subpipelines inside $lookup and $unionWith are validated to ensure the correct use of from and coll fields.从MongoDB 8.0开始，$lookup和$unionWith内的子管道中的命名空间经过验证，以确保from和coll字段的正确使用。

For details, see $lookup subpipelines and $unionWith subpipelines.有关详细信息，请参阅$lookup子管道和$unionWith子管道。

Query Planner Optimization Time查询计划优化时间

The explain() method now returns information on query planner optimization time. explain()方法现在返回查询计划器优化时间的信息。The queryPlanner.optimizationTimeMillis status shows the time in milliseconds that the query planner spent on optimizations.queryPlanner.optimizationTimeMillis状态显示查询计划器在优化上花费的时间（毫秒）。

Only Single-Version Downgrades are Supported仅支持单版本降级

MongoDB only supports single-version downgrades. You cannot downgrade to a release that is multiple versions behind your current release.MongoDB只支持单版本降级。您不能降级到比当前版本落后多个版本的版本。

For example, you can downgrade a 8.0-series to a 7.0-series deployment. However, further downgrading that 7.0-series deployment to a 6.0-series deployment is not supported.例如，您可以将8.0系列部署降级为7.0系列部署。但是，不支持将7.0系列部署进一步降级为6.0系列部署。

Downgrade Policy降级政策

• Binary downgrades aren't supported for MongoDB Community Edition.MongoDB社区版不支持二进制降级。
• You cannot downgrade your deployment's FCV to or from a rapid release version of MongoDB.您无法将部署的FCV降级到MongoDB的快速发布版本或从MongoDB的快速版本降级。
• If you upgrade or downgrade your deployment's FCV, you cannot downgrade your Enterprise deployment's binary version without assistance from support.如果升级或降级部署的FCV，则在没有支持人员帮助的情况下，无法降级企业部署的二进制版本。