将 MongoDB 升级到 2.4

在本页面

在一般情况下,从 MongoDB 2.2 升级到 2.4 是二进制兼容的“嵌入式”升级:关闭mongod实例,并用运行 2.4 的mongod实例替换它们。 但是 ,在尝试进行任何升级之前,请熟悉本文档的内容,尤其是升级分片集群的过程以及运行 2.4 后恢复到 2.2的注意事项。

升级建议和清单

升级时,请考虑以下事项:

  • 对于所有使用身份验证的部署,请先升级驱动程序(即 Client 端库),然后再升级mongod个实例。

  • 要升级到 2.4 分片群集,必须*遵循元数据升级过程升级。

  • 如果您使用的是 2.2.0,并且启用了authorization,则需要先升级到 2.2.1,然后再升级到 2.4. 参见在启用 auth 的情况下运行的 2.2.0 部署的滚动升级限制

  • 如果您有在 2.4 之前创建的system.users个文档(即针对authorization),则必须确保 any *数据库中system.users集合中user字段没有重复的值。如果您的文档中包含重复的用户字段,则必须在升级之前将其删除。

有关更多信息,请参见Security Enhancements

将独立 mongod 实例升级到 MongoDB 2.4

将副本集从 MongoDB 2.2 升级到 MongoDB 2.4

您可以通过分别升级成员来执行集合的“滚动”升级,从而升级到 2.4,而其他成员则可以最大程度地减少停机时间。使用以下过程:

  • 通过关闭mongod并将 2.2 二进制文件替换为 2.4 二进制文件,一次升级集合secondary的成员。升级mongod实例后,请 await 成员恢复到SECONDARY状态,然后再升级下一个实例。要检查成员的状态,请在mongo shell 中发出rs.status()

  • 使用mongo shell 方法rs.stepDown()降级primary以允许正常的failover过程。 rs.stepDown()加快了故障转移过程,比直接关闭主数据库更可取。

rs.status()的输出所示,一旦主数据库降级并且另一个成员已处于PRIMARY状态,请关闭先前的主数据库,并将mongod二进制文件替换为 2.4 二进制文件并开始新的过程。

Note

副本集故障转移不是即时的,但是将使该集不可用于读取或接受写入,直到故障转移过程完成为止。通常,这需要 10 秒钟或更长时间。您可能希望在 sched 义的维护时段内计划升级。

将分片群集从 MongoDB 2.2 升级到 MongoDB 2.4

Important

如果集群的所有成员当前正在运行 2.2 实例,则仅将分片集群升级到 2.4. 运行 2.0 的分片群集的唯一受支持的升级路径是通过 2.2.

Overview

sharded cluster从 MongoDB 2.2 版升级到 2.4(或 2.3)要求您使用--upgrade选项运行 2.4 mongos,如本过程所述。升级过程不需要停机。

升级到 MongoDB 2.4 后,现有集群中所有集合和块的元数据都会增加新纪元。即使 2.2 不需要纪元,MongoDB 2.2 进程也能够处理纪元。此过程仅适用于从 2.2 版升级。 MongoDB 的早期版本无法正确处理历元。有关更多信息,请参见集群元数据升级

完成元数据升级后,您可以完全升级集群的组件。在禁用平衡器的情况下:

  • 升级集群中的所有mongos实例。

  • 升级所有 3 个mongod配置服务器实例。

  • 一次升级每个分片的mongod个实例。

有关更多信息,请参见升级分片群集组件

群集元数据升级

Considerations

注意群集升级过程的以下属性:

  • 在开始升级之前,请确保config database的文件系统上的可用空间量至少是config database数据文件当前使用的空间量的 4 到 5 倍。

此外,请确保config database中的所有索引均为{v:1}索引。如果关键索引是{v:0}索引,则由于{v:0}格式的已知问题,块拆分可能会失败。 {v:0}索引存在于使用 MongoDB 2.0 或更早版本创建的集群上。

元数据升级的持续时间取决于执行升级的节点与三个配置服务器之间的网络延迟。确保升级过程和配置服务器之间的 await 时间短。

升级后的配置数据库将需要比以前更多的存储空间,以制作config.chunksconfig.collections集合的备份和工作副本。与往常一样,如果存储需求增加,则mongod可能需要预分配其他数据文件。有关更多信息,请参见如何获取有关数据库存储使用的信息?

元数据升级过程

迁移到 2.4 时,对分片群集的元数据格式的更改(存储在config database中)需要特殊的元数据升级过程。

执行此过程时,请勿执行修改元数据的操作。有关禁止的操作的示例,请参见将分片群集从 MongoDB 2.2 升级到 MongoDB 2.4

  • 在开始升级之前,请确保config database的文件系统上的可用空间量至少是config database数据文件当前使用的空间量的 4 到 5 倍。

此外,请确保config database中的所有索引均为{v:1}索引。如果关键索引是{v:0}索引,则由于{v:0}格式的已知问题,块拆分可能会失败。 {v:0}索引存在于使用 MongoDB 2.0 或更早版本创建的集群上。

元数据升级的持续时间取决于执行升级的节点与三个配置服务器之间的网络延迟。确保升级过程和配置服务器之间的 await 时间短。

要检查索引的版本,请使用db.collection.getIndexes()

如果 配置数据库上的任何索引{v:0},则应通过连接到mongos来重建那些索引,或者:使用db.collection.reIndex()方法重建所有索引,或者先使用db.collection.dropIndex()然后再使用db.collection.ensureIndex()删除并重建特定索引。如果需要将_id索引升级到{v:1},请使用db.collection.reIndex()

您可能在群集中的其他数据库上具有{v:0}索引。

Optional

为了在升级过程中提高安全性,您可以使用mongodump或其他备份工具来备份配置数据库。

  • 确保分片群集中没有任何活动的版本 2.0 mongodmongos进程。自动升级过程会检查 2.0 个过程,但是网络可用性可能会阻止进行明确的检查。在停止或升级 2.0 版mongos进程后,请 await5 分钟,以确认没有任何活动。

  • 使用configDB指向分片群集的config servers并使用--upgrade选项来启动一个 2.4 mongos进程。升级过程发生在升级过程成为守护程序之前(即--fork之前)。

您可以将现有的mongos实例升级到 2.4,也可以启动一个新的 mongos 实例,该实例可以访问所有配置服务器(如果需要避免重新配置生产mongos)。

使用类似于以下命令的命令启动mongos

mongos --configdb <config servers> --upgrade

如果没有--upgrade选项 2.4 mongos进程将无法启动,直到升级过程完成。

升级将防止在升级过程中发生任何块移动或分裂。如果有很多分片集合,或者其他失败的进程持有过时的锁,则获取所有集合的锁可能需要几秒钟或几分钟的时间。请参阅日志以获取进度更新。

  • mongos进程成功启动后,升级完成。如果mongos进程无法启动,请检查日志以获取更多信息。

如果在升级期间mongos终止或失去与配置服务器的连接,则可以始终安全地重试升级。

但是,如果在短关键部分内升级失败,则mongos将退出并报告升级将需要手动干预。要 continue 升级过程,您必须遵循关键部分中断后重新同步步骤。

Optional

如果mongos日志显示正在 await 升级锁定的升级,则先前的升级过程可能仍处于活动状态或已异常结束。 15 分钟没有任何远程活动后,mongos将强制执行升级锁定。如果可以验证没有正在运行的升级进程,则可以连接到 2.2 mongos进程并手动强制锁定:

mongo <mongos.example.net>
db.getMongo().getCollection("config.locks").findOne({ _id : "configUpgrade" })

如果此文档的process字段中指定的过程是可验证的脱机版本,请运行以下操作以强制锁定。

db.getMongo().getCollection("config.locks").update({ _id : "configUpgrade" }, { $set : { state : 0 } })

如果您对其他升级操作的活动有任何疑问,则 awaitmongos验证锁定是否处于活动状态总是更安全的。除了configUpgrade之外,mongos可能还需要 await 特定的收集锁。不要强行使用特定的收集锁。

  • 无需 --upgrade选项即可升级并重新启动分片群集中的其他mongos进程。

有关更多信息,请参见升级分片群集组件

升级后,不要将 2.0 版 MongoDB 进程引入分片集群。这样可以将旧的元数据格式重新引入配置服务器。通过此升级过程进行的元数据更改将有助于防止在将来的 MongoDB 版本中因跨版本不兼容而引起的错误。

关键部分中断后重新同步

在将更改应用于元数据的升级的短暂关键阶段中,网络中断不太可能但有可能阻止所有三台配置服务器验证或修改数据。如果发生这种情况,则必须重新同步config servers,并且在启动新的mongos进程时可能会出现问题。 sharded cluster将保持可访问状态,但要避免所有群集元数据更改,直到重新同步配置服务器。更改元数据的操作包括:添加分片,删除数据库和删除集合。

Note

仅在升级的短暂关键部分期间如果某些东西(例如网络,电源等)中断升级过程,请执行以下步骤。请记住,您可以始终尝试元数据升级过程

要重新同步配置服务器:

  • 关闭分片群集中的balancer并停止所有元数据操作。如果您正在升级过程中(将分片群集从 MongoDB 2.2 升级到 MongoDB 2.4),则已经禁用了均衡器。

  • 关闭三个配置服务器中的两个,最好关闭configDB字符串中列出的最后两个。例如,如果您的configDB字符串是configA:27019,configB:27019,configC:27019,请关闭configBconfigC。关闭最后两个配置服务器可确保大多数mongos实例将不间断地访问群集元数据。

  • mongodump活动配置服务器(configA)的数据文件。

  • 将已停用的配置服务器(configBconfigC)的数据文件移动到备份位置。

  • 创建新的空data directories

  • 重新启动已禁用的配置服务器,其中--dbpath指向现在为空的数据目录,而--port指向备用端口(例如27020)。

  • 使用mongorestore将禁用文档上的数据文件从活动配置服务器(configA)重新填充到新端口(configB:27020,configC:27020)上重新启动的配置服务器。这些配置服务器现在已重新同步。

  • 在旧端口上重新启动还原的配置服务器,将端口重置回旧设置(configB:27019configC:27019)。

  • 在某些情况下,连接池可能会导致虚假故障,因为mongos仅在尝试使用后才禁用旧连接。 2.4 解决了此问题,但要避免在 2.2 版中出现此问题,可以重新启动所有mongos实例(一个一个,一个实例,以避免停机),并在重新启动每个replica set primaries碎片之前使用rs.stepDown()方法。

  • 分片群集现在已完全重新同步;但是,在再次尝试升级过程之前,必须使用 2.2 mongos版本手动重置升级状态。首先使用mongoShell 连接到 2.2 mongos

mongo <mongos.example.net>

然后,使用以下操作重置升级过程:

db.getMongo().getCollection("config.version").update({ _id : 1 }, { $unset : { upgradeState : 1 } })

升级分片群集组件

成功完成元数据升级程序中描述的元数据升级过程并启动 2.4 mongos实例后,您可以升级 MongoDB 部署中的其他过程。

在仍然禁用平衡器的情况下,请按以下 Sequences 升级分片群集的组件:

  • 以任何 Sequences 升级群集中的所有mongos实例。

  • 升级所有 3 个mongod配置服务器实例,并升级mongos --configdb参数* last 中的 first *系统。

  • 一次升级每个分片,在运行replSetStepDown之前先升级mongod个从属,并升级每个分片的主。

此过程完成后,您现在可以重新启用平衡器

在启用 auth 的情况下运行的 2.2.0 部署的滚动升级限制

MongoDB 不能支持混合了 2.2.0 和 2.4.0 或更高版本组件的部署。在具有 2.4 系列进程的混合部署中,可以*存在 MongoDB 2.2.1 版和更高版本的进程。因此,您无法执行从 MongoDB 2.2.0 到 MongoDB 2.4.0 的滚动升级。要升级具有 2.2.0 组件的群集,请使用以下过程之一。

  • 将所有 2.2.0 进程进行滚动升级到最新的 2.2 系列版本(例如 2.2.3),以便部署中没有早于 2.2.1 的进程。如果部署中没有 2.2.0 进程,请滚动升级到 2.4.0.

  • 停止集群中的所有进程。将所有进程升级到 MongoDB 的 2.4 系列版本,然后同时启动所有进程。

从 2.3 升级到 2.4

如果您使用的是 2.3 或 2.4-rc(候选版本)系列中的mongod,则可以安全地将这些数据库转换为 2.4.0 或更高版本; 但是,如果您在 v2.4-rc2 之前使用mongod创建了2dspheretext索引,则需要重建这些索引。例如:

db.records.dropIndex( { loc: "2dsphere" } )
db.records.dropIndex( "records_text" )

db.records.ensureIndex( { loc: "2dsphere" } )
db.records.ensureIndex( { records: "text" } )

将 MongoDB 从 2.4 降级到以前的版本

在某些情况下,2.4 和 2.2 mongod所使用的数据文件的磁盘格式是兼容的,您可以根据需要进行升级和降级。但是,2.4 中的一些新功能与以前的版本不兼容:

  • 2dsphere索引与 2.2 和更早的mongod实例不兼容。

  • text索引与 2.2 和更早的mongod实例不兼容。

  • 使用hashed索引作为分片键与 2.2 及更早版本的mongos实例不兼容。

  • hashed索引与 2.0 和更早的mongod实例不兼容。

Important

使用散列的分片键分片的集合不应使用 2.2 mongod实例,这些实例不能正确地支持这些集合的集群操作。

如果您完成了分片群集的元数据升级,则可以安全地降级到 2.2 MongoDB 进程。 **完成升级程序后,请勿使用 2.0 进程。

Note

在分片群集中,一旦完成元数据升级过程,就不能在同一群集中使用 2.0 mongodmongos实例。

如果完成元数据升级,则可以按任何 Sequences 安全地降级组件。再次升级时,请始终先升级mongos个实例,再升级mongod个实例。

请勿 在具有 2.2 个组件的群集中创建2dspheretext索引。

注意事项和兼容性

如果您升级到 MongoDB 2.4,然后需要使用相同的数据文件运行 MongoDB 2.2,请考虑以下限制。

  • 如果使用hashed索引作为分片键索引(仅在 2.4 下可用),则您将无法查询此分片集合中的数据。此外,2.2 mongos无法为分片键索引使用hashed索引为分片的集合正确地路由插入操作:使用 2.2 mongos插入的任何数据都不会到达正确的分片,并且将来的查询将无法访问。

  • 如果从不创建2dspheretext索引,则可以在给定数据集的 2.4 和 2.2 mongod之间移动;但是,在使用 2.4 mongod创建第一个2dspheretext索引后,您将需要使用--upgrade选项运行 2.2 mongod并删除任何2dspheretext索引。

升级和降级步骤

基本降级和升级

除以下所述 外,在 2.2 和 2.4 之间移动是一种直接替代:

mongod --dbpath /var/mongod/data --shutdown

/var/mongod/data替换为您的 MongoDB dbPath

  • 使用相同的dbPath设置启动新的mongod进程,例如:
mongod --dbpath /var/mongod/data

/var/mongod/data替换为您的 MongoDB dbPath

创建 2dsphere 或文本索引后降级到 2.2

如果在运行 2.4 mongod实例时创建了2dspheretext索引,则可以随时通过使用--upgrade选项启动2.2 mongod来降级:

mongod --dbpath /var/mongod/data/ --upgrade

然后,您将需要使用db.collection.dropIndex()删除任何现有的2dspheretext索引,例如:

db.records.dropIndex( { loc: "2dsphere" } )
db.records.dropIndex( "records_text" )

Warning

--upgrade将在您创建2dspheretext索引的任何数据库上运行repairDatabase,这些数据库将重建* all *索引。

升级/降级操作故障排除

如果不使用--upgrade,则当您尝试启动 2.2 mongod并且创建了2dspheretext索引时,mongod将返回以下消息:

'need to upgrade database index_plugin_upgrade with pdfile version 4.6, new version: 4.5 Not upgrading, exiting'

在运行 2.4 时,要检查 MongoDB 数据库的数据文件版本,请在 Shell 中使用以下操作:

db.getSiblingDB('<databasename>').stats().dataFileVersion

在创建2dspheretext索引后, 2.2 和 2.4 的主要数据文件[1]版本均为4,2.2 的次要数据文件版本为5和 2.4 的次要数据文件版本为6

[1]数据文件版本(即pdfile version)是独立的,并且与 MongoDB 的发行版本无关。