基础知识：MongoDB生命周期的点点滴滴

MongoDB 3.6的生命周期即将在今年4月份结束。借机会顺便说一下关于MongoDB生命周期的点点滴滴。

版本号

先解释下MongoDB的版本号。MongoDB的版本号分为3位：主版本.次版本.修订号。

• 主版本：当有重大更新时更新主版本号。例如支持WT引擎时主版本号从2升级到3；支持事务功能时从3升级到4；
• 次版本：发布新功能时更新次版本号。以奇数次版本号作为开发版，给大家尝鲜用，但不应用于生产环境；以偶数次版本号作为稳定版，适合生产环境使用。这就是为什么大家在下载网站上只看到4.0，4.2，4.4而无法找到4.1，4.3，4.5的原因。
• 修订号：每隔一定时间发布一次，包含近期内所有的bugfix。修订号不做任何功能上的更新，只用于发布bugfix。所以只要主/次版本号一致时，更新修订号可以完全向前兼容。

主/次版本基本上保持一年一次的更新频率，修订号不定期发布。

生命周期结束意味着什么？

一个版本（注意这里说的版本是指主/次版本）的生命周期结束意味着不再发布基于该版本的任何更新，即使发现新的bug也不再修复，但你仍可以继续使用。使用生命周期已结束的版本对生产环境存在较大的风险，应尽快更新到仍在生命周期内的版本。

生命周期多久结束？

原则上每个版本的生命周期会在下一个版本发布后的18个月内结束。有点绕对吗？简化一下，由于每个版本间隔一年发布，所以算下来每个版本的生命周期大约是2年半。也存在特殊情况，比如3.6发布后仅仅半年4.0就发布了。但这主要是为了将发布时间从圣诞节期间调整到年中，所以以后基本也不再会有这种情况发生。每个版本具体的过期时间可以在Support Policy中找到（https://www.mongodb.com/support-policy）。跟其他数据库产品的过期时间比起来，MongoDB的生命周期好像比较短，这是什么呢？答案是：相比其他数据库，MongoDB是一个新兴数据库，发展也就10多年时间，还处在高速发展进化的过程中。如果对一个版本支持很长时间，势必需要将过多的人力投入在旧版本支持上，这会阻碍MongoDB演化的速度。试想一个bug如果需要在n个分支上同时修复，是不是需要花更多的时间呢？再者在敏捷盛行的今天，版本更新都以月甚至日计，对于提供就地更新、在线更新的MongoDB来说不应该是个很大的问题。

如何更新版本？

每个主/次版本在发布时都会附带Release Notes（例如4.4 Release Notes: https://docs.mongodb.com/manual/release-notes/4.4/），描述了该版本中有哪些更新。读起来可能会有些枯燥，所以不妨等着每年官方、社区组织的新版本功能发布会更直观些。在Release Notes下面会有Compatibility Changes（重要），告诉你这个版本哪些功能与之前的版本不兼容了，这些是更新前需要在应用端考虑的问题。升级前务必阅读！另一件必须要完成的事情是升级驱动程序。驱动程序的在线文档中会注明驱动版本和MongoDB版本的支持关系，参考可以获得应该使用的版本。如果使用旧版本的驱动连接新版本数据库，轻则无法使用新功能，重则可能出现运行时错误。所以驱动升级也是必不可少的步骤。最后需要参考的是不同集群的升级步骤文档，包括：

• Upgrade a Standalone to x.x
• Upgrade a Replica Set to x.x
• Upgrade a Sharded Cluster to x.x

根据自己情况选择即可。通常这里进行的叫做“滚动升级”，即各个节点逐一升级。所以在升级过程中整个集群对外是始终可用的，除了有几秒的只读以外。最后的最后，文档中也提供了降级的办法，参考“Downgrade x.x to x.x”

写在最后

MongoDB的版本更新尽管不简单，也远没有你想象的复杂。虽然文档看上去比较长，但那是考虑了所有边缘情况的前提下，通常很多可能与你无关。把握规则，通读文档，最后多玩几次，都不在话下。

作者：张耀星

MongoDB中文社区常委会委员，论坛联席主席MongoDB公司北亚区首席技术咨询服务顾问。在MongoDB的开发、应用和咨询服务方面，拥有多年的丰富实践经验。

作为MongoDB认证专家，曾经为不同行业的各类大型客户提供过培训、性能调优、架构设计等各类技术及咨询服务，颇得广大客户信任。