翻译或纠错本页面

• 发布笔记 >
• Release Notes for MongoDB 3.2 >
• 将MongoDB升级到3.2

将MongoDB升级到3.2

在您尝试任何升级之前，请熟悉本文档的内容。

如果您需要升级到3.2版本的指导，MongoDB 提供 3.2 升级 服务 帮助您在对MongoDB应用没有任何中断的情况下进行顺畅的转化。

升级建议和检查列表

升级的时候，考虑一下几点：

升级要求

为了将现有的MongoDB部署升级到3.2，您的部署必须运行在一个3.0系列的版本中。

为了从2.6系列的版本中进行升级，在升级到3.2版本之前，您 必须 升级到最新的3.0系列版本。从2.6系列升级到3.0系列的版本升级流程，请查阅 将MongoDB升级到3.0.

准备工作

在开始您的升级之前，查阅 Compatibility Changes in MongoDB 3.2 文档以保证您的应用以及 部署与MongoDB3.2兼容。在开始升级之前，解决您部署中不兼容的地方。

升级MongoDB时，在将升级部署到您的生产环境之前，请在一个临时环境中测试您的应用。

将单机 mongod 实例升级到MongoDB3.2

The following steps outline the procedure to upgrade a standalone mongod from version 3.0 to 3.2. To upgrade from version 2.6 to 3.2, upgrade to the latest 3.0-series release first, and then use the following procedure to upgrade from 3.0 to 3.2.

使用Package Manager（包管理器）进行升级

如果您是从MongoDB apt, yum, dnf, or zypper 代码库安装的MongoDB，您应该使用包管理器升级到3.2。更具您的Linux系统选择合适的 installation instructions 。这将包括增加新版本的代码库，然后执行真正的升级。

手动升级

否则，您可以手动升级MongoDB：

1

Download 3.2 binaries.

Download binaries of the latest release in the 3.2 series from the MongoDB Download Page. See 安装MongoDB for more information.

2

Replace with 3.2 binaries

Shut down your mongod instance. Replace the existing binary with the 3.2 mongod binary and restart mongod.

注解

MongoDB 3.2在一些 mongod 故障时会造成内核转储。在生产环境下，如果您之前没关闭内核转储的话，建议您关闭操作系统的内核转储。

升级复制集到3.2

预备工作

在您升级到3.2版本之前，所有的复制集成员必须运行在3.0版本之上。从之前的MongoDB版本升级之前， 首先 upgrade to the latest 3.0-series release ，然后使用下列步骤从3.0升级到3.2。

升级二级制

您可以使用一个 “rolling” 升级从MongoDB3.0升级到3.2，通过在其它成员可用的情况下，单独升级成员，以最小化宕机时间。

1

Upgrade secondary members of the replica set.

Upgrade the secondary members of the replica set one at a time:

• Shut down the mongod instance and replace the 3.0 binary with the 3.2 binary.
• Restart the member and wait for the member to recover to SECONDARY state before upgrading the next secondary member. To check the member’s state, issue rs.status() in the mongo shell.

2

Step down the replica set primary.

Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

3

Upgrade the primary.

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, upgrade the stepped-down primary:

• Shut down the stepped-down primary and replace the mongod binary with the 3.2 binary.
• Restart.

Replica set failover is not instant and will render the set unavailable to accept writes until the failover process completes. This may take 30 seconds or more: schedule the upgrade procedure during a scheduled maintenance window.

注解

MongoDB 3.2在一些 mongod 故障时会造成内核转储。在生产环境下，如果您之前没关闭内核转储的话，建议您关闭操作系统的内核转储。

升级分片集群到3.2

预备工作

• 3.0版本或之后

  为了将一个分片集群升级到3.2， 所有 集群成员必须至少是3.0版本。升级过程检查集群的所有组件，如果任何成员运行在早于3.0的版本上，都将会生成警告。

• 在升级过程中，停止元数据的修改。

  在升级过程中，确保客户端不会修改集合的元数据。例如，在升级的过程中，千万 不要 执行下面任何一个操作：

  • sh.enableSharding()
  • sh.shardCollection()
  • sh.addShard()
  • db.createCollection()
  • db.collection.drop()
  • db.dropDatabase()

  • 任何创建数据库的操作

  • 以任何方式修改集群元数据的其它任何操作。

  查阅 分片参考文献 了解分片命令的完整列表。并不是 分片参考文献 页面中所有的命令都会修改集群元数据。

• Disable the balancer

• 备份 config 数据库

  Optional but Recommended. As a precaution, take a backup of the config database before upgrading the sharded cluster.

升级二级制

1

Disable the Balancer.

Disable the balancer as described in Disable the Balancer.

2

Upgrade the shards.

Upgrade the shards one at a time. If the shards are replica sets, for each shard:

1. Upgrade the secondary members of the replica set one at a time:

   • Shut down the mongod instance and replace the 3.0 binary with the 3.2 binary.
   • Restart the member and wait for the member to recover to SECONDARY state before upgrading the next secondary member. To check the member’s state, issue rs.status() in the mongo shell.

2. Step down the replica set primary.

   Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

   rs.stepDown()
   

3. When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, upgrade the stepped-down primary:

   • Shut down the stepped-down primary and replace the mongod binary with the 3.2 binary.
   • Restart.

3

Upgrade the config servers.

Upgrade the config servers one at a time in reverse order of the configDB or --configdb setting for the mongos. That is, if the mongos has the following --configdb listing:

mongos --configdb confserver1:port1,confserver2:port2,confserver3:port2

Upgrade first confserver3, then confserver2, and lastly confserver1.

Starting with the last config server listed in the configDB setting:

1. Stop the config server and replace with the 3.2 binary.

2. Start the 3.2 binary with both the --configsvr and --port options:

   mongod --configsvr --port <port> --dbpath <path>
   

   If using a configuration file, specify sharding.clusterRole: configsvr and net.port in the file:

   sharding:
      clusterRole: configsvr
   net:
      port: <port>
   storage:
      dbpath: <path>
   

Repeat for the config server listed second in the configDB setting, and finally the config server listed first in the configDB setting.

4

Upgrade the mongos instances.

Replace each mongos instance with the 3.2 binary and restart.

mongos --configdb <cfgsvr1:port1>,<cfgsvr2:port2>,<cfgsvr3:port3>

5

Re-enable the balancer.

Re-enable the balancer as described in 开启均衡过程.

注解

MongoDB 3.2在一些 mongod 故障时会造成内核转储。在生产环境下，如果您之前没关闭内核转储的话，建议您关闭操作系统的内核转储。

Once the sharded cluster binaries have been upgraded to 3.2, existing config servers will continue to run as mirrored mongod instances. For instructions on upgrading existing config servers to a replica set, see Upgrade Config Servers to Replica Set (requires MongoDB version 3.2.4 or later versions).

其它资料

• 准备好使用MongoDB3.2了？获取我们的帮助。<https://www.mongodb.com/contact/mongodb-3-2-upgrade-services?jmp=docs>`_

←   JavaScript Changes in MongoDB 3.2 Downgrade MongoDB from 3.2  →

© MongoDB, Inc 2008-2017. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.