翻译或纠错本页面

将MongoDB升级到3.0

在本页中

一般情况下，从mongodb2.6升级到3.0是二进制兼容的“就地”升级：关闭 mongod 实例，用3.0替换它们并运行。 然而 ，在你升级之前请确保你了解了这个文档的内容，尤其是关于 升级分片集群 的步骤。

如果你在升级到3.0的时候需要指导， MongoDB可以提供咨询服务 来确保你的MongoDB应用没有中断地平滑升级。

升级建议和清单

升级时，请考虑以下几点：

升级要求

要升级现存的mongodb到3.0，你只能从2.6版本升级。如果你运行的版本比2.6要老，在升级到3.0之前 必须 先升级到2.6。见 Upgrade MongoDB to 2.6 来查看2.4升级到2.6的步骤。一旦你升级到了2.6，你 不能 再降级到2.4版本之前的版本。

如果你现在运行的mongodb已经使用了认证和授权，你的用户数据模型 authSchema 的版本至少应该是3。为了确认现存的 authSchema 的版本，见 MongoDB 2.4 User Model Removed。要升级 authSchema 版本，请点击 Upgrade User Authorization Data to 2.6 Format 查看详情。

准备

在升级mongodb之前，需要在对生产环境升级之前多在测试环境测试你的应用。

MongoDB 3.0的一些更改需要手动核对和干预。开始你的升级之前，查看 :doc:`/release-notes/3.0-compatibility`以确保你的应用和部署是和MongoDB 3.0兼容的。在开始升级之前请解决你的集群不兼容性。

降级限制

一旦升级到MongoDB 3.0，你将 不能 降级到 2.6.8 以前的版本。

如果你升级到3.0并且已经运行了 authSchemaUpgrade ，你必须要禁用 --auth ，或者恢复升级前的一个备份才可以降级到2.6，因为 authSchemaUpgrade 弃用了2.6采用的 MONGODB-CR 认证。详见 升级现存的 MONGODB-CR 认证机制到 SCRAM-SHA-1 。

升级MongoDB的过程

升级单独 mongod 实例到MongoDB 3.0

下面的步骤描述如何将一个单独 mongod 从2.6升级到3.0。要从2.4升级到3.0 首先 请查看 upgrade to version 2.6 ，然后用下面的步骤从2.6升级到3.0。

升级二进制文件

如果你从 apt ， yum 或者 zypper 仓库安装MongoDB，你应该使用你的包管理工具升级到3.0。查看合适版本的 installation instructions 来为你的linux系统找到合适的安装方法。这涉及为新版本添加一个仓库，然后执行实际的升级。

否则，你需要手动升级MongoDB：

1
Download 3.0 binaries.

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

2
Replace 2.6 binaries.

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

为独立模式的实例修改存储引擎到WiredTiger

为了修改独立模式 mongod 实例的存储引擎到WiredTiger，参考：将单机模式下的 MongoDB 存储引擎切换到WiredTiger。

升级一个复制集到3.0

前提条件

升级二进制文件

你可以使用”滚动”的方式从MongoDB 2.6升级到3.0来最小化你的宕机时间，这是指在其他成员可用的时候分别升级复制集的成员：

1
Upgrade secondary members of the replica set.

Upgrade the secondary members of the set one at a time by shutting down the mongod and replacing the 2.6 binary with the 3.0 binary. After upgrading a mongod instance, wait for the member to recover to SECONDARY state before upgrading the next instance. To check the member’s state, issue rs.status() in the mongo shell.

2
Step down the replica set primary.

Use rs.stepDown() in the mongo shell to step down the primary and force the set to failover. rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly.

3
Upgrade the primary.

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the previous primary and replace the mongod binary with the 3.0 binary and start the new instance.

复制集高可用并不是立即实施的，实施时会导致集群暂时无法接受写操作直至错误恢复过程完成。这个过程可能需要30秒或者更多：请在预定的维护时间窗内执行更新。

改变复制集的存储引擎为WiredTiger

为了修改复制集模式的实例到WiredTiger，参考 将复制集模式下的 MongoDB 存储引擎切换到 WiredTiger 。

升级分片集群到3.0

只有 所有 的集群成员当前运行的实例为2.6的时候才可以升级分片集群到3.0。运行中的2.4的分片集群唯一的升级途径是先升级到2.6。升级的过程会验证集群中的所有成员，并且如果任何成员运行在2.4的时候都会发出警告。

注意事项

升级的过程不需要任何的宕机时间。然而，当你升级一个分片集群时，确保客户端不会改变集合的元数据，例如，在升级的过程中， 不能 进行以下的任何操作：

升级分片集群

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

1
Disable the Balancer.

Turn off the balancer in the sharded cluster, as described in Disable the Balancer.

2
Upgrade the cluster’s meta data.

Start a single 3.0 mongos instance with the configDB pointing to the cluster’s config servers and with the --upgrade option.

To run a mongos with the --upgrade option, you can upgrade an existing mongos instance to 3.0, or if you need to avoid reconfiguring a production mongos instance, you can use a new 3.0 mongos that can reach all the config servers.

To upgrade the meta data, run:

mongos --configdb <configDB string> --upgrade

You can include the --logpath option to output the log messages to a file instead of the standard output. Also include any other options required to start mongos instances in your cluster, such as --sslOnNormalPorts or --sslPEMKeyFile.

The 3.0 mongos will output informational log messages.

<timestamp> I SHARDING [mongosMain] MongoS version 3.0.0 starting: ...
...
<timestamp> I SHARDING [mongosMain] starting upgrade of config server from v5 to v6
<timestamp> I SHARDING [mongosMain] starting next upgrade step from v5 to v6
<timestamp> I SHARDING [mongosMain] about to log new metadata event: ...
<timestamp> I SHARDING [mongosMain] checking that version of host ... is compatible with 2.6
...
<timestamp> I SHARDING [mongosMain] upgrade of config server to v6 successful
...
<timestamp> I SHARDING [mongosMain] distributed lock 'configUpgrade/...' unlocked.
<timestamp> I -        [mongosMain] Config database is at version v6

The mongos will exit upon completion of the --upgrade process.

The upgrade will prevent any chunk moves or splits from occurring during the upgrade process. If the data files have many sharded collections or if failed processes hold stale locks, acquiring the locks for all collections can take seconds or minutes. Watch the log for progress updates.

3
Ensure mongos --upgrade process completes successfully.

The mongos will exit upon completion of the meta data upgrade process. If successful, the process will log the following messages:

<timestamp> I SHARDING [mongosMain] upgrade of config server to v6 successful
...
<timestamp> I -        [mongosMain] Config database is at version v6

After a successful upgrade, restart the mongos instance. If mongos fails to start, check the log for more information.

If the mongos instance loses its connection to the config servers during the upgrade or if the upgrade is otherwise unsuccessful, you may always safely retry the upgrade.

4
Upgrade the remaining mongos instances to 3.0.

Upgrade and restart without the --upgrade option the other mongos instances in the sharded cluster.

After you have successfully upgraded all mongos instances, you can proceed to upgrade the other components in your sharded cluster.

警告

Do not upgrade the mongod instances until after you have upgraded all the mongos instances.

5
Upgrade the config servers.

After you have successfully upgraded all mongos instances, upgrade all 3 mongod config server instances, leaving the first config server listed in the mongos --configdb argument to upgrade last.

6
Upgrade the shards.

Upgrade each shard, one at a time, upgrading the mongod secondaries before running replSetStepDown and upgrading the primary of each shard.

7
Re-enable the balancer.

Once the upgrade of sharded cluster components is complete, Re-enable the balancer.

修改存储引擎为WiredTiger

对于MongoDB 3.0的分片集群，你可以选择升级分片使用WiredTiger存储引擎，但config sever使用MMAPv1，如果你升级了config server使用WiredTiger，那必须升级所有3个config server使用WiredTiger。

为了修改分片集模式的实例到WiredTiger，参考 Change Sharded Cluster to WiredTiger 。

升级现存的 MONGODB-CR 认证机制到 SCRAM-SHA-1

升级完二进制文件后，见 Upgrade to SCRAM-SHA-1 来获取 SCRAM-SHA-1 的升级场景。

一般的更新步骤

Except as described on this page, moving between 2.6 and 3.0 is a drop-in replacement:

1

Stop the existing mongod instance.

For example, on Linux, run 2.6 mongod with the --shutdown option as follows:

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

Replace /var/mongod/data with your MongoDB dbPath. See also the 停止 mongod 进程 for alternate methods of stopping a mongod instance.

2

Start the new mongod instance.

Ensure you start the 3.0 mongod with the same dbPath:

mongod --dbpath /var/mongod/data

Replace /var/mongod/data with your MongoDB dbPath.

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

Report a Problem