随着MongoDB开源社区的不断发展，MongoDB通过发布新版本为您提供更多优势特性，例如更快的性能、更好的安全性、更多的功能等。同时，MongoDB开源社区也陆续停止对低版本MongoDB的支持和维护，若您持续使用低版本MongoDB将会面临诸多挑战，甚至会引发一定的安全性、稳定性风险。
根据MongoDB官方的Lifecycle Schedules，MongoDB 4.4版本已于2024年2月正式EOL，云数据库 MongoDB 版团队建议您升级至更新的版本（包括5.0、6.0、7.0），便于获取更好的服务。
旧版本存在的风险和隐患
以下风险和隐患是云数据库 MongoDB 版团队根据长期的云数据库运维经验整理得出。
分片实例的孤立文档导致进行实例间数据迁移时校验不一致
受影响的版本及架构：4.2及以下版本的分片集群实例。
简要描述：在分片集群实例中，若未及时清理孤立文档，可能会导致在迁移数据时出现数据不一致的问题。
推荐版本：4.4及以上版本。
推荐理由：
当一个Chunk成功迁移到新的分片后，源分片中的该Chunk会延期删除。孤立文档通常是因为迁移过程中断而产生的。孤立文档并不会影响mongos节点上的正常业务请求，因为请求会经过配置服务器（ConfigServer）的路由数据检查。
从4.4版本开始，MongoDB实现了能够自恢复的Chunk迁移和孤立文档清理。就算节点出现异常，MongoDB也会自动恢复之前中断的迁移过程。您不再需要主动执行
cleanupOrphaned命令来清理孤立文档。您依然可以执行该命令来确认后台线程是否已经成功完成了相关库表内孤立文档的删除。更多信息，请参见cleanupOrphaned。
compact阻塞业务读写
受影响的版本及架构：4.2及以下版本实例。
简要描述：需要回收磁盘碎片的场景下，低版本实例执行compact命令会阻塞业务读写，而且compact操作不能被中断，只能重启，影响业务。
推荐版本：4.4及以上版本。
推荐理由：
从4.4版本开始，优化了compact的加锁行为，不再会阻塞业务正常的读写（CURD）操作，只会阻塞一些DDL操作（例如
createIndex、dropIndex等）。业务侧不再需要等到维护窗口期再来执行compact命令。更多信息，请参见回收磁盘碎片以提升磁盘利用率、compact Blocking。
说明如需回收磁盘碎片，建议您使用云数据库 MongoDB 版的空间分析功能回收磁盘碎片。
compact导致节点进入RECOVERING异常状态
受影响的版本及架构：4.2及以下版本实例（小版本低于4.2.18版本）。
简要描述：需要回收磁盘碎片的场景下，低版本实例执行compact命令会导致节点临时进入RECOVERING状态，如果持续时间过长，该节点会被阿里云MongoDB侧实例探活组件认定为节点不健康从而触发相应的重搭操作。
推荐版本：4.4及以上版本。
推荐理由：
从4.2.18版本开始，在mongod节点上执行compact命令将不再导致节点进入异常的RECOVERING状态，从而避免了节点不可用和上述非预期的重搭任务流问题。
更多信息，请参见回收磁盘碎片以提升磁盘利用率、compact RECOVERING。
说明如需回收磁盘碎片，建议您使用云数据库 MongoDB 版的空间分析功能回收磁盘碎片。
hidden节点物理备份带来的空间膨胀问题
受影响的版本及架构：4.2及以下版本的本地盘版实例。
简要描述：受限于物理备份的机制，备份上传期间磁盘文件大小依然在增长，长期积累会导致hidden节点磁盘空间膨胀。当发生节点故障或切换节点时，可能会触发磁盘使用率的误告警。
推荐版本：5.0及以上版本的云盘版实例。
推荐理由：
云盘版架构实例的全量备份是基于物理备份结合云盘快照的方式。从原理上缩短了需要在WiredTiger引擎侧维持备份检查点（Backup checkpoint）的时间，有效解决了hidden节点因备份而导致空间膨胀的问题。
此外，云盘版的快照备份以及基于快照备份的恢复具备更好的性能。当副本集实例的数据规模达到2 TB以上时，本地盘版实例的物理备份耗时久、失败率高、期间无法执行其他运维操作等问题也能得到解决。
分片实例重建同名库表时遇到残留路由数据的问题
受影响的版本及架构：4.4及以下版本的分片集群实例。
简要描述：分片集群实例上执行
dropDatabase命令后又重建同名库表时，由于ConfigServer节点上路由数据有残留，导致实例无法完整正常读写操作。推荐版本：5.0及以上版本。
推荐理由：
从5.0版本开始，MongoDB优化了
dropDatabase命令对于路由数据的处理，不再会导致路由数据的残留。在4.2及以下版本中，不仅需要用户侧重复执行dropDatabase命令，还需要额外在所有mongos上通过flushRouterConfig命令刷新路由信息，否则就会有残留数据导致问题。更多信息，请参见dropDatabase、flushRouterConfig。
默认writeConcern为{w:1}导致主从同步异常
受影响的版本及架构：5.0以下版本实例。
简要描述：如果业务写入太快，可能会导致从节点落后太多而进入RECOVERING的异常状态，降低实例可用性；也可能导致从节点落后太多而读不到预期的数据，使得部分读写分离的业务受损。而且这种状态下的增量备份也会受影响，导致无法按时间点恢复。
推荐版本：5.0及以上版本。
推荐理由：
从5.0版本开始，MongoDB将默认的writeConcern从原本的
{w:1}调整为了{w:"majority"}，即写入的数据需要被副本集内大部分节点确认后才返回成功，牺牲了少量性能换取更好的数据可靠性。解决了因为从节点落后太多而主节点被flowControl影响导致业务查询响应慢或者主节点异常进入ROLLBACK状态引起数据丢失的问题。对于写入性能要求比较高的场景，您依然可以将writeConcern设置为
{w:1}。更多信息，请参见Default Write Concern、setDefaultRWConcern。
Balancer均衡速度慢，横向扩缩容性能差，业务高峰期无法横向扩展
受影响的版本及架构：5.0以下版本实例。
简要描述：Balancer迁移速度无法提升，导致需要横向扩展的场景无法快速均衡数据，热点无法快速缓解，影响业务。
推荐版本：5.0及以上版本。
推荐理由：
从5.0版本开始，MongoDB新增了
chunkMigrationConcurrency和balancerMigrationsThrottlingMs两个可调整参数，用于调整Balancer的迁移并发度和性能。更多信息，请参见chunkMigrationConcurrency、balancerMigrationsThrottlingMs。
说明如果您的数据库实例已经是5.0版本却不支持这两个参数，您可以升级数据库小版本解决该问题。
分片实例数据不均衡而导致的负载不均
受影响的版本及架构：5.0及以下版本实例（小版本低于6.0.3版本）。
简要描述：Balancer按照分片间的Chunks数量来判断是否均衡，在存在Jumbo Chunk、Empty Chunks、热点数据的情况下会导致分片间的数据分布不均以及相应的负载不均问题。
推荐版本：6.0及以上版本。
推荐理由：
从6.0.3版本开始，Balancer会根据分片间数据量的差异均衡数据，而不是根据分片间Chunks数量的差异来均衡数据。从而有效解决了之前版本因为Jumbo Chunk、Empty Chunk等原因而导致数据、负载不均匀的问题。
更多信息，请参见MongoDB 6.0.3版本Balancer改动。
其他内核缺陷相关
版本 | 内核缺陷 | 风险级别 | 补充说明 |
MongoDB 3.4 | 中 | 【触发条件】：实例开启了读写分离。 【现象】：Secondary回放oplog时加全局锁导致业务读从节点时的慢请求。 | |
MongoDB 4.0 | 低 | 【触发条件】：Server侧的连接数突增。 【现象】：可能会遇到Sessions不足而触发断言，导致mongod节点异常，触发切换。 | |
MongoDB 3.6 ~ 4.2 | 低 | 【触发条件】：偶发。 【现象】：客户端收到类似 | |
MongoDB <= 4.2 | 低 | 【触发条件】：偶发， 【现象】：会导致mongos异常宕机，重启后自愈 | |
MongoDB 4.0 ~ 4.2 | 低 | 【触发条件】：偶发。 【现象】：服务端无法正确区分事务和retryable wirtes而导致请求失败报错。 | |
MongoDB 4.0 ~ 4.4 | 高 | 【触发条件】：长事务操作。 【现象】：wt cache eviction无法正常完成，dirty迅速上涨到>20%。处理超时事务清理的线程可能会卡住而导致请求延时大幅增加，业务受损。 | |
MongoDB 3.6 ~ 4.4 | 高 | 【触发条件】：CS节点90天未发生切换。 【现象】：CS上HMAC生产签名密钥的缺陷，导致mongos异常宕机无法自愈。 | |
MongoDB 4.0 ~ 4.4 | 中 | 【触发条件】：偶发。 【现象】：opContext触发断言错误，导致mongod异常，触发切换。 | |
MongoDB < 4.4 | 高 | 【触发条件】：Secondary后台创建索引过程中，oplog中又有DDL操作。 【现象】：DDL操作被阻塞，从节点无法提供服务。 | |
MongoDB < 4.4 | 中 | 【触发条件】：节点重启或初始化同步。 【现象】：节点recovery流程中WT引擎里对于history store的时序判断问题，会触发WT断言错误，mongod异常宕机。 | |
MongoDB 4.2 ~ 4.4 | 高 | 【触发条件】：实例开启了读写分离，从节点高负载。 【现象】：pthread互斥锁的争用导致从节点的read tickets耗尽，业务查询受损。 | |
MongoDB 4.2 ~ 4.4 | 中 | 【触发条件】：业务侧频繁listCollections。 【现象】：遇到底层CollectionCatalog互斥锁的问题，严重影响实例性能，业务受损。 | |
MongoDB <= 6.0 | 高 | 【触发条件】：小规格实例，建索引过程中出现过OOM。 【现象】：mongod反复重启无法自愈。副本集内2个节点均进入此状态时，整个副本集不可用。 | |
MongoDB <= 6.0 | 低 | 【触发条件】：新建TTL索引或调整过期时间后导致有大量过期文档。 【现象】：后台TTL线程会卡住无法自愈，导致TTL功能失效。 |
新版本的新特性及优化
版本 | 新特性/优化 | 补充说明 |
MongoDB 5.0 | 时序集合 | 从5.0版本开始，MongoDB可以更好地处理时序数据，适配车联网、物联网等广泛场景。 |
查询长时间运行快照 | 从5.0版本开始，MongoDB提供了读取历史快照的能力。阿里云MongoDB基于此能力扩展了按Key闪回的高效恢复手段。 | |
版本化API | 从5.0版本开始，MongoDB正式提供了版本化API的能力，通过将应用程序生命周期和数据库生命周期解耦，提供了完备的兼容性保证。用户无需担心升级数据库版本而带来的兼容性风险了。 | |
MongoDB 6.0 | changeStream若干优化 | 从6.0版本开始，ChangeStream包含了诸多优化：
|
join查询优化 | 从6.0版本开始，MongoDB分片实例也开始支持 | |
分片实例支持自动整理分片集合的磁盘碎片空间 | 从6.0版本开始，MongoDB分片实例支持通过 | |
时序集合若干优化 | 从6.0开始，时序集合包含了诸多优化：
| |
compact性能大幅提升 | 阿里云MongoDB在6.0版本的基础上，在WT引擎层对compact命令进行了全方位优化，大幅提升了compact的性能，同时也降低了compact执行期间受eviction压力而失败的概率。 | |
MongoDB 7.0 | 分片键分析 | 从7.0版本开始，支持基于采样查询（Sampled queries）的结果来分析集合的分片键是否合理，可以帮助您更好地设计Schema以及分片键、更合理使用分片架构。 |
可查询加密 （Queryable Encryption） | 从7.0版本开始，可查询加密使得敏感数据在其整个生命周期中（传输中、静止中、使用中、日志中和备份中）都是加密的，并且只在客户端解密。提供了更强大且全面的数据安全保障，有效避免被“拖库”的数据泄露风险。 | |
元数据一致性检查 | 从7.0版本开始，在数据库维护期或者异常（OOM或故障切换等）结束后能够主动发现潜在的元数据/索引不一致风险。 | |
ChangeStream支持超大变更事件 | 从7.0版本开始，新增了 | |
wt引擎动态限流 | 从7.0版本开始，MongoDB会自动动态调整WT存储引擎的事务并发度（之前默认是128）来实现限流的效果。缓解了之前版本中数据库异常后因请求堆积而导致雪崩的问题 |