当在MongoDB 5.2之前创建的时间序列集合升级到MongoDB 6.0或更高版本，而在此集合被克隆之前，查询可能会返回不完整的结果。相关地，MongoDB Rapid Releases 7.1.0-7.3.3上的时间序列集合，在那些版本上通过collMod更改了集合粒度，也可能返回不完整的查询结果。

在MongoDB服务器版本6.0.17上运行包含$group和$lookup的某些聚合管道时，一个错误会导致结果不正确或崩溃。

Node.js v22.7.0运行时存在一个回归，与其处理UTF-8编码相关，这可能影响使用MongoDB Node.js驱动的应用程序的数据完整性。MongoDB在其任何产品中都不使用受影响的Node.js版本，但是使用MongoDB Node.js驱动的开发人员在通过Node.js v22.7.0运行时将数据写入其集群时可能会遇到数据完整性问题。

为了平衡负载并保持高质量的服务，Atlas Serverless系统有时会在不同的数据库服务器之间迁移无服务器实例的数据。在迁移完成后，Atlas Serverless不会安全地自动重试某些多写、非事务性数据库命令，这可能导致更新和删除行为不正确。

mongosync 1.1.0 – 1.7.1版本在初始数据复制过程中可能出现问题，导致某些写入或源上的文档未复制到目标。请升级到mongosync版本1.7.2或更高版本。Atlas Live Migrate依赖于mongosync进行MongoDB 6.0+迁移，修复已应用于Atlas Live Migrate。

影响分片集群上多文档事务的问题，可能导致分片多文档事务返回不正确的数据，并可能错过写入。

mongodump中的一个错误会导致集合选项中的键以错误的顺序导出。这些更改可能会更改视图返回的结果集，或者更改由验证器接受的文档。

影响Sharded Time Series集合插入的问题可能导致这些集合上插入的文档立即成为孤儿，导致查询不返回文档并可能导致数据丢失。

mongosync 1.5中的一个竞争条件可能导致源上的某些写入未复制到目标。请升级到版本1.6或更高版本。

存储引擎问题可能导致增量Ops Manager和Cloud Manager备份不一致。从受影响的增量备份中恢复的集群可能会因校验和错误而崩溃。Atlas客户/备份不受影响。

在ARM64或POWER架构上运行的MongoDB存储引擎可能存在一个bug，导致文档或索引条目顺序错误，从而引起不一致性以及查询结果排序不正确或不完整。

Atlas、Ops Manager和Cloud Manager中的MongoDB代理问题可能导致自动的“滚动索引构建”引入索引不一致性。其他平台上的MongoDB集群不受影响。

对于配置不当的TTL索引，在从版本4.4或更早版本升级到MongoDB 5.0或6.0时，可能会突然过期文档。

MongoDB版本5.0.0-5.0.10和6.0.0中的分片元数据bug可能在执行movePrimary命令时引入损坏。

MongoDB 4.4.3和4.4.4中的存储引擎bug在升级到4.4.8-4.4.10或5.0.2-5.0.5时可能引入损坏。可以从版本4.4.3和4.4.4直接升级到4.4.11+或5.0.6+。

MongoDB 4.4.2-4.4.8和5.0.0-5.0.2中的存储引擎bug可能导致在非干净关闭和重启后数据不一致。升级到版本4.4.9或5.0.3。

MongoDB 4.4.8中的存储引擎bug可能导致在非干净关闭和重启后数据不一致。升级到版本4.4.9。

MongoDB 4.4.7、5.0.0和5.0.1中的存储引擎bug允许某些插入违反唯一索引约束。升级到版本4.4.8或5.0.2。

MongoDB 4.4.5中的存储引擎bug会导致启动时崩溃，并可能导致临时查询正确性问题。升级到版本4.4.6。

某些MongoDB 4.2+产品的备份快照可能发生损坏。

启用增量备份时，MongoDB 4.2.7可能存在缓冲区溢出，可能导致内存损坏。

内存管理bug可能导致在索引构建期间重启的副本集次要节点丢失文档和索引不一致。

当MongoDB从非干净关闭恢复时，恢复过程可能损坏已接收大小更改更新的文档。

内存管理bug可能导致失败的操作、进程崩溃以及可能持久化到磁盘的数据内存损坏。

我们已在MongoDB Compass中识别到一个bug，在特定条件下，通过Compass修改或删除文档可能会发生在预期不同的文档上。

在后台索引构建过程中，如果修改包含在索引规范中的字段，则可能在特定情况下导致不匹配的索引条目出现。这会影响使用受影响索引的查询。

在数据迁移期间，影响迁移数据块内的数据的插入和更新操作不会反映到接收分片，从而导致数据丢失。

在副本集中，如果复制写入时副节点干净关闭，则节点可能会将某些已复制的操作标记为成功应用，尽管它们尚未应用。

WiredTiger中的竞争条件可能阻止写操作立即对后续读操作可见，这可能导致各种问题，主要影响复制。

启用了均衡器（或存在手动数据块迁移）的分片集群，其中包含可能成为主节点的WiredTiger节点，如果在迁移的数据块上有大量写操作，可能会丢失对该数据块的写入。

在VMWare上运行的某些3.x Linux内核，使用由LVM管理的虚拟SCSI磁盘的MongoDB安装可能看到命名空间（.ns）文件损坏。

对文本索引字段的更新可能无法更新文本索引。因此，文本搜索可能无法匹配字段内容，导致搜索结果不正确。

在极少数情况下，mongos可能错误地报告写操作为成功。

在分片集群中的数据块迁移期间，如果数据块中的某个文档的大小在16,776,185到16,777,216字节（包含）之间，则迁移过程中可能会丢失一些文档。

如果在初始同步期间在同步源上执行写操作，则二级索引（即除_id之外的所有索引）可能在初始同步时损坏。

dbhash结果的缓存可能会导致过时值，这可能导致分片集群配置服务器之间出现不一致。