将MongoDB升级到2.4
在一般情况下，从MongoDB 2.2升级到2.4是一个二进制兼容的“下拉式”升级：关闭mongod实例，并将其替换为运行2.4的mongod实例。但是，在尝试任何升级之前，请熟悉本文档的内容，特别是升级分片集群以及运行2.4后恢复到2.2。
升级建议和核对清单
升级时，请考虑以下几点：
对于所有使用身份验证的部署，在升级
mongod实例之前，请升级驱动程序（即客户端库）。要升级到2.4分片集群，必须按照元数据升级程序。
如果您使用的是2.2.0并在启用
authorization的情况下运行，则需要先升级到2.2.1，然后升级到2.4。看启用auth运行的2.2.0部署的滚动升级限制。如果您有在2.4之前创建的
system.users文档（即authorization），则必须确保任何数据库中的system.users集合中没有user字段的重复值。如果您确实有带有重复用户字段的文档，则必须在升级之前删除它们。有关更多信息，请参阅安全增强功能。
将独立mongod实例升级到MongoDB 2.4
- 从2.4系列中下载最新版本的二进制文件MongoDB下载页面。有关更多信息，请参阅Install MongoDB。
- 关闭您的
mongod实例。将现有的二进制文件替换为2.4mongod二进制文件，然后重新启动mongod。
将副本集从MongoDB 2.2升级到MongoDB 2.4
您可以通过单独升级成员来执行套装的“滚动”升级到2.4，而其他成员可以最大限度地减少停机时间。请按照以下规程操作：
1、通过关闭mongod并用2.4二进制文件替换2.2二进制文件，一次升级一个次要成员。升级mongod实例后，请等待成员恢复到SECONDARY状态，然后再升级下一个实例。要检查成员的状态，请在mongo shell中发出rs.status（）。
2、使用mongo shell方法rs.stepDown（）逐步关闭主服务器，以允许正常的故障转移过程。rs.stepDown（）加快了故障转移过程，比直接关闭主服务器更可取。
一旦主制下台，另一个成员假设PRIMARY状态，如rs.status()输出所观察到的那样，关闭上一个主制文件，用2.4二进制文件替换mongod二进制文件，并开始新进程。
笔记：
复制集故障转移不是即时的，但将使该集无法读取或接受写入，直到故障转移过程完成。通常这需要10秒或更长时间。您可能希望在预定义的维护窗口内计划升级。
将分片集群从MongoDB 2.2升级到MongoDB 2.4
重要：
只有当集群的所有成员当前都在运行2.2的实例时，才能将分片集群升级到2.4。运行2.0的分片集群唯一支持的升级路径是通过2.2。
一览表
将分片集群从MongoDB版本2.2升级到2.4（或2.3）需要使用本过程中描述的--upgrade选项运行2.4 mongos。升级过程不需要停机。
MongoDB 2.4的升级为现有集群中所有集合和块的元数据增加了纪元。MongoDB 2.2进程能够处理时代，尽管2.2不需要它们。本规程仅适用于从2.2版本升级。早期版本的MongoDB无法正确处理纪元。看集群元数据升级了解更多信息。
完成元数据升级后，您可以完全升级集群的组件。停用平衡器后：
看升级分片集群组件了解更多信息。
集群元数据升级
注意事项
谨防集群升级过程的以下属性：
在开始升级之前，请确保配置文件系统中配置数据库的可用空间至少是配置数据库数据文件当前使用的空间量的4到5倍。
此外，请确保配置数据库中的所有索引都是
{v:1}索引。如果关键索引是{v:0}索引，则由于{v:0}格式的已知问题，块分割可能会失败。{v:0}索引存在于使用MongoDB 2.0或更低版本创建的集群中。元数据升级的持续时间取决于执行升级的节点和三个配置服务器之间的网络延迟。确保升级过程和配置服务器之间的低延迟。
在升级过程中，您无法更改收集元数据。例如，在升级期间，不要执行：
sh.enableSharding()，sh.shardCollection()，sh.addShard()，db.createCollection()，db.collection.drop()，db.dropDatabase()，- 创建数据库的任何操作，或
- 以任何方式修改集群元数据的任何其他操作。有关分片命令的完整列表，请参阅分片参考。但是，请注意，并非分页引用页面上的所有命令都会修改集群元数据。
一旦您升级到2.4并完成升级过程，请勿在集群中使用2.0
mongod和mongos流程。2.0进程可能会将旧的元数据格式重新引入集群元数据。
升级后的配置数据库将比以前需要更多的存储空间，才能对config.chunks和config.collections集合进行备份和工作副本。一如既往，如果存储需求增加，mongod可能需要预先分配其他数据文件。看看我如何获得有关数据库存储使用的信息？了解更多信息。
元数据升级程序
更改存储在配置数据库中的分片集群的元数据格式，在移动到2.4时需要特殊的元数据升级过程。
在执行此过程时，请勿执行修改元数据的操作。看将分片集群从MongoDB 2.2升级到MongoDB 2.4禁止操作的例子。
在开始升级之前，请确保配置文件系统中配置数据库的可用空间至少是配置数据库数据文件当前使用的空间量的4到5倍。
此外，请确保配置数据库中的所有索引都是
{v:1}索引。如果关键索引是{v:0}索引，则由于{v:0}格式的已知问题，块分割可能会失败。{v:0}索引存在于使用MongoDB 2.0或更低版本创建的集群中。元数据升级的持续时间取决于执行升级的节点和三个配置服务器之间的网络延迟。确保升级过程和配置服务器之间的低延迟。
要检查索引的版本，请使用
db.collection.getIndexes()。如果配置数据库上的任何索引是
{v:0}，您应该通过连接到mongos来重建这些索引，并且：使用db.collection.reIndex()方法重建所有索引，或使用db.collection.dropIndex()和thendbdb.collection.ensureIndex()删除并重建特定索引。如果您需要将_id索引升级到{v:1}请使用db.collection.reIndex()。集群中的其他数据库上可能有
{v:0}索引。-
笔记:
选修科目
为了在升级期间获得额外的安全性，您可以使用
mongodump或其他备份工具。 确保没有2.0版本的
mongod或mongos进程在分片集群中仍然活跃。自动升级流程检查2.0个进程，但网络可用性可能会阻止最终检查。在停止或升级2.0版本的mongos进程后等待5分钟，以确认没有进程仍然有效。使用
configDB指向分片集群的配置服务器和--upgrade选项启动单个2.4mongos进程。升级过程发生在流程成为守护进程之前（即--fork之前）。您可以将现有的
mongos实例升级到2.4，或者如果您需要避免重新配置生产mongos您可以启动一个新的mongos实例，该实例可以到达所有配置服务器。以类似于以下命令启动
mongos：mongos --configdb <config servers> --upgrade如果没有
--upgrade选项2.4，在升级过程完成之前，mongos进程将无法启动。升级将防止在升级过程中发生任何块移动或分裂。如果有很多碎片集合，或者有其他失败过程保存的陈旧的锁，获取所有集合的锁可能需要几秒钟或几分钟。有关进度更新，请参阅日志。
当
mongos过程成功启动时，升级就完成了。如果mongos进程无法启动，请查看日志以获取更多信息。如果
mongos在升级期间终止或失去与配置服务器的连接，您可以随时安全地重试升级。但是，如果升级在简短的关键部分失败，它们将退出并报告升级需要手动干预。要继续升级流程，您必须按照关键部分中断后重新同步程序。
笔记:
选修科目
如果
mongos日志显示等待升级锁的升级，则之前的升级过程可能仍然有效或可能异常结束。在15分钟后，没有远程活动后，mongos将强制升级锁定。如果您可以验证没有正在运行的升级进程，您可以连接到2.2mongos进程并手动强制锁定：mongo <mongos.example.net>db.getMongo().getCollection("config.locks").findOne({ _id : "configUpgrade" })如果本文档
process字段中指定的进程可验证离线，请运行以下操作以强制锁定。db.getMongo().getCollection("config.locks").update({ _id : "configUpgrade" }, { $set : { state : 0 } })如果您对另一个升级操作的活动有任何疑问，等待
mongos验证锁是否处于非活动状态总是更安全。除了configUpgrade外，mongos可能需要等待特定的集合锁。不要强制使用特定的收集锁。升级并重新启动分片集群中的其他
mongos进程，而无需--upgrade选项。看升级分片集群组件了解更多信息。
重新启用平衡器。您现在可以执行修改集群元数据的操作。
升级后，不要在分片集群中引入2.0版本的MongoDB进程。这可以将旧的元数据格式重新引入配置服务器。此升级过程所做的元数据更改将有助于防止未来版本的MongoDB中因跨版本不兼容而导致的错误。
关键部分中断后重新同步
在升级中对元数据应用更改的简短关键部分，网络中断不太可能但可能阻止所有三台配置服务器验证或修改数据。如果发生这种情况，配置服务器必须重新同步，并且启动newmongos进程可能会出现问题。分片集群将保持可访问性，但在重新同步配置服务器之前，请避免所有集群元数据更改。更改元数据的操作包括：添加碎片、删除数据库和删除集合。
笔记：
仅当某些东西（例如网络、电源等）在升级的简短关键部分中断升级过程时，才执行以下过程。请记住，您可以随时安全地尝试元数据升级过程。
要重新同步配置服务器：
关闭分片集群中的平衡器，并停止所有元数据操作。如果您正在升级过程中（将分片集群从MongoDB 2.2升级到MongoDB 2.4），您已经禁用了平衡器。
关闭三台配置服务器中的两台，最好是
configDB字符串中列出的最后两台。例如，如果您的configDB字符串是configA:27019,configB:27019,configC:27019，请关闭configB和configC。关闭最后两个配置服务器可以确保大多数mongos实例可以不间断地访问集群元数据。mongodump活动配置服务器（configA）的数据文件。将停用的配置服务器（
configB和configC）的数据文件移动到备份位置。创建新的空数据目录。
使用
mongorestore将禁用文档上的数据文件从活动配置服务器（configA）重新填充到新端口上重新启动的配置服务器（configB:27020,configC:27020）。这些配置服务器现在已重新同步。在旧端口上重新启动恢复的配置服务器，将端口重置为旧设置（
configB:27019和configC:27019）。在某些情况下，连接池可能会导致虚假故障，因为它们仅在尝试使用后才禁用旧连接。2.4修复了这个问题，但为了在2.2版本中避免这个问题，您可以重新启动所有
mongos实例（一个接一个，以避免停机），并在重新启动每个碎片副本集原语之前使用rs.stepDown()方法。现在，分片群集已完全重新同步;然而在你再次尝试升级过程之前，你必须使用2.2版本的mongos手动重置升级状态.首先使用mongo shell连接到2.2 mongos：
mongo <mongos.example.net>然后，使用以下操作来重置升级过程：
db.getMongo().getCollection("config.version").update({ _id : 1 }, { $unset : { upgradeState : 1 } })最后，请重试升级流程，如将分片集群从MongoDB 2.2升级到MongoDB 2.4。
升级分片集群组件
在您成功完成元数据升级程序，2.4 mongos实例启动，您可以升级MongoDB部署中的其他进程。
当平衡器仍然处于禁用状态时，请按以下顺序升级分片集群的组件：
- 以任何顺序升级集群中的所有
mongos实例。 - 升级所有3个
mongod配置服务器实例，最后升级mongos --configdb参数中的第一个系统。 - 升级每个碎片，一次一个，在运行
replSetStepDown之前升级mongod次要，并升级每个碎片的主。
完成此过程后，您现在可以重新启用平衡器。
在启用auth的情况下运行的2.2.0部署的滚动升级限制
MongoDB不能支持混合2.2.0和2.4.0或更高版本的部署。MongoDB 2.2.1版本及更高版本的进程可以存在于2.4系列进程的混合部署中。因此，您无法执行从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创建了2dsphere或text索引，则需要重建这些索引。例如：
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实例不兼容。
重要；
使用哈希碎片键分片的集合不应使用2.2
mongod实例，这不能正确支持这些集合的集群操作。
如果您已完成分片集群的元数据升级，您可以安全地降级到2.2 MongoDBprocesses。完成升级规程后，请勿使用 2.0 流程。
笔记：
在分片集群中，一旦您完成了元数据升级程序，您不能在同一集群中使用2.0
mongod或mongos实例。如果您完成元数据升级，您可以安全地按任何顺序降级组件。再次升级时，请务必在
mongod实例之前升级mongos实例。不要在包含2.2个组件的集群中创建
2dsphere或text索引。
注意事项和兼容性
如果您升级到MongoDB 2.4，然后需要使用相同的数据文件运行MongoDB 2.2，请考虑以下限制。
- 如果您使用
hashed索引作为分片键索引，这只能在2.4下使用，您将无法查询此分片集合中的数据。此外，2.2个mongos无法正确路由使用hashed索引的集合的插入操作：您使用2.2mongos插入的任何数据都不会到达正确的碎片上，并且无法通过未来的查询访问。 - 如果您从未创建
2dsphere或text索引，您可以在给定数据集的2.4和2.2mongod之间移动；但是，在使用2.4mongod创建第一个2dsphere或text索引后，您需要使用--upgrade选项运行2.2mongod，并删除任何2dsphere或text索引。
升级和降级程序
基本降级和升级
除下文所述外，在2.2和2.4之间移动是一种掉落的替换：
使用
--shutdown选项停止现有的mongod如下：mongod --dbpath /var/mongod/data --shutdown将
/var/mongod/data为MongoDBdbPath。-
mongod --dbpath /var/mongod/data将
/var/mongod/data为MongoDBdbPath。
创建2dsphere或text索引后降级到2.2
如果您在运行2.4 mongod实例时创建了2dsphere或文本索引，您可以随时降级，方法是使用--upgrad选项启动2.2 mongod，如下所示：
mongod --dbpath /var/mongod/data/ --upgrade
然后，您需要使用db.collection.dropIndex()删除任何现有的2dsphere或text索引，例如：
db.records.dropIndex( { loc: "2dsphere" } )
db.records.dropIndex( "records_text" )
警告：
--upgrade将在您创建2dsphere或text索引的任何数据库上运行repairDatabase，该数据库将重建所有索引。
对升级/降级操作进行故障诊断
如果您不使用--upgrade，当您尝试启动2.2 mongod并创建2dsphere或text索引时，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
在创建2dsphere或text索引后，2.2和2.4的主要数据文件[1]版本为4，2.2的次要数据文件版本为5，2.4的次要数据文件版本为6。
| [1] | 数据文件版本（即pdfile version）是独立的，与MongoDB的发布版本无关。 |
|---|---|
译者：韩鹏帅 参见