将 MongoDB 升级到 2.4

在本页面

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

升级建议和清单

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

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

将独立 mongod 实例升级到 MongoDB 2.4

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

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

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 的早期版本无法正确处理历元。有关更多信息,请参见集群元数据升级

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

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

群集元数据升级

Considerations

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

此外,请确保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中的所有索引均为{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或其他备份工具来备份配置数据库。

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

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

mongos --configdb <config servers> --upgrade

如果没有--upgrade选项 2.4 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 特定的收集锁。不要强行使用特定的收集锁。

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

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

关键部分中断后重新同步

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

Note

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

要重新同步配置服务器:

mongo <mongos.example.net>

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

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

升级分片群集组件

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

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

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

在启用 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.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 中的一些新功能与以前的版本不兼容:

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,请考虑以下限制。

升级和降级步骤

基本降级和升级

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

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

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

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 的发行版本无关。
首页