参考 > 发行说明 > MongoDB 2.4发行说明 > 将MongoDB升级到2.4
在本页面
通常,从MongoDB 2.2升级到2.4是二进制兼容的“嵌入式”升级:关闭mongod
实例并用mongod
运行2.4 的实例替换它们。但是,在尝试进行任何升级之前,请熟悉本文档的内容,尤其是升级分片群集的过程以及在运行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
),则必须
确保任何数据库中集合中
的user
字段都没有重复的值。如果确实有带有重复用户字段的文档,则必须在升级之前将其删除。system.users
有关更多信息,请参见安全性增强。
mongod
实例升级到MongoDB 2.4¶mongod
实例。将现有的二进制文件替换为2.4 mongod
二进制文件,然后重新启动mongod
。您可以通过分别升级成员来执行集合的“滚动”升级,从而升级到2.4,而其他成员则可以最大程度地减少停机时间。使用以下过程:
通过关闭并一次将2.2二进制文件替换为2.4二进制文件,一次升级集合的第二个成员mongod
。升级mongod
实例后,请等待成员恢复到SECONDARY
状态,然后再升级下一个实例。要检查成员的状态,请rs.status()
在
mongo
shell中发出。
使用mongo
shell方法rs.stepDown()
降级主要数据库,以允许常规故障转移过程。 rs.stepDown()
加快故障转移过程,并且比直接关闭主数据库更可取。
一旦主节点降级并且另一个成员进入了
PRIMARY
状态,如在输出中所观察到的
rs.status()
,请关闭先前的主节点,并用mongod
2.4二进制文件替换
二进制文件并启动新进程。
注意
副本集故障转移不是即时的,但是将使该集不可用于读取或接受写入,直到故障转移过程完成为止。通常,这需要10秒钟或更长时间。您可能希望在预定义的维护时段内计划升级。
重要
如果集群的所有成员当前正在运行2.2实例,则仅将分片集群升级到2.4 。运行2.0的分片群集的唯一受支持的升级路径是通过2.2。
将分片群集从MongoDB版本2.2 升级到2.4(或2.3)时,需要运行mongos
带有该--upgrade
选项的2.4 ,如本过程所述。升级过程不需要停机。
对MongoDB 2.4的升级为现有集群中的所有集合和块添加了元数据。即使2.2不需要纪元,MongoDB 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
可能需要预先分配其他数据文件。请参阅
如何获取有关数据库存储使用的信息?欲获得更多信息。
更改为分片群集的元数据格式(存储在 config数据库中),在迁移到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()
,然后
db.collection.ensureIndex()
。如果需要升级
_id
索引{v:1}
使用db.collection.reIndex()
。
您可能{v:0}
在群集中的其他数据库上具有索引。
可选的
为了在升级过程中提高安全性,可以使用mongodump
或其他备份工具对config数据库进行备份。
确保分片群集中没有任何版本2.0 mongod
或
mongos
进程仍处于活动状态。自动升级过程会检查2.0个过程,但是网络可用性可能会阻止进行明确的检查。在停止或升级2.0版mongos
进程后,请等待5分钟,以确认所有进程仍未激活。
mongos
通过configDB
指向分片群集的配置服务器并带有--upgrade
选项来启动一个2.4 进程
。升级过程发生在该过程成为守护程序之前(即之前)
--fork
。
您可以将现有mongos
实例升级
到2.4,也可以启动
可以访问所有配置服务器的新mongos实例(如果需要避免重新配置生产)mongos
。
mongos
使用类似于以下内容的命令启动:
如果没有该--upgrade
选项,mongos
则在升级过程完成之前,进程将无法启动2.4
。
升级将防止在升级过程中发生任何块移动或分裂。如果有很多分片集合,或者其他失败的进程持有过时的锁,则获取所有集合的锁可能需要几秒钟或几分钟的时间。请参阅日志以获取进度更新。
该mongos
过程成功启动后,升级即告完成。如果该mongos
过程无法启动,请检查日志以获取更多信息。
如果mongos
在升级过程中终止或失去与配置服务器的连接,则可以始终安全地重试升级。
但是,如果在短关键部分内升级失败,mongos
将退出并报告升级将需要手动干预。要继续升级过程,您必须遵循“关键部分中断”过程后的 “ 重新同步”。
升级和重新启动其他mongos
的分片群集中的过程,而不该--upgrade
选项。
有关更多信息,请参见升级分片群集组件。
重新启用平衡器。现在,您可以执行修改集群元数据的操作。
升级后,请勿将2.0版MongoDB进程引入分片群集。这样可以将旧的元数据格式重新引入到配置服务器中。通过此升级过程进行的元数据更改将有助于防止由于MongoDB的未来版本中的跨版本不兼容而引起的错误。
在将更改应用于元数据的升级的短暂关键阶段中,网络中断不太可能但有可能阻止所有三台配置服务器验证或修改数据。如果发生这种情况,则必须重新同步配置服务器,并且在启动新mongos
进程时可能会出现问题。分片群集
将保持可访问性,但是要避免所有群集元数据更改,直到重新同步配置服务器为止。更改元数据的操作包括:添加分片,删除数据库和删除集合。
注意
仅执行以下步骤,如果某物(例如,网络,功率等)升级的短临界段期间的中断升级过程。请记住,您可以始终安全地尝试元数据升级过程。
要重新同步配置服务器:
关闭分片群集中的平衡器,并停止所有元数据操作。如果您正在升级过程中(将分片群集从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
)。
在某些情况下,连接池可能会导致虚假故障,因为mongos
只有在尝试使用后才禁用旧连接。2.4修复了这个问题,但要避免在2.2版本这个问题,你可以重新启动所有mongos
实例(一个接一个,以避免停机时间),然后使用rs.stepDown()
重新启动每个碎片的方法之前副本集
初选。
分片群集现在已完全重新同步;但是,在再次尝试升级过程之前,必须使用2.2版手动重置升级状态mongos
。通过连接到2.2开始mongos
与mongo
外壳:
然后,使用以下操作重置升级过程:
最后,重试升级过程,如 将分片群集从MongoDB 2.2升级到MongoDB 2.4中一样。
成功完成“元数据升级过程”中所述的元数据升级过程并mongos
启动2.4
实例后,您可以升级MongoDB部署中的其他过程。
在仍然禁用平衡器的情况下,请按以下顺序升级分片群集的组件:
mongos
以任何顺序升级集群中的所有实例。mongod
配置服务器实例,并在参数
last中升级第一个系统。mongos --configdb
mongod
在运行replSetStepDown
和升级每个分片的主数据库之前先升级第二个。完成此过程后,您现在可以重新启用平衡器。
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组件的群集,请使用以下过程之一。
如果您使用mongod
2.3或2.4-rc(候选发行版)系列中的,则可以安全地将这些数据库转换为2.4.0或更高版本;但是,如果使用v2.4-rc2之前的版本创建2dsphere
或建立text
索引mongod
,则需要重建这些索引。例如:
在某些情况下,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 MongoDB进程。完成升级过程后,请勿使用2.0进程。
注意
在分片群集中,一旦完成元数据升级过程,就不能在同一群集中使用2.0
mongod
或mongos
实例。
如果完成元数据升级,则可以按任何顺序安全地降级组件。再次升级时,请务必先升级mongos
实例再升级mongod
实例。
不要在具有2.2个组件的群集中创建2dsphere
或建立text
索引。
如果您升级到MongoDB 2.4,然后需要使用相同的数据文件运行MongoDB 2.2,请考虑以下限制。