翻译或纠错本页面

升级分片集群到 3.4¶

本页内容

升级建议及检查列表
必要准备
下载 3.4 二进制文件
升级流程
其它升级流程

警告

3.4 与IBM Power 系统上 Ubuntu 16.04 的不兼容性: 由于 lock elision bug in glibc ，如果你在IBM Power系统上运行 Ubuntu 16.04，请不要在生产中使用MongoDB 3.4，直到修改后的 glibc 版本发布并且您已经安装了该版本。

重要

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

如果你需要升级到 3.4 的指导， MongoDB offers major version upgrade services 可以在没有任何中断MongoDB应用的情况下，帮助您保证一个平稳的过渡。

升级建议及检查列表¶

在升级的时候，考虑下列内容：

升级版本路径¶

如果想将现有的MongoDB部署升级到 3.4 ，您必须运行在 3.2-series 版本上。

为了从早于 3.2-series 的版本中进行升级，您必须依次升级主要版本直到您升级到 3.2-series 。例如，如果你正在运行一个 3.2-series ，在升级到 3.4-series 之前，您必须首先升级到 3.2 。

准备工作¶

在开始您的升级之前，查阅 MongoDB 3.4 中的兼容性变化 文档以保证您的应用和部署于 MongoDB 3.4 兼容。在开始升级之前，解决部署中的不兼容性。

在升级MongoDB之前，首先在测试环境中测试您的应用，再将升级部署到您的生产环境。

降级考量¶

一旦升级到 3.4，您不能降级到 3.2.7 或者是之前的版本。您只可以降级到 3.2.8 或之后的版本。

`mongos` 和之前版本的 `mongod` 实例¶

3.4 版本的 mongos 实例不能连接到之前版本的 mongod 实例。

3.2 和之前的 mongo shell与3.4 集群不兼容。

必要准备¶

Version 3.2 or Greater

为了将分片集群升级到 3.4 ，所有集群成员必须至少是 3.2 版本。升级流程检查集群的所有组件，如果任何组件运行在早于 3.2 版本的MongoDB之上，将会产生警报。
配置服务器为复制集（CSRS）

从 3.4 开始，不再支持镜像 mongod 实例作为配置服务器（SCCC）的使用。在您将复制集升级到 3.4 之前，您必须将您的配置服务器从SCCC转化到复制集（CSRS）。

为了将您的配置服务器从SCCC转化到CSRS，请查阅 Upgrade Config Servers to Replica Set 。
在升级的过程中停止元数据的修改
在升级过程中，确保客户端不会修改客户端元数据。例如，在升级过程中，千万不要执行以下任何操作：
- sh.enableSharding()
- sh.shardCollection()
- sh.addShard()
- db.createCollection()
- db.collection.drop()
- db.dropDatabase()
- 任何创建数据库的操作
- 任何以任何方式修改集群元数据的操作
查阅 分片参考文献 了解分片命令的完整列表。并不是 分片参考文献 页面上的所有命令都会修改集群元数据。
Disable the balancer
备份 config 数据库

非必要，但推荐。作为预防措施，在升级分片集群之前 , 生成一个 配置 数据库的备份。

下载 3.4 二进制文件¶

通过包管理工具¶

如果您从 MongoDB apt ， yum ， dnf ，或者 zypper 资源库安装的MongoDB，您应该使用包管理工具升级到 3.4 。

在您的Linux系统中遵循正确的 installation instructions 。包括了：增加新版本的资料库，然后执行真正的升级流程。

手动下载 3.4 二进制文件¶

如果您不是使用包管理工具安装MongoDB，您可以从 MongoDB Download Center <https://www.mongodb.com/download-center?jmp=docs>`_ 手动下载MongoDB二进制文件。

查阅 安装MongoDB 了解更多信息。

升级流程¶

1

Disable the Balancer.¶

Disable the balancer as described in Disable the Balancer.

2

Upgrade the config servers.¶

If the config servers are replica sets:

Upgrade the secondary members of the replica set one at a time:
1. Shut down the secondary mongod instance and replace the 3.2 binary with the 3.4 binary.
2. Start the 3.4 binary with both the --configsvr and --port options:
```
mongod --configsvr --port <port> --dbpath <path>
```
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr and net.port and start the 3.4 binary:
```
sharding:
   clusterRole: configsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.
3. 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.
  
  Repeat for each secondary member.
Step down the replica set primary.
1. 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()
```
2. When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the stepped-down primary and replace the mongod binary with the 3.4 binary.
3. Start the 3.4 binary with both the --configsvr and --port options:
```
mongod --configsvr --port <port> --dbpath <path>
```
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr and net.port and start the 3.4 binary:
```
sharding:
   clusterRole: configsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.

3

Upgrade the shards.¶

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

Upgrade the secondary members of the replica set one at a time:
1. Shut down the mongod instance and replace the 3.2 binary with the 3.4 binary.
2. Start the 3.4 binary with the --shardsvr and --port command line options.
```
mongod --shardsvr --port <port> --dbpath <path>
```
  Of if using a configuration file, update the file to include sharding.clusterRole: shardsvr and net.port and start:
```
sharding:
   clusterRole: shardsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.
3. Wait for the member to recover to SECONDARY state before upgrading the next secondary member. To check the member’s state, you can issue rs.status() in the mongo shell.
  
  Repeat for each secondary member.
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()
```
When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, upgrade the stepped-down primary:
1. Shut down the stepped-down primary and replace the mongod binary with the 3.4 binary.
2. Start the 3.4 binary with the --shardsvr and --port command line options.
```
mongod --shardsvr --port <port> --dbpath <path>
```
  Of if using a configuration file, update the file to specify sharding.clusterRole: shardsvr and net.port and start the 3.4 binary:
```
sharding:
   clusterRole: shardsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.

4

Upgrade the `mongos` instances.¶

Replace each mongos instance with the 3.4 binary and restart. Include any other configuration as appropriate for your deployment.

注解

In 3.4, mongos no longer supports --chunkSize and --noAutoSplit runtime options (or the corresponding sharding.chunkSize and sharding.autoSplit settings). If your 3.2 mongos configuration includes these settings, remove the settings when running the 3.4 mongos.

mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3>

5

Re-enable the balancer.¶

Using a 3.4 mongo shell, re-enable the balancer as described in 开启均衡过程.

3.2 和之前的 mongo shell与3.4 集群不兼容。

6

Enable backwards-incompatible 3.4 features.¶

At this point, you can run the 3.4 binaries without the 3.4 features that are incompatible with 3.2.

To enable these 3.4 features, set the feature compatibility version to 3.4.

警告

Enabling these backwards-incompatible features can complicate the downgrade process. For details, see 删除 3.4 不兼容的功能.

It is recommended that after upgrading, you allow your deployment to run without enabling these features for a burn-in period to ensure the likelihood of downgrade is minimal. When you are confident that the likelihood of downgrade is minimal, enable these features.

On a mongos instance, run the setFeatureCompatibilityVersion command in the admin database:

db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )

This command must perform writes to an internal system collection. If for any reason the command does not complete successfully, you can safely retry the command on the mongos as the operation is idempotent.

其它升级流程¶

如果需要升级复制集，请查阅 升级复制集到 3.4 。
如果需要升级复制集，请查阅 升级复制集到 3.4 。

← 升级复制集到 3.4 降级 MongoDB 3.4 到 3.2 →